Koordinert offentliggjøring av sårbarheter: slik driver du et program

Hva er koordinert offentliggjøring av sårbarheter?

Koordinert offentliggjøring av sårbarheter (CVD) er praksisen med å håndtere en nyoppdaget sårbarhet privat mellom finneren og leverandøren til en retting eller et avbøtende tiltak er tilgjengelig, og deretter publisere den. CERT Guide to Coordinated Vulnerability Disclosure beskriver det som å samle inn informasjon fra dem som finner sårbarheter, koordinere delingen av informasjonen mellom de relevante interessentene og offentliggjøre sårbarheten og de avbøtende tiltakene, også for allmennheten.

For en produktleverandør har CVD to halvdeler. Den utadvendte halvdelen, å motta rapporter og publisere advisories, er det denne siden handler om. Den innadvendte halvdelen, å verifisere, rette og gi ut, er livssyklusen for sårbarhetshåndtering. Begge drives vanligvis av et PSIRT.

CVD vs full offentliggjøring vs bug bounty

	Koordinert offentliggjøring	Full offentliggjøring	Bug bounty
Hva det er	Privat rapport, retting og deretter publisering på et avtalt tidspunkt	Finneren publiserer detaljene umiddelbart, med eller uten å si fra til leverandøren	Et program som betaler for gyldige funn
Hvem styrer tidspunktet	Leverandør og finner sammen, noen ganger med en koordinator	Finneren	Vilkårene i programmet, som vanligvis følger CVD
Risiko for brukerne	Lavest: Detaljene blir offentlige når en retting finnes eller en frist går ut	Høyest: Angripere får vite om det samtidig med forsvarerne	Som for CVD
Kostnad	Arbeidstid til triage og oppfølging	Uplanlagt nødarbeid	Arbeidstid pluss belønninger og ofte plattformgebyrer

En bug bounty er ikke et alternativ til et program for offentliggjøring av sårbarheter (VDP). Den er et insentiv oppå et slikt program. Hver leverandør trenger en måte alle kan rapportere en sårbarhet på; en bounty avgjør bare om noen rapporter får betalt.

Dette hører hjemme i en policy for offentliggjøring av sårbarheter

En policy for offentliggjøring av sårbarheter er det offentlige dokumentet som setter vilkårene for programmet ditt. ISO/IEC 29147, den internasjonale standarden for offentliggjøring av sårbarheter, gjør ett element obligatorisk, en foretrukket kontaktmekanisme, og anbefaler flere. En fullstendig policy dekker:

• Hvordan du rapporterer. En egen adresse eller et nettskjema, og en måte å sende sensitive detaljer sikkert på, for eksempel en publisert krypteringsnøkkel.
• Hva som bør være med. Berørt produkt og versjon, steg for å reprodusere, konsekvens og hvordan rapportøren kan nås.
• Omfang. Hvilke produkter, versjoner og tjenester som er dekket, og hvilke testmetoder som ikke er tillatt, for eksempel tjenestenekt eller tilgang til andre brukeres data.
• Safe harbor. En forpliktelse til ikke å gå rettslig til verks mot forskning i god tro som følger policyen.
• Hva rapportører kan forvente. Når du bekrefter mottak av rapporten, hvordan du holder dem oppdatert, og tidsmålet ditt for en retting.
• Tidslinje for offentliggjøring. Når detaljene blir offentlige, og hva som skjer hvis en retting tar lengre tid.
• Publisering. Hvor advisories dukker opp, og om du tildeler CVE-ID-er.
• Anerkjennelse. Om og hvordan du krediterer rapportører, og om du betaler bounties.

Hold policyen kort og konkret. Rapportører leser den for å avgjøre om det er trygt og verdt innsatsen å rapportere til deg.

security.txt: gjør kontaktinformasjonen din lett å finne

En policy fungerer bare hvis forskere kan finne den. RFC 9116, publisert i april 2022, definerer security.txt, en liten tekstfil som serveres på /.well-known/security.txt over HTTPS.

Contact: mailto:[email protected]
Expires: 2027-09-30T23:00:00.000Z
Encryption: https://example.com/pgp-key.txt
Policy: https://example.com/security/disclosure-policy
Acknowledgments: https://example.com/security/thanks
Preferred-Languages: en
Canonical: https://example.com/.well-known/security.txt

