En gammel version, der stadig har kunder

Mange produkter har før eller siden en version, som ikke længere udvikles, men som nogle kunder stadig bruger, fordi de ikke har haft tid, budget eller lyst til at skifte. Spørgsmålet om test hviler på, hvad I har lovet de kunder: så længe I leverer og vedligeholder den gamle version, er den en del af jeres produkt, og kunderne på den har samme ret til at spørge, hvad den er testet for.

Den nyeste rapport handler som udgangspunkt om den nyeste version. Hvis en kunde på den gamle version beder om dokumentation, skal I enten kunne vise en test af den version, kunden bruger, eller forklare ærligt, hvorfor den ikke er testet, og hvad der sker fremover.

Hvorfor den gamle version bliver et særligt spørgsmål

Den gamle version kan halte bagefter på flere måder. Rettelser fra de seneste test er måske kun lavet i den nye version. Komponenter, som den gamle version bygger på, kan være forældede. Og udviklerne, der kendte koden bedst, arbejder måske på noget andet nu.

Samtidig kan det være de mest konservative kunder, der bliver på en gammel version: kunder med egne installationer, særlige tilpasninger eller integrationer, der er dyre at ændre. Det er også de kunder, der stiller grundige spørgsmål i deres årlige spørgeskema. Et tænkt eksempel er en forsyningsvirksomhed eller en større produktionsvirksomhed, der kører produktet på egne servere og har bygget arbejdsgange op om den gamle brugerflade. For dem er et skifte et projekt, ikke en opdatering, og indtil projektet er gennemført, vil de vide, at den version, de faktisk bruger, ikke er glemt. → Samme skema hvert år

Hvad rapporten om den nye version kan sige

En test af den nye version kan godt sige noget om den gamle, men kun om de dele, der er fælles og uændrede. Er login, administration og adskillelsen mellem kunderne bygget på samme måde i begge versioner, kan et fund i den nye version pege på det samme problem i den gamle.

Det gælder også den anden vej. En rettelse, der er lavet i den nye version, beskytter ikke kunderne på den gamle, medmindre den også er ført tilbage. Gennemgå derfor hvert fund i rapporten og notér, om det også findes i den gamle version, og om rettelsen er lavet dér. Det er den liste, en kunde på den gamle version har brug for at høre om. → Åbne fund i rapporten

Gamle versioner af et API er et kendt problem i sig selv. OWASP beskriver risikoen ved versioner, der stadig kører, men ikke længere holdes ved lige eller er med i overblikket. Hvis kunderne på den gamle version bruger et ældre API, hører det med i jeres vurdering. → Produktets API

Valgene for den gamle version

Der er grundlæggende fire veje, og de kan kombineres:

Tag den gamle version med i næste test · som et særskilt mål i omfanget, så rapporten kan sige noget om netop den.
Bestil en afgrænset test af det, der adskiller den · hvis versionerne deler meget, kan testen af den gamle nøjes med det, der er anderledes.
Skriv tydeligt, at den ikke er testet · med en begrundelse og en dato for, hvornår versionen ophører.
Flyt kunderne · en plan for at få dem over på den nye version, så spørgsmålet forsvinder.

Hvilken vej der er rigtig, afhænger af, hvor mange kunder der er tilbage, hvor længe versionen skal leve, og hvad jeres kontrakter siger om vedligeholdelse. Omfanget af en ekstra test afhænger af, hvor meget de to versioner har til fælles. Det indgår i → pris og tilbud.

Det, I lover kunderne på den gamle version

Det vigtigste er at være præcis. Kunden skal kunne se, hvilken version rapporten dækker, hvilke fund der er rettet i kundens version, og hvornår versionen ikke længere får sikkerhedsrettelser. → Version og testdatoer

Undgå at svare i spørgeskemaet, at produktet testes årligt, hvis det kun gælder den nye version, og kunden, der spørger, sidder på den gamle. Svaret er sandt for den ene gruppe kunder og forkert for den anden. Skriv hellere, hvilken version der testes, og hvad der gælder for de andre.

For software, som kunderne installerer hos sig selv, kan Cyber Resilience Act få betydning, når forordningen finder anvendelse. Den kræver, at fabrikanten fastsætter en supportperiode, hvor sårbarheder skal håndteres, og den giver i visse tilfælde mulighed for kun at levere sikkerhedsopdateringer til den seneste version, hvis brugerne af ældre versioner kan få den nyeste uden beregning. Hvordan reglerne gælder for jeres produkt, skal vurderes for sig; teksten er ikke juridisk rådgivning. → Cyber Resilience Act

En udløbsdato gør svaret lettere

En gammel version uden slutdato bliver ved med at trække spørgsmål med sig. En offentliggjort dato for, hvornår versionen ikke længere vedligeholdes, gør det lettere at svare alle kunder ens. Kunder på den gamle version kan se, hvornår de skal skifte, og I kan forklare, at testindsatsen ligger på den version, der har en fremtid.

Indtil datoen er nået, skal versionen dog behandles som en fuldgyldig del af produktet, også i testplanen. Bliver der fundet en alvorlig sårbarhed i den, gælder de samme forpligtelser over for kunderne som for den nye version. → Sikkerhedsmeddelelse til kunderne om en sårbarhed i produktet

Det skal I lade være med

Lade den nye versions rapport stå for begge · kunden på den gamle version læser versionsnummeret.
Rette fund i den nye version og glemme den gamle · notér for hvert fund, om det også gælder dér.
Svare generelt om test i skemaet · skriv, hvilken version svaret gælder for.
Holde liv i versionen uden slutdato · så bliver spørgsmålene ved.
Love rettelser i en version, der ikke længere udvikles · lov kun det, I kan holde.

Hvad kan og ikke kan konkluderes

En test af den nye version kan sige noget om de dele, den gamle version deler med den, men kun hvis I har vurderet, hvad der er fælles. Den siger intet om det, der kun findes i den gamle version. Uden en test eller en tydelig forklaring står kunderne på den gamle version uden dokumentation.

Tjekliste til den gamle version

☐ Ved I, hvor mange kunder der bruger den gamle version, og hvordan?
☐ Er hvert fund fra seneste test vurderet for den gamle version?
☐ Er rettelser ført tilbage, hvor det er lovet?
☐ Er det besluttet, om versionen skal testes, og i givet fald hvordan?
☐ Har versionen en offentliggjort slutdato?
☐ Siger jeres svar i spørgeskemaerne, hvilken version de gælder for?

Kilder

OWASP API Security Top 10 2023: Improper Inventory Management: risikoen ved ældre API-versioner, der stadig kører uden at blive holdt ved lige.
Forordning (EU) 2024/2847 (Cyber Resilience Act), artikel 13, stk. 8 og 10: supportperiode med håndtering af sårbarheder, og mulighed for kun at afhjælpe sårbarheder i den seneste version, når brugerne kan få den uden beregning.

Senest gennemgået: oktober 2026.