En virksomhed, der har hørt om bug bounty, kan spørge sig selv, om et program med belønning for fund kan afløse den aftalte penetrationstest. Svaret hviler på to ting: hvad I skal bruge resultatet til, og om organisationen er klar til at modtage fund fra mange ukendte personer på én gang.
De to modeller ligner hinanden på overfladen, fordi begge handler om, at nogen med tilladelse leder efter svagheder. I praksis er de meget forskellige. En penetrationstest er en kontrakt med en kendt leverandør om et afgrænset område i en aftalt periode. Et bug bounty-program er en åben invitation, hvor mange deltagere kan lede, og hvor kun de fund, der lever op til programmets regler, bliver belønnet.
To måder at give tilladelse på
I en penetrationstest gives tilladelsen til en bestemt leverandør gennem en aftale. Den beskriver systemer, periode, udgangspunkt og kontaktpersoner. Begge parter ved, hvem der arbejder, og hvornår. → Scope i en penetrationstest
I et bug bounty-program gives tilladelsen gennem offentlige eller lukkede regler, som deltagerne accepterer. Reglerne beskriver, hvilke systemer der må undersøges, hvad der ikke er tilladt, og hvordan fund skal meldes. Virksomheden ved ikke på forhånd, hvem der deltager, eller hvornår de arbejder. Programmet kan være åbent for alle eller kun for inviterede deltagere.
Tilladelsen er det, der adskiller begge modeller fra uautoriseret hacking. Forskellen mellem de farvede hatte og betydningen af tilladelse er forklaret i → Hackere og deres hatte.
Hvad hver model giver
En penetrationstest giver en samlet rapport. Den beskriver, hvad der blev undersøgt, fra hvilket udgangspunkt, og hvad der blev fundet. Den beskriver også begrænsninger og det, der ikke blev nået. Rapporten kan bruges som dokumentation over for ledelse og kunder, fordi den knytter resultatet til et kendt omfang.
Et bug bounty-program giver enkeltstående meldinger, efterhånden som deltagerne finder noget. Det kan give mange forskellige blikke på de samme systemer over lang tid. Men programmet giver normalt ingen samlet beskrivelse af, hvad der er undersøgt. At der ikke kommer meldinger om kundeportalen, betyder ikke nødvendigvis, at den er grundigt afprøvet. Det kan også betyde, at ingen har kigget.
Deltagerne bliver belønnet for fund, ikke for tid. Det kan trække opmærksomheden mod de typer fejl, der er lette at finde og belønnes godt, mens mere tidskrævende områder bliver overset.
Fortroligheden er også forskellig. I en penetrationstest kan I aftale fortrolighed med én kendt leverandør, og rapporten afleveres kun til jer. I et program kender deltagerne selv de fund, de melder. Reglerne skal derfor beskrive, om og hvornår et fund må omtales offentligt, og hvordan deltagerne skal behandle de oplysninger, de møder undervejs. Det kræver, at nogen hos jer har taget stilling til netop de spørgsmål, før programmet åbner.
Modenhed afgør, om programmet kan bæres
Et bug bounty-program stiller krav til den organisation, der modtager fundene. Meldingerne kommer, når deltagerne finder noget, ikke når det passer jer. Nogle er dubletter, andre er uden betydning, og enkelte kan være alvorlige og kræve handling samme dag.
Før et program giver mening, bør virksomheden kunne svare ja til en række spørgsmål. Har I en fast proces for at vurdere og prioritere svagheder? Ved I, hvem der retter fejl i webshoppen eller kundeportalen, og kan de handle hurtigt? Er der nogen, der kan svare deltagerne fagligt og rettidigt? Har I besluttet, hvordan belønninger fastsættes og udbetales? → Hvem retter fundene?
Hvis svarene er usikre, er en aftalt penetrationstest ofte et bedre sted at begynde. Den giver et afgrænset antal fund på et kendt tidspunkt og en leverandør, der kan forklare dem. Det giver organisationen tid til at bygge den proces op, som et program senere vil kræve. → Prioritering af rettelser
Systemer, I ikke selv råder over
Både test og program kræver, at virksomheden har ret til at give tilladelse til de systemer, der er med. Det er især vigtigt i et åbent program, hvor deltagerne ikke har en aftale med jer, men kun med reglerne.
Hvis kundeportalen ligger hos et hostingfirma, eller hvis ERP-systemet drives af en leverandør, skal det være afklaret, om de accepterer, at ukendte personer undersøger løsningen. Reglerne skal tydeligt udelukke systemer, som virksomheden ikke selv kan godkende. → Er en penetrationstest lovlig?
Når de to bruges sammen
De to modeller udelukker ikke hinanden. En virksomhed med en moden proces kan bruge en penetrationstest til at få en grundig og dokumenteret vurdering af en ny løsning og et program til at holde løbende øje med de offentligt tilgængelige dele.
Uanset program kan det være en god idé at have en enkel og offentlig beskrivelse af, hvordan andre kan melde en svaghed, de har opdaget. Det er ikke et belønningsprogram, men en kontaktvej. Den gør det lettere for en udefrakommende at give besked på en ordentlig måde.
Hvis en kunde beder om dokumentation for sikkerhedsarbejdet, er det vigtigt at kende forskellen. En kunde, der beder om en testrapport, får ikke det samme ud af en oversigt over meldinger fra et program. → Når kunden beder om pentestrapporten
Det skal I lade være med
- At starte et program uden en proces for fund · Meldinger, der ikke bliver vurderet og besvaret, skaber både risiko og dårlig stemning.
- At læse ingen meldinger som ingen fejl · Fravær af fund siger ikke, hvad deltagerne faktisk har undersøgt.
- At bruge programmet som dokumentation over for kunder · En samlet testrapport og en liste over meldinger besvarer forskellige spørgsmål.
- At glemme leverandørernes systemer · Reglerne skal udelukke det, I ikke selv kan give tilladelse til.
- At vælge model efter, hvad andre gør · Vælg efter jeres spørgsmål og jeres evne til at håndtere fund.
Hvad kan og ikke kan konkluderes
En penetrationstest kan vise, hvad der blev fundet i et kendt omfang i en bestemt periode. Et bug bounty-program kan vise, hvad deltagerne har meldt inden for programmets regler. Ingen af dem kan vise, at systemerne er fri for svagheder.
Et program uden meldinger er ikke en dokumentation for sikkerhed, og en test uden fund er heller ikke en garanti. Begge resultater skal læses sammen med det, der faktisk blev undersøgt. → Etisk hacker
Tjekliste før I vælger model
- ☐ Er det skrevet ned, hvad resultatet skal bruges til?
- ☐ Har I en fast proces for at vurdere og prioritere svagheder?
- ☐ Kan de ansvarlige for webshoppen og portalen rette fejl hurtigt?
- ☐ Er der nogen, der kan svare deltagere i et program fagligt og rettidigt?
- ☐ Har hostingfirma og driftsleverandør accepteret de systemer, der indgår?
- ☐ Har I en offentlig kontaktvej til at melde svagheder?
Senest gennemgået: oktober 2026.
Næste skridt
Del af: Artikler om penetrationstest
Læs også: Etisk hacker · Spørgsmål og svar
→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest hos Nielco IT