• Påkrevd: Contact og Expires. RFC 9116 anbefaler en utløpsdato mindre enn ett år frem i tid, så filen ikke blir utdatert.
• Valgfritt: Policy, Encryption, Acknowledgments, Preferred-Languages, Canonical og Hiring.
• Signering: RFC-en anbefaler en OpenPGP-klartekstsignatur, med Canonical satt.

Legg inn en påminnelse i kalenderen før Expires-datoen. En utløpt fil forteller forskere at ingen leser.

Embargoer og tidslinjer for offentliggjøring

Embargoen er perioden mellom rapporten og publiseringen. Den mest siterte normen er policyen til Google Project Zero: Leverandører får 90 dager på å gjøre en patch tilgjengelig, og detaljene publiseres 30 dager etter at patchen er levert. En leverandør som trenger litt mer tid, kan be om en utsettelse, til maksimalt 104 dager totalt. Når en sårbarhet allerede blir utnyttet i praksis, synker fristen til 7 dager.

Din egen policy kan sette andre vilkår, og mange rapportører godtar dem. Det viktige er at tidslinjen er skrevet ned, at du holder rapportører informert, og at du ber om forlengelse før fristen, ikke etter. En advisory publisert i tide med et avbøtende tiltak er bedre enn stillhet.

CVE-ID-er og CNA-er

De fleste advisories har en CVE-ID, så kunder og verktøy kan matche dem. ID-er tildeles av CVE Numbering Authorities (CNA-er), organisasjoner med fullmakt til å tildele ID-er innenfor et avtalt omfang. Mange programvareleverandører er CNA-er for sine egne produkter, og det lar dem tildele ID-en og publisere oppføringen etter sin egen tidsplan. Hvis du ikke er det, tildeler en CNA hvis omfang dekker produktet ditt, eller en CNA of Last Resort, den.

Koordinering mellom flere parter

Noen sårbarheter berører mange leverandører samtidig: en feil i et mye brukt bibliotek, en protokoll eller en brikke. Da hjelper en koordinator med å nå hver berørte leverandør og bli enige om én publiseringsdato.

• CERT/CC, ved Software Engineering Institute på Carnegie Mellon University, koordinerer saker med flere leverandører og publiserer CVD-guiden fra CERT.
• Nasjonale CSIRT-er i EU. Under NIS2 utpeker hver medlemsstat et CSIRT som CVD-koordinator. Det fungerer som et betrodd mellomledd mellom rapportører og leverandører, forhandler frem tidslinjer for offentliggjøring, håndterer sårbarheter som berører flere enheter, og tar imot anonyme rapporter.
• ENISAs European Vulnerability Database (EUVD), opprettet under NIS2, har vært i drift siden mai 2025 og publiserer informasjon om offentlig kjente sårbarheter, også sårbarheter koordinert i EU.

ISO/IEC 29147 dekker også tilfellet der du er begge deler: en leverandør hvis produkt inneholder en annen leverandørs sårbare komponent, og som må rapportere upstream og varsle sine egne kunder.

Etter at en rapport har kommet inn

1. Bekreft mottak innen tiden policyen din lover, og gi rapportøren en sporings-ID.
2. Verifiser rapporten og vurder alvorlighetsgraden.
3. Finn ut hva som er berørt: hvert produkt, hver utgivelse og hver støttet gren som inneholder den sårbare koden eller komponenten.
4. Rett og gi ut for hver berørt gren, og hold rapportøren oppdatert.
5. Publiser advisoryen, med CVE-ID, berørte versjoner, utbedring og kreditering. Maskinlesbare advisories bruker CSAF, og VEX forteller kundene hvilke produkter som ikke er berørt.

Hele prosessen, med roller, tidsfrister og nøkkeltall, finner du i livssyklusen for sårbarhetshåndtering.

Regelverk gjør CVD-policyer obligatoriske

EUs Cyber Resilience Act krever at produsenter har en policy for koordinert offentliggjøring av sårbarheter og håndhever den, og at de oppgir en kontaktadresse for rapportering av sårbarheter, også i tredjepartskomponenter (vedlegg I del II). Disse pliktene gjelder fra 11. desember 2027; se hva CRA krever. NIS2 artikkel 21 nr. 2 bokstav e nevner håndtering og offentliggjøring av sårbarheter blant sikkerhetstiltakene vesentlige og viktige enheter må gjennomføre. I USA påla Executive Order 14028 utarbeidelse av veiledning for programvareleverandørkjeden, som omfatter deltakelse i et program for offentliggjøring av sårbarheter.

