Koordineret offentliggørelse af sårbarheder: sådan driver du et disclosure-program

Hvad er koordineret offentliggørelse af sårbarheder?

Coordinated vulnerability disclosure (CVD), koordineret offentliggørelse af sårbarheder, er praksissen med at håndtere en nyfundet sårbarhed privat mellem finderen og leverandøren, indtil en rettelse eller afhjælpende foranstaltning er tilgængelig, og derefter offentliggøre den. CERT Guide to Coordinated Vulnerability Disclosure beskriver det som at indsamle oplysninger fra dem, der finder sårbarheder, koordinere delingen af de oplysninger mellem de relevante interessenter og offentliggøre sårbarheden og dens afhjælpende foranstaltninger, også over for offentligheden.

For en produktleverandør har CVD to halvdele. Den udadrettede halvdel, at modtage rapporter og offentliggøre advisories, er det, denne side handler om. Den indadrettede halvdel, at verificere, rette og udgive, er livscyklussen for sårbarhedsstyring. Begge drives som regel af en PSIRT.

CVD vs full disclosure vs bug bounty

	Koordineret offentliggørelse	Full disclosure	Bug bounty
Hvad det er	Privat rapport, rettelse og derefter offentliggørelse på et aftalt tidspunkt	Finderen offentliggør detaljerne med det samme, med eller uden at fortælle leverandøren det	Et program, der betaler for gyldige fund
Hvem styrer timingen	Leverandør og finder i fællesskab, nogle gange med en koordinator	Finderen	Programmets vilkår, som regel efter CVD
Risiko for brugerne	Lavest: Detaljerne bliver offentlige, når en rettelse findes, eller en frist udløber	Højest: Angribere hører om det samtidig med forsvarerne	Som ved CVD
Omkostning	Medarbejdertid til triage og svar	Uplanlagt nødarbejde	Medarbejdertid plus belønninger og ofte platformgebyrer

En bug bounty er ikke et alternativ til et vulnerability disclosure program (VDP). Den er et incitament oven på et sådant program. Enhver leverandør skal have en måde, så alle kan rapportere en sårbarhed; en bounty afgør kun, om der betales for nogle rapporter.

Hvad der hører til i en disclosure-politik

En disclosure-politik er det offentlige dokument, der fastsætter vilkårene for dit program. ISO/IEC 29147, den internationale standard for offentliggørelse af sårbarheder, gør ét element obligatorisk, en foretrukken kontaktmulighed, og anbefaler flere andre. En komplet politik dækker:

• Hvordan man rapporterer. En dedikeret adresse eller webformular og en måde at sende følsomme detaljer sikkert på, for eksempel en offentliggjort krypteringsnøgle.
• Hvad rapporten skal indeholde. Berørt produkt og version, trin til at genskabe problemet, konsekvens, og hvordan rapportøren kan kontaktes.
• Omfang. Hvilke produkter, versioner og tjenester der er dækket, og hvilke testmetoder der er forbudte, for eksempel denial of service eller adgang til andre brugeres data.
• Safe harbor. Et løfte om ikke at gå rettens vej mod forskning i god tro, der følger politikken.
• Hvad rapportører kan forvente. Hvornår du bekræfter rapporten, hvordan du holder dem opdateret, og dit mål for, hvor hurtigt en rettelse er klar.
• Tidsplan for offentliggørelse. Hvornår detaljerne bliver offentlige, og hvad der sker, hvis en rettelse tager længere tid.
• Offentliggørelse. Hvor advisories vises, og om du tildeler CVE-id'er.
• Anerkendelse. Om og hvordan du krediterer rapportører, og om du betaler bounties.

Hold politikken kort og konkret. Rapportører læser den for at afgøre, om det er sikkert og umagen værd at rapportere til dig.

security.txt: gør din kontakt let at finde

En politik virker kun, hvis forskere kan finde den. RFC 9116, offentliggjort i april 2022, definerer security.txt, en lille tekstfil, der 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åkrævet: Contact og Expires. RFC 9116 anbefaler en udløbsdato mindre end et år ude i fremtiden, så filen ikke bliver forældet.
• Valgfrit: Policy, Encryption, Acknowledgments, Preferred-Languages, Canonical og Hiring.
• Signering: RFC'en anbefaler en OpenPGP-klartekstsignatur med Canonical angivet.

