Rapporten dækker ikke det modul, kunden køber

Det kan ske: en ny kunde læser jeres pentestrapport og konstaterer, at netop det modul, kunden skal bruge, ikke var med i testen. Rapporten er god nok i sig selv, men den besvarer ikke kundens spørgsmål, og salget står stille, indtil I har et svar.

Svaret hviler på tre skridt. Først skal I vurdere, hvor stort hullet reelt er: deler modulet login, rettigheder og data med det, der blev testet, eller er det en selvstændig del? Dernæst skal I forklare kunden præcis, hvad rapporten dækker, og hvad den ikke gør. Til sidst skal I tilbyde en plan, der lukker hullet, enten med en afgrænset test af modulet eller ved at tage det med i den næste.

Hvorfor hullet opstår

Et softwareprodukt vokser i moduler, og testen bestilles ud fra det, der var vigtigst på bestillingstidspunktet. Et modul, der kom til senere, et tilkøb, få kunder bruger, eller en del, der blev anset for lav risiko, kan være holdt ude for at begrænse omfanget. Det var måske et fornuftigt valg dengang. Det bliver først et problem, når en kunde netop vil købe den del.

Hullet kan også være skjult. Omfangsafsnittet nævner måske produktet som helhed, mens bilagene viser, at testeren kun havde adgang til en del af funktionerne. Kundens sikkerhedsfolk finder den slags. Derfor er det bedre, at I selv har gennemgået omfanget mod jeres modulliste, før rapporten sendes ud. → Omfangsafsnittet i rapporten

Vurder, hvor meget der faktisk mangler

Ikke alle huller er lige store. Spørg jer selv om følgende, før I svarer kunden:

Fælles grundlag · bruger modulet samme login, samme rollemodel og samme adskillelse af kundedata som det testede?
Egne indgange · har modulet egne skærmbilleder, egne endepunkter i API’et eller egne integrationer, testeren ikke så?
Data · behandler modulet andre eller mere følsomme oplysninger end resten af produktet?
Alder · er modulet nyt, ombygget eller udviklet af et andet team?
Kundens brug · er modulet centralt for kunden, eller et tillæg, der bruges sjældent?

Deler modulet det meste med den testede del, kan en del af testens resultat have betydning for det. Har det egne indgange og egne data, siger rapporten meget lidt om det. Vær forsigtig med at overføre konklusioner. En test af login siger noget om login, ikke om det, der sker bag det i et andet modul.

Forklar hullet uden at bortforklare

Kunden har brug for et klart svar. Skriv, hvad rapporten omfatter, at modulet ikke var med, og hvorfor. Forklar kort, hvilke dele af modulet der bygger på det testede, og hvilke der ikke gør. Undgå at antyde, at modulet er “dækket indirekte”, hvis det ikke er tilfældet.

Kundens sikkerhedsfolk kan respektere et ærligt svar med en plan. Det, der skader, er et svar, der lyder dækkende, men som ikke holder, når kunden læser rapporten igen. → Opfølgende spørgsmål fra kundens sikkerhedsteam

Mulighederne for at lukke hullet

Der er typisk tre måder at komme videre på, og valget afhænger af kundens tidsplan og af, hvor langt der er til jeres næste test.

En afgrænset test af modulet · hurtigst, når kunden ikke kan vente, og giver en selvstændig rapport eller et tillæg.
Modulet med i næste test · naturligt, hvis næste test ligger tæt på, og kunden kan acceptere en plan med dato.
Midlertidig dokumentation · fx jeres egen beskrivelse af modulets sikkerhedsdesign, resultater fra automatiske test og jeres udviklingsproces, som supplement indtil testen er gennemført.

Den tredje mulighed er ikke en erstatning for en test, og det skal fremgå. Den kan give kunden tilstrækkeligt grundlag til at gå videre med en plan, men det er kunden, der afgør det. Omfanget af en afgrænset test afhænger af modulets størrelse, antallet af roller, integrationerne og om adskillelsen mellem kunder skal afprøves igen. De forhold er også dem, der bestemmer tidsforbruget, og dermed hvor hurtigt I kan give kunden et svar. Om hvordan sådanne opgaver prissættes: pris og tilbud. → Flere produkter i porteføljen

Et tænkt eksempel

Et softwarehus sælger et system til ejendomsadministration med et kernemodul og et nyere modul til lejerkommunikation. Forårets test omfattede kernemodulet. En boligorganisation vil købe begge dele og lægger særlig vægt på lejerkommunikationen, fordi den rummer oplysninger om beboerne.

Softwarehuset svarer, at rapporten omfatter kernemodulet, at lejerkommunikationen deler login og rettigheder med kernen, men har egne skærmbilleder, eget API og egen lagring af beskeder, som ikke var med. Det tilbyder en afgrænset test af modulet inden for de næste uger og vedlægger en beskrivelse af modulets adgangsstyring i mellemtiden. Kunden kan på det grundlag beslutte, om aftalen skal vente på testen eller underskrives med en betingelse.

Forebyg det næste hul

Når én kunde har spurgt, vil flere gøre det. Brug anledningen til at sammenholde jeres modulliste med det, testerne har set de seneste år. Moduler, der aldrig har været med, bør have en plan, også selvom ingen kunde har spurgt endnu. Notér beslutningen, så I kan forklare den, når spørgsmålet kommer. Overvej også, om salgsmaterialet og svarbiblioteket beskriver testen så bredt, at kunderne tror, alle moduler var med. Den formulering kan være kilden til overraskelsen. → Hvad skal med i en test af SaaS-produktet · → Et årshjul for sikkerhedstest

Det skal I lade være med

Påstå, at modulet er dækket indirekte · Det holder kun, hvis modulet ikke har egne indgange og data.
Sende rapporten uden at nævne hullet · Kunden finder det selv og stoler mindre på resten.
Love en test uden dato · En plan uden tidspunkt er ikke en plan for kunden.
Lade midlertidig dokumentation ligne en test · Kald den det, den er.
Udvide omfanget bagefter · Rapporten dækker det, testeren testede, intet andet.
Glemme de andre kunder · Bruger flere modulet, har de samme spørgsmål til gode.

Hvad kan og ikke kan konkluderes

En rapport uden modulet kan stadig sige noget om de dele, modulet deler med det testede. Den kan ikke sige noget om modulets egne funktioner, data og integrationer. En plan for at lukke hullet viser kunden, at I tager det alvorligt, men indtil testen er gennemført, er modulet utestet, og det bør stå sådan i jeres svar.