En rapport er bare så nyttig som registreringen av det du leverte

Hver rapport reiser det samme første spørsmålet: Hvilke av utgivelsene våre inneholder dette? CRACI kjører GitHub Actions-byggene dine på sine egne runnere og registrerer pakkene hver jobb faktisk hentet, inkludert transitive avhengigheter, pakker gjenopprettet fra CI-cacher og avhengigheter som ingen lockfile lister opp. Byggehistorikken viser hvilke tidligere bygg som inneholdt en sårbar avhengighet, så du vet i hvilken periode du var berørt, og inventarvisningen viser hvilke programvareversjoner som er rullet ut til hvilke produkter.

CRACI samler SBOM-er på tvers av bygg og repositorier og vurderer overvåkede SBOM-er på nytt kontinuerlig, så når en sårbarhet i en komponent med åpen kildekode publiseres, ser du alle stedene den dukker opp. Sikkerhetsteam triagerer funn og sender dem til teamene som eier rettingen, CRACI støtter VEX, og policy gates kan blokkere bygg som inneholder en bestemt CVE når den er rettet. Se sårbarhetssporing.

Koordinert offentliggjøring av sårbarheter: ofte stilte spørsmål

Hva er koordinert offentliggjøring av sårbarheter?

Koordinert offentliggjøring av sårbarheter (CVD) er prosessen der den som finner en sårbarhet, rapporterer den privat til leverandøren, leverandøren retter den, og detaljene publiseres når brukerne kan beskytte seg, vanligvis på en dato partene blir enige om. Koordinatorer som CERT/CC eller et nasjonalt CSIRT trer inn når en leverandør ikke kan nås, eller når flere leverandører er berørt.

Hva er forskjellen på et VDP og en bug bounty?

Et program for offentliggjøring av sårbarheter (VDP) forteller alle hvordan de kan rapportere en sårbarhet og hva de kan forvente, uten å betale for funn. En bug bounty betaler forskere for gyldige funn, vanligvis innenfor et definert omfang og ofte gjennom en bounty-plattform. De fleste organisasjoner begynner med et VDP; en bounty er et valgfritt tillegg oppå det, ikke en erstatning.

Hva bør en policy for offentliggjøring av sårbarheter inneholde?

Som et minimum hvordan man rapporterer: en kontaktadresse eller et skjema. ISO/IEC 29147 anbefaler også å si hva en rapport bør inneholde, hvordan man kommuniserer sikkert, hva rapportører kan forvente og når, hva som er innenfor omfanget, hvordan du publiserer advisories, og hvordan du krediterer rapportører. De fleste policyer legger til en safe harbor-erklæring og en tidslinje for offentliggjøring.

Hva er security.txt?

security.txt er en ren tekstfil definert i RFC 9116 og servert på /.well-known/security.txt. Den forteller forskere hvor de kan rapportere sårbarheter. Den må inneholde feltene Contact og Expires og kan lenke til policyen, krypteringsnøkkelen og anerkjennelsessiden din.

Hvor lang er en typisk frist for offentliggjøring?

90 dager er den mest siterte normen. Google Project Zero gir leverandører 90 dager på å gjøre en patch tilgjengelig og publiserer detaljene 30 dager etter patchen, med en frist på 7 dager når en sårbarhet allerede blir utnyttet i praksis. Din egen policy kan sette andre vilkår, og koordinatorer forhandler fra sak til sak.

Er en policy for koordinert offentliggjøring av sårbarheter obligatorisk?

I økende grad, ja. EUs Cyber Resilience Act krever at produsenter av produkter med digitale elementer har en CVD-policy og håndhever den, og at de oppgir en kontaktadresse for rapporter, og NIS2 nevner håndtering og offentliggjøring av sårbarheter blant de påkrevde sikkerhetstiltakene. Andre steder ber kunder og innkjøpsregler ofte om en.

Må jeg være CNA for å få en CVE-ID?

Nei. En CVE Numbering Authority (CNA) tildeler CVE-ID-er innenfor sitt eget omfang, og mange leverandører blir CNA-er for sine egne produkter. Hvis du ikke er det, kan en CNA hvis omfang dekker produktet ditt, eller en CNA of Last Resort, tildele ID-en.