Sammenligning

Penetrasjonstest eller bug bounty

Kort svar: en penetrasjonstest er noe dere kjøper. Et bug bounty-program er noe dere driver.

Det er den forskjellen som betyr mest, og den som blir minst diskutert. Testen har en pris, en frist og en rapport. Programmet har en policy, en innboks og noen som må svare på det som kommer inn, hver uke, i årevis.

Begge deler har sin plass. For de fleste norske virksomheter under hundre ansatte er ingen av dem det første steget, og nest siste avsnitt her sier hva som er det i stedet.

Oppdatert 2026-08-16 · kildene kontrollert 2026-08-16 · skrevet av Erik Nilsen

De to modellene, kort

En penetrasjonstest: omfanget avtales skriftlig, prisen avtales før noe gjøres, og dere får en rapport som beskriver hva som ble undersøkt. Også der det ikke ble funnet noe. Dere betaler for undersøkelsen.

Et bug bounty-program: dere publiserer en policy som sier hva det er lov å teste og hva som ikke er det, og betaler per godkjent funn etter en satsliste dere setter selv. Det er åpent, det er løpende, og dere betaler for resultater.

Ordlisten sier det på én linje: programmet dekker det noen velger å se på, mens en test dekker det som er avtalt. Alt under her er konsekvensene av nettopp den setningen.

Hva dere sitter igjen med å vise fram

Er grunnen til at dere ser på dette at en kunde, en revisor eller en anbudsrunde har bedt om noe, er dette avsnittet det viktigste på siden.

En test gir en rapport med omfang, metode, funn og alvorlighetsgrad, og et sammendrag som kan videresendes. Den sier også hva som ble undersøkt uten at det ble funnet noe, og det er halve poenget med dokumentasjonen.

Et program gir en samling meldinger fra utenforstående. Det er ikke en beskrivelse av dekning. Ingen kan si hvor mye av systemet noen faktisk har sett på, fordi ingen har lovet å se på noe bestemt.

Hva et program koster i praksis

Utbetalingene er den delen folk regner på, og den er faktisk den enkleste å styre. Dere setter satsene selv, og dere kan sette et tak.

Kostnaden som overrasker er triageringen. Noen må lese hver melding, avgjøre om den er reell, avgjøre om den er en dublett av noe som allerede er meldt, og svare på en måte som ikke gjør at folk slutter å melde fra. Plattformene har egne tilstander for dubletter, for meldinger utenfor omfang og for det som er kjent fra før, nettopp fordi dette er en jobb noen må gjøre hver eneste uke.

Har dere ingen med tid til den jobben, blir programmet en innboks ingen svarer i. Det er verre enn ikke å ha noe program i det hele tatt, fordi den som meldte fra vet at dere ikke gjorde noe.

Hva et program krever av dere før dere åpner

Dette er listen som gjør at de fleste utsetter beslutningen, og det er som regel en riktig beslutning å utsette.

En skriftlig policy: hva som er innenfor, hva som ikke er det, og hva som aldri er tillatt
Et testmiljø med testdata, hvis dere vil at noen skal kunne logge inn. Ekte kundedata skal ikke ligge tilgjengelig for utenforstående
En navngitt mottaker, og en svartid dere faktisk klarer å holde
En satsliste, og en avklaring internt om hvem som godkjenner utbetalinger
En plan for hva som skjer når noen melder noe kritisk klokken 23 en fredag

Når bug bounty er riktig

Når dere allerede tester. Et program er et supplement til testing, ikke en erstatning for den.

Dere ruller ut endringer ofte, og en test i året henger etter virkeligheten
Dere har noen internt som eier sikkerhet, og som kan svare på det som kommer inn
Dere har allerede ryddet det opplagte, slik at programmet ikke fylles opp med det dere visste fra før
Dere har en tjeneste med mange brukere, der det finnes folk der ute som er nysgjerrige på den

Når testen er riktig

Når svaret skal foreligge på en dato, og når noen skal kunne lese det.

Dere trenger et svar innen en frist
Dere trenger noe skriftlig å vise fram til en kunde, en revisor eller et styre
Dere vil ha noen inn i det innloggede, med flere roller, uten å åpne det for hvem som helst
Dere vil ha en fast pris i stedet for en budsjettpost som varierer med hvor mye folk finner

Det billigste riktige steget er ingen av delene

Legg ut en adresse folk kan melde til. Det koster ingenting og tar en ettermiddag.

RFC 9116 beskriver et lite filformat kalt security.txt, som legges på /.well-known/security.txt. Der står det hvem som skal kontaktes, på hvilket språk, og hvor policyen ligger. Den som oppdager noe i systemet deres i dag har ofte ingen anelse om hvor det skal meldes, og gir opp.

Det er ikke et bug bounty-program. Det er ingen betaling, ingen satsliste og ingen forpliktelse ut over å svare. Det er også det steget som gir mest igjen av alt som står på denne siden, fordi den første meldingen de fleste virksomheter får kommer fra en tilfeldig person og ikke fra noen de betaler.

Har dere ikke security.txt, trenger dere ikke et bug bounty-program ennå. Dere trenger en postkasse.

Uavklart

Det som ikke er avklart

Et bug bounty-program hviler på at en skriftlig invitasjon gjør det lovlig å gjøre noe som ellers ikke er det. Det er en større antakelse enn den ser ut som.

Straffeloven § 204 rammer den som uberettiget skaffer seg tilgang til et datasystem. En publisert policy er ment å gjøre tilgangen berettiget, men vi kjenner ikke til norsk rettspraksis som avklarer hvor langt en slik invitasjon rekker, særlig når noen går utenfor det policyen sier.
Om en samling meldinger fra et program godtas som dokumentasjon i en anbudsrunde eller hos en revisor, finnes det ingen etablert praksis for. Spør den som stiller kravet, før dere legger opp til det.
Hva som skjer med personopplysninger en utenforstående kommer over underveis, må være tenkt igjennom før programmet åpnes. Juridisk er det ikke uklart. I praksis er det nesten alltid uavklart den dagen den første meldingen kommer.

Kilder

Hvor dette er hentet fra

Primærkilder, slik at dere kan kontrollere hvert punkt uten å spørre oss.

Videre

Les videre

Se også

Andre steder på nettstedet

Tjenester og priser