En offentlig kanal og en fungerende prosess for sårbarhetsrapporter utenfra: retningslinjer, security.txt, mottak, triage og koordinert offentliggjøring.
Før eller senere finner noen utenfor selskapet en sårbarhet i produktet ditt. Hva som skjer videre, avhenger av om vedkommende finner en adresse å skrive til, og av om noen svarer. Der det ikke finnes en kanal, havner rapporten i innboksen til kundestøtten, i sosiale medier eller ingen steder i det hele tatt.
Et program for sårbarhetsrapportering er minimumet: publiserte retningslinjer som sier hvordan man rapporterer og hva den som rapporterer, kan forvente, en innboks som blir lest, og en prosess som fører en rapport fra mottak til utbedring. Programmet betaler ingen belønninger og trenger ingen plattform. EUs cyberrobusthetsforordning (Cyber Resilience Act) gjør retningslinjer for koordinert offentliggjøring av sårbarheter obligatoriske for produsenter av produkter med digitale elementer: Rapportering av aktivt utnyttede sårbarheter gjelder fra 11. september 2026, alle forpliktelsene fra 11. desember 2027.
01Omfang
Hva vi tester
Retningslinjer for sårbarhetsrapportering: omfang, regler, safe harbour, tidslinje for offentliggjøring
security.txt etter RFC 9116, med overvåking av utløpsdatoen
Kanal for mottak: egen postkasse eller eget skjema, krypteringsnøkkel, bekreftelse på mottak
Rutine for triage: gjenskaping, vurdering av alvorlighetsgrad, fjerning av duplikater
Intern håndtering etter ISO/IEC 30111: ansvar, frister, eskalering
Kommunikasjon med dem som rapporterer, og koordinert publisering
Sikkerhetsvarsler og CVE-identifikatorer for sårbarheter i produktene dine
Rapporteringsplikter etter cyberrobusthetsforordningen og NIS2, der de gjelder
02Fremgangsmåte
Slik utføres arbeidet
01
Retningslinjer
Vi utarbeider retningslinjene sammen med den juridiske avdelingen din. Formuleringen om safe harbour følger teksten som miljøet av sikkerhetsforskere anerkjenner, tilpasset jurisdiksjonen din av juristene dine.
02
Kanal
Kanalen for mottak og security.txt settes opp og testes utenfra, slik en sikkerhetsforsker ville funnet dem.
03
Prosess
Roller, frister og eskalering skrives ned og øves på en testrapport før retningslinjene publiseres.
04
Drift
Hvis du ønsker det, driver vi mottaket: bekrefter mottak, gjenskaper, vurderer og overleverer bekreftede rapporter til ingeniørene dine.
Poengsum og vektor for alvorlighetsgraden til hvert funn.
FIRST
06Spørsmål
Spørsmål om denne tjenesten
Noen har sendt oss en sårbarhetsrapport og ber om penger. Hva gjør vi?
Ikke betal under press, og ikke kom med trusler. Bekreft mottak, be om de tekniske detaljene og verifiser påstanden. De fleste uoppfordrede rapporter kommer fra sikkerhetsforskere som handler i god tro, noen er automatisert støy, og noen få er utpressing. Vi verifiserer rapporten, vurderer alvorlighetsgraden og hjelper deg med å svare; be om dette gjennom skjemaet på dette nettstedet, og nevn at en rapport venter på svar.
Hva er forskjellen på et program for sårbarhetsrapportering og bug bounty?
Et program for sårbarhetsrapportering tar imot rapporter og lover rettferdig behandling. Bug bounty legger til betaling og inviterer dermed til aktiv leting. Det første er et minimum for alle selskaper med et produkt på nettet, det andre er en beslutning om budsjett og modenhet.
Utsetter en safe harbour-klausul oss for risiko?
Den forplikter deg til ikke å rettsforfølge folk som følger reglene dine. Den gir ikke tillatelse til noe utenfor disse reglene, og den binder verken tredjeparter eller påtalemyndigheten. Teksten gjennomgås av juristene dine før publisering.