Sæt en påmindelse i kalenderen før datoen i Expires. En udløbet fil fortæller forskere, at ingen læser med.

Embargoer og frister for offentliggørelse

Embargoen er perioden mellem rapporten og offentliggørelsen. Den mest citerede norm er Google Project Zeros politik: Leverandører får 90 dage til at gøre en patch tilgængelig, og detaljerne offentliggøres 30 dage efter, at patchen er leveret. En leverandør, der har brug for lidt mere tid, kan bede om henstand, så fristen bliver højst 104 dage i alt. Når en sårbarhed allerede bliver udnyttet i praksis, falder fristen til 7 dage.

Din egen politik kan fastsætte andre vilkår, og mange rapportører accepterer dem. Det vigtige er, at tidsplanen er skrevet ned, at du holder rapportører informeret, og at du beder om en forlængelse før fristen og ikke efter. En advisory offentliggjort til tiden med en afhjælpende foranstaltning er bedre end tavshed.

CVE-id'er og CNA'er

De fleste advisories har et CVE-id, så kunder og værktøjer kan matche dem. Id'er tildeles af CVE Numbering Authorities (CNA'er), organisationer med tilladelse til at tildele id'er inden for et aftalt område. Mange softwareleverandører er CNA'er for deres egne produkter, så de kan tildele id'et og offentliggøre posten efter deres egen tidsplan. Er du ikke det, tildeler en CNA, hvis område dækker dit produkt, eller en CNA of Last Resort det.

Koordinering mellem flere parter

Nogle sårbarheder berører mange leverandører på én gang: en fejl i et meget brugt bibliotek, en protokol eller en chip. Så hjælper en koordinator med at nå alle berørte leverandører og aftale én dato for offentliggørelse.

• CERT/CC ved Carnegie Mellon Universitys Software Engineering Institute koordinerer sager med flere leverandører og udgiver CERT's CVD-guide.
• Nationale CSIRT'er i EU. Under NIS2 udpeger hver medlemsstat en CSIRT som sin CVD-koordinator. Den fungerer som en betroet mellemmand mellem rapportører og leverandører, forhandler frister for offentliggørelse, håndterer sårbarheder, der berører flere enheder, og modtager anonyme rapporter.
• ENISA's European Vulnerability Database (EUVD), oprettet under NIS2, har været i drift siden maj 2025 og offentliggør oplysninger om offentligt kendte sårbarheder, herunder dem, der er koordineret i EU.

ISO/IEC 29147 dækker også det tilfælde, hvor du er begge dele: en leverandør, hvis produkt indeholder en anden leverandørs sårbare komponent, og som skal rapportere upstream og informere sine egne kunder.

Når en rapport er kommet ind

1. Bekræft inden for den tid, din politik lover, og giv rapportøren et sporings-id.
2. Verificér rapporten, og vurdér dens alvorlighed.
3. Find, hvad der er berørt: hvert produkt, hver release og hver understøttet branch, der indeholder den sårbare kode eller komponent.
4. Ret og udgiv for hver berørt branch, og hold rapportøren opdateret.
5. Offentliggør advisoryen med CVE-id, berørte versioner, afhjælpning og kreditering. Maskinlæsbare advisories bruger CSAF, og VEX fortæller kunderne, hvilke produkter der ikke er berørt.

Hele processen, med roller, frister og målepunkter, finder du i livscyklussen for sårbarhedsstyring.

Lovgivning gør CVD-politikker obligatoriske

EU's Cyber Resilience Act kræver, at producenter indfører og håndhæver en politik for koordineret offentliggørelse af sårbarheder og oplyser en kontaktadresse til rapportering af sårbarheder, også dem i tredjepartskomponenter (bilag I, del II). Disse forpligtelser gælder fra 11. december 2027; se hvad CRA kræver. NIS2 artikel 21, stk. 2, litra e, nævner håndtering og offentliggørelse af sårbarheder blandt de sikkerhedsforanstaltninger, væsentlige og vigtige enheder skal træffe. I USA krævede Executive Order 14028 vejledning om softwareforsyningskæden, der omfatter deltagelse i et vulnerability disclosure program.

En rapport er kun så nyttig som din registrering af det leverede

Hver rapport rejser det samme første spørgsmål: Hvilke af vores releases indeholder det her? CRACI kører dine GitHub Actions-builds på sine egne runnere og registrerer de pakker, hvert job faktisk hentede, inklusive transitive afhængigheder, pakker gendannet fra CI-caches og afhængigheder, som ingen lockfile angiver. Build-historikken viser, hvilke tidligere builds der indeholdt en sårbar afhængighed, så du ved, i hvilken periode du var berørt, og inventarvisningen viser, hvilke softwareversioner der er installeret på hvilke produkter.

CRACI samler SBOM'er på tværs af builds og repositories og genvurderer løbende overvågede SBOM'er, så du, når en sårbarhed i en open source-komponent er offentliggjort, kan se alle de steder, den optræder. Sikkerhedsteams triagerer fund og sender dem til de teams, der ejer rettelsen, CRACI understøtter VEX, og policy gates kan blokere builds, der indeholder en bestemt CVE, når den er rettet. Se sårbarhedssporing.

Koordineret offentliggørelse af sårbarheder: ofte stillede spørgsmål

Hvad er koordineret offentliggørelse af sårbarheder?

Koordineret offentliggørelse af sårbarheder (CVD) er den proces, hvor den, der finder en sårbarhed, rapporterer den privat til leverandøren, leverandøren retter den, og detaljerne offentliggøres, når brugerne kan beskytte sig, som regel på en dato, parterne aftaler. Koordinatorer som CERT/CC eller en national CSIRT træder til, når en leverandør ikke kan nås, eller flere leverandører er berørt.

Hvad er forskellen på et VDP og en bug bounty?

Et vulnerability disclosure program (VDP) fortæller alle, hvordan de rapporterer en sårbarhed, og hvad de kan forvente, uden at betale for fund. En bug bounty betaler forskere for gyldige fund, som regel inden for et defineret omfang og ofte via en bounty-platform. De fleste organisationer starter med et VDP; en bounty er en valgfri tilføjelse oven på det, ikke en erstatning.

Hvad skal en disclosure-politik indeholde?

Som minimum hvordan man rapporterer: en kontaktadresse eller formular. ISO/IEC 29147 anbefaler også at angive, hvad en rapport skal indeholde, hvordan man kommunikerer sikkert, hvad rapportører kan forvente og hvornår, hvad der er omfattet, hvordan du offentliggør advisories, og hvordan du krediterer rapportører. De fleste politikker tilføjer en safe harbor-erklæring og en tidsplan for offentliggørelse.

Hvad er security.txt?

security.txt er en ren tekstfil defineret i RFC 9116 og serveret på /.well-known/security.txt. Den fortæller forskere, hvor de kan rapportere sårbarheder. Den skal indeholde felterne Contact og Expires og kan linke til din politik, krypteringsnøgle og anerkendelsesside.

Hvor lang er en typisk frist for offentliggørelse?

90 dage er den mest citerede norm. Google Project Zero giver leverandører 90 dage til at gøre en patch tilgængelig og offentliggør detaljerne 30 dage efter patchen, med en frist på 7 dage, når en sårbarhed allerede bliver udnyttet i praksis. Din egen politik kan fastsætte andre vilkår, og koordinatorer forhandler fra sag til sag.

Er en politik for koordineret offentliggørelse af sårbarheder obligatorisk?

I stigende grad, ja. EU's Cyber Resilience Act kræver, at producenter af produkter med digitale elementer indfører og håndhæver en CVD-politik og oplyser en kontaktadresse til rapporter, og NIS2 nævner håndtering og offentliggørelse af sårbarheder blandt de påkrævede sikkerhedsforanstaltninger. Andre steder beder kunder og indkøbsregler ofte om en.

Skal jeg være CNA for at få et CVE-id?

Nej. En CVE Numbering Authority (CNA) tildeler CVE-id'er inden for sit eget område, og mange leverandører bliver CNA'er for deres egne produkter. Er du ikke CNA, kan en CNA, hvis område dækker dit produkt, eller en CNA of Last Resort tildele id'et.