Bug bounty som svar på kundens krav om test?

Et softwarehus med et bug bounty-program kan fristes til at svare kundens spørgsmål om penetrationstest med en henvisning til programmet. Svaret hviler på, hvad kunden skal bruge: en dokumenteret test af et kendt omfang på et kendt tidspunkt, med fund og status. Et bug bounty-program giver ikke det dokument, så det kan ikke erstatte pentesten i svaret, men det kan supplere den og vise, at I tager imod sårbarheder fra andre.

Valget mellem de to modeller er beskrevet fra køberens side på penetrationtest.dk. Her handler det om, hvad I kan sige til kunden.

Hvad kunden spørger efter

Når kunden spørger, om produktet er penetrationstestet, ligger der et dokumentationsbehov bag. Kunden vil kunne sige internt, at leverandøren er vurderet, og vil gerne have noget at lægge i sagen. → Spørgsmålet om penetrationstest i skemaet

Det, kunden kan bruge, er en rapport, et resumé eller en erklæring, som siger:

Hvad der blev testet · produktet, modulerne og miljøet.
Hvornår · testperioden og den version, der blev testet.
Af hvem · en tester med kendte kvalifikationer og uafhængighed.
Hvad der blev fundet · fundene og deres alvorlighed.
Hvad der er sket siden · status for rettelserne.

Et bug bounty-program kan give en del af svaret på de sidste to punkter, men ikke de første tre.

Hvad et bug bounty-program viser

Et bug bounty-program er en ordning, hvor udefrakommende inviteres til at lede efter sårbarheder i et aftalt område efter faste regler og får en belønning for godkendte fund. Det bygger på samme grundlag som en politik for ansvarlig offentliggørelse: en kontaktvej, regler og en proces for at tage imod rapporter. → Ansvarlig offentliggørelse

ISO/IEC 29147 er en international standard for leverandørers modtagelse og offentliggørelse af oplysninger om sårbarheder i produkter og tjenester. Et program, der følger den slags principper, viser kunden, at I har en ordnet proces for at modtage og håndtere fund fra andre. Det er værdifuldt, og kunden kan med rette spørge til det.

Det, programmet ikke viser, er hvilke dele af produktet der faktisk er blevet undersøgt, hvor grundigt, og af hvem. Deltagerne vælger selv, hvor de leder, og et område uden indrapporterede fund kan være uundersøgt lige så vel som sikkert. Der er heller ingen fast testperiode eller version at henvise til, og deltagernes kvalifikationer er ukendte for kunden. Det er netop de oplysninger, en leverandørvurdering bygger på, og derfor kan kundens sikkerhedsfolk ikke sætte programmet i stedet for en rapport, selv om de anerkender det.

Svaret, I kan give

Har I både en pentest og et program, er svaret enkelt: henvis til pentesten som dokumentation og nævn programmet som et supplement. Det viser kunden to ting: at produktet er testet, og at I tager imod sårbarheder løbende.

Har I kun et program, så sig det præcist. Skriv ikke “ja” til spørgsmålet om penetrationstest, hvis svaret er et bug bounty-program. Beskriv i stedet, hvad programmet omfatter, siden hvornår det har kørt, og hvordan fund håndteres, og sig, om og hvornår en pentest er planlagt. → Svar, I ikke kan dokumentere

Hvad I kan dokumentere fra programmet

Selvom et program ikke giver en testrapport, kan det give dokumentation, som en kunde kan bruge.

Programmets regler · omfanget, hvad der er udelukket, og hvordan rapporter modtages.
Håndteringen af fund · hvordan I vurderer, prioriterer og retter det, der indrapporteres.
En samlet status · fx antallet af modtagne og rettede fund i en periode, hvis I fører den slags opgørelser.
Sammenhængen med pentesten · at fund fra programmet indgår i grundlaget for den næste test.

Det gør svaret konkret uden at udlevere detaljer om enkelte sårbarheder. Spørger kunden til jeres håndtering af sårbarheder generelt, er det samme oplysninger, der skal bruges. → Spørgsmål om hændelser og håndtering af sårbarheder

Når programmet og pentesten spiller sammen

De to ordninger kan styrke hinanden, og det kan I gøre synligt for kunden. Fund fra programmet kan pege på områder, hvor produktet har haft svagheder, og dermed på dele, som den næste pentest bør gå grundigere til. Omvendt kan pentesten dække områder, som deltagerne i programmet ikke har adgang til, fx funktioner bag login med bestemte roller eller administrationsmodulet.

Beskriv sammenhængen kort i den dokumentation, kunden får. En sætning om, at fund fra programmet indgår i planlægningen af den årlige test, og at testens omfang omfatter dele, programmet ikke dækker, siger mere end to separate henvisninger. Det viser også, at I har tænkt over, hvad hver ordning kan og ikke kan.

Et tænkt eksempel

Et softwarehus med en platform til onlinekurser har i to år haft et offentligt program for sårbarhedsrapporter med belønning. En ny kunde sender et spørgeskema, der spørger, om produktet er penetrationstestet inden for det seneste år.

Softwarehuset har ikke fået lavet en pentest. Svaret i skemaet bliver: “Nej, ikke inden for det seneste år. Vi har et program for sårbarhedsrapporter med følgende omfang og regler, og fund håndteres efter vores proces for sårbarheder. En penetrationstest af platformen er planlagt i næste kvartal, og et resumé kan udleveres, når den er afsluttet.”

Kunden accepterer svaret med en betingelse om at få resuméet, før aftalen forlænges. Softwarehuset noterer betingelsen i sin oversigt over kundekrav, så resuméet bliver sendt, når testen er afsluttet.

Det skal I lade være med

Svare ja til pentest, når svaret er bug bounty · det er to forskellige ting, og kunden vil opdage det.
Sige, at ingen fund betyder intet at finde · det er ikke det, programmet kan vise.
Udlevere detaljer om fund fra programmet · status og proces er nok.
Lade programmet stå uden regler, kunden kan læse · så kan kunden ikke vurdere det.
Glemme at bruge fundene i pentesten · de kan pege på områder, testen bør dække.

Hvad kan og ikke kan konkluderes

Et bug bounty-program kan vise, at I har en ordnet proces for at modtage og rette sårbarheder fra andre, og det kan være et godt supplement i svaret til kunden. Det kan ikke dokumentere, hvilke dele af produktet der er undersøgt, og derfor kan det ikke erstatte en penetrationstest, når kunden beder om netop den. Hvordan kunden vurderer jeres svar, afhænger af kundens egne krav.

Tjekliste til svaret

☐ Er det tydeligt, om der er lavet en pentest, og hvornår?
☐ Er programmet beskrevet med omfang og regler?
☐ Er håndteringen af fund fra programmet beskrevet?
☐ Er der en plan for en pentest, hvis der ikke er lavet en?
☐ Er svaret formuleret, så det ikke kan læses som et ja til en pentest?

Kilder

ISO/IEC 29147:2018 Vulnerability disclosure: krav og anbefalinger til leverandører om modtagelse og offentliggørelse af oplysninger om sårbarheder i produkter og tjenester.
NCSC (UK): Vulnerability Disclosure Toolkit: kontaktvej, politik og security.txt som grundelementer i en proces for at tage imod sårbarhedsrapporter.

Senest gennemgået: oktober 2026.