Version og testdatoer: gør det tydeligt, hvad der blev testet

Et softwareprodukt ændrer sig hver måned, men en pentestrapport beskriver én bestemt udgave på bestemte dage. Hvis kunden ikke kan se, hvilken udgave og hvilke dage, kan rapporten ikke kobles til det produkt, kunden bruger nu, og så mister den meget af sin værdi i salget.

Svaret er enkelt at formulere, men kan blive overset: rapporten bør angive testperioden, rapportens udgivelsesdato og den version eller udrulning, der blev testet, og datoerne for en eventuel retest skal stå for sig. Med de oplysninger kan kunden selv vurdere, hvor meget der er sket siden.

Tre datoer, der ikke er den samme

En rapport kan have flere datoer, og de betyder noget forskelligt for modtageren:

Testperioden · de dage, hvor testeren faktisk arbejdede på produktet. Det er her, resultatet gælder.
Rapportdatoen · den dag, rapporten blev færdig. Den kan ligge et godt stykke efter testen.
Retestdatoen · den dag, testeren efterprøvede rettelserne. Den gælder kun for de fund, der blev set på igen.

Kunder regner forskelligt. Nogle tæller rapportens alder fra testperioden, andre fra rapportdatoen. Står kun én dato på forsiden, gætter kunden, og gættet falder ikke nødvendigvis ud til jeres fordel. Skriv alle tre, og betegn dem, så de ikke kan forveksles. → Kravet om en rapport under et år

Versionen gør datoen brugbar

En dato alene siger ikke, hvilket produkt testeren mødte. Hos et softwarehus med hyppige udrulninger kan produktet se anderledes ud fra den ene uge til den næste. Derfor bør rapporten også angive, hvad der blev testet, i den form I selv bruger til at identificere en udgave: et versionsnummer, et releasenavn eller en dato for udrulningen.

Det er ikke nødvendigt at give kunden jeres interne byggenumre. Det vigtige er, at I internt kan pege på præcis den udgave, og at kunden kan se, om den udgave ligger før eller efter ændringer, der har betydning for kunden. Hvis I udruller løbende uden versionsnumre, kan datoen for den udrulning, testen ramte, gøre samme nytte. → Hyppige udrulninger: hvilken version skal testes?

Ændringer under testen og dele med egen udgivelse

Testperioden kan strække sig over flere dage eller uger, og udviklingen holder ikke nødvendigvis pause imens. Kom der en udrulning midt i testen, bør rapporten sige det. Ellers kan et fund, der blev rettet undervejs, se ud, som om det stadig er åbent, eller en ny funktion kan se ud, som om den var med, selvom testeren aldrig så den.

Aftal derfor med testeren, før testen starter, om der må udrulles undervejs, og hvordan det i givet fald skrives ind. Om en kortere pause i udrulningerne er nødvendig, er en afvejning mellem jeres releaseplan og ønsket om en entydig rapport. → Kodefrys under testen: er det nødvendigt?

Præcision om versionen er lige så vigtig, når produktet ikke er ét samlet hele. Mange produkter består af dele, der udgives hver for sig: en webapplikation, et API med egen versionering, en integration eller en klient, kunderne installerer. Testede rapporten flere af dem, bør versionen angives for hver del, der har sin egen. En kunde, der kun bruger API’et, har brug for at vide, hvilken API-version der var med, ikke kun hvilken version webapplikationen havde.

Tilsvarende bør det fremgå, hvis en del var med i testen på et andet tidspunkt end resten. Ellers kan kunden tro, at hele produktet blev testet på én gang, og drage forkerte slutninger om de dele, der faktisk blev set på tidligere eller senere.

Samme datoer i alle dokumenter

Rapporten er ikke altid det eneste sted, kunden ser datoerne. De står også i erklæringsbrevet, i jeres svar i sikkerhedsspørgeskemaer, måske på en tillidsside og i salgsmateriale. Hvis ét dokument siger marts, et andet april og et tredje bare “i foråret”, begynder kundens sikkerhedsfolk at tvivle på resten.

Vælg derfor, hvilken dato I bruger som testens dato i korte sammenhænge, og brug den samme overalt. Testperioden er som regel det mest retvisende valg, fordi det er dér, resultatet gælder. Når en ny test eller retest kommer, så opdater alle stederne på én gang, og hav én person, der ved, hvor de står. → Erklæringsbrevet fra testeren

Et tænkt eksempel

Et softwarehus udvikler et system til dokumenthåndtering for advokatkontorer og udruller hver anden uge. Testen fandt sted over to uger i marts, rapporten kom i april, og retesten af to fund lå i maj. Der kom én udrulning midt i testperioden.

Rapportens forside angiver testperioden, rapportdatoen og retestdatoen hver for sig. Omfangsafsnittet nævner, hvilken udrulning testen startede på, og at én ny udrulning kom undervejs, hvad den indeholdt på overordnet niveau, og at testeren tog højde for den. En kunde, der i september spørger til rapporten, kan derfor se, at resultatet beskriver produktet i marts, og spørge målrettet til ændringerne siden. → Omfangsafsnittet

Hvad I skal kunne svare på bagefter

Datoer og versioner i rapporten er kun halvdelen. Den anden halvdel er jeres egen oversigt over, hvad der er sket siden. Når kunden spørger, om rapporten stadig dækker, skal I kunne sige, hvilke væsentlige ændringer der er kommet, og om nogen af dem er vurderet som en anledning til ny test.

Hold en kort log ved siden af rapporten: version, dato, ændringer med betydning for sikkerheden, og jeres vurdering af dem. Den gør det muligt at give kunden et præcist svar uden at improvisere. → Meget er udgivet siden testen

Det skal I lade være med

Kun angive rapportdatoen · Kunden kan tro, at testen er nyere, end den er, og opdage det senere.
Lade retesten opdatere forsiden · En retest gør ikke hele rapporten nyere.
Udelade versionen · Uden den kan ingen se, hvilket produkt resultatet gælder.
Tie om udrulninger under testen · Det skaber tvivl om fundenes status.
Give én version for et produkt med flere dele · Hver del med egen udgivelse skal have sin.
Svare på ændringer uden log · Et gæt om, hvad der er udrullet siden, holder ikke i en gennemgang.

Hvad kan og ikke kan konkluderes

Tydelige datoer og versioner viser kunden, hvilken udgave af produktet testen beskriver, og hvornår. De gør ikke resultatet gyldigt for senere udgaver, og de siger ikke, om ændringerne siden har betydning for sikkerheden. Den vurdering er jeres, og kunden kan bede om at se den.