Samordnat offentliggörande av sårbarheter: så driver du ett program

Vad är samordnat offentliggörande av sårbarheter?

Samordnat offentliggörande av sårbarheter (CVD) är arbetssättet att hantera en nyupptäckt sårbarhet i förtroende mellan upphittaren och leverantören tills en åtgärd eller begränsning finns tillgänglig, och sedan publicera den. CERT Guide to Coordinated Vulnerability Disclosure beskriver det som att samla in information från dem som hittar sårbarheter, samordna hur informationen delas mellan berörda intressenter och offentliggöra sårbarheten och de åtgärder som begränsar den, även för allmänheten.

För en produktleverantör har CVD två halvor. Den utåtriktade halvan, att ta emot rapporter och publicera säkerhetsmeddelanden, är vad den här sidan handlar om. Den inåtriktade halvan, att verifiera, åtgärda och släppa, är livscykeln för sårbarhetshantering. Båda drivs oftast av ett PSIRT.

CVD, fullständigt offentliggörande och bug bounty

	Samordnat offentliggörande	Fullständigt offentliggörande	Bug bounty
Vad det är	Rapport i förtroende, åtgärd och sedan publicering vid en överenskommen tidpunkt	Upphittaren publicerar detaljerna direkt, med eller utan att informera leverantören	Ett program som betalar för giltiga fynd
Vem styr tidpunkten	Leverantören och upphittaren tillsammans, ibland med en samordnare	Upphittaren	Programmets villkor, som oftast följer CVD
Risk för användare	Lägst: detaljerna blir offentliga när det finns en åtgärd eller en tidsfrist har löpt ut	Högst: angripare får veta samtidigt som försvarare	Som för CVD
Kostnad	Personaltid för triagering och svar	Oplanerat akutarbete	Personaltid plus belöningar och ofta plattformsavgifter

En bug bounty är inget alternativ till ett program för sårbarhetsrapportering (VDP). Den är ett incitament ovanpå ett sådant. Varje leverantör behöver ett sätt för vem som helst att rapportera en sårbarhet; en bounty avgör bara om vissa rapporter ger betalt.

Vad som ingår i en policy för sårbarhetsrapportering

En policy för sårbarhetsrapportering är det offentliga dokument som anger villkoren för ditt program. ISO/IEC 29147, den internationella standarden för offentliggörande av sårbarheter, gör ett element obligatoriskt, en föredragen kontaktväg, och rekommenderar flera till. En komplett policy omfattar:

• Hur man rapporterar. En särskild adress eller ett webbformulär, och ett sätt att skicka känsliga uppgifter säkert, till exempel en publicerad krypteringsnyckel.
• Vad som ska ingå. Berörd produkt och version, steg för att återskapa problemet, påverkan och hur rapportören kan nås.
• Omfattning. Vilka produkter, versioner och tjänster som omfattas, och vilka testmetoder som inte är tillåtna, till exempel överbelastningsattacker eller åtkomst till andra användares data.
• Safe harbor. Ett åtagande att inte vidta rättsliga åtgärder mot forskning i god tro som följer policyn.
• Vad rapportörer kan förvänta sig. När du bekräftar rapporten, hur du håller dem uppdaterade och ditt tidsmål för en åtgärd.
• Tidslinje för offentliggörande. När detaljerna blir offentliga, och vad som händer om en åtgärd tar längre tid.
• Publicering. Var säkerhetsmeddelanden visas och om du tilldelar CVE-id:n.
• Erkännande. Om och hur du krediterar rapportörer, och om du betalar belöningar.

Håll policyn kort och konkret. Rapportörer läser den för att avgöra om det är säkert och värt besväret att rapportera till dig.

security.txt: gör din kontaktväg lätt att hitta

En policy fungerar bara om forskare kan hitta den. RFC 9116, publicerad i april 2022, definierar security.txt, en liten textfil som serveras på /.well-known/security.txt över 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

• Obligatoriskt: Contact och Expires. RFC 9116 rekommenderar ett utgångsdatum mindre än ett år framåt, så att filen inte blir inaktuell.
• Valfritt: Policy, Encryption, Acknowledgments, Preferred-Languages, Canonical och Hiring.
• Signering: RFC:n rekommenderar en OpenPGP-signatur i klartext, med Canonical angivet.

Lägg in en påminnelse i kalendern före datumet i Expires. En utgången fil säger till forskare att ingen läser.

Embargon och tidslinjer för offentliggörande

Embargot är perioden mellan rapporten och publiceringen. Den mest citerade normen är Google Project Zeros policy: leverantörer får 90 dagar på sig att göra en patch tillgänglig, och detaljerna publiceras 30 dagar efter att patchen levererats. En leverantör som behöver lite mer tid kan begära en respitperiod, till högst 104 dagar totalt. När en sårbarhet redan utnyttjas i det vilda sjunker tidsfristen till 7 dagar.

Din egen policy kan ange andra villkor, och många rapportörer godtar dem. Det viktiga är att tidslinjen är nedskriven, att du håller rapportörer informerade och att du begär en förlängning före tidsfristen i stället för efter. Ett säkerhetsmeddelande som publiceras enligt plan med en begränsande åtgärd är bättre än tystnad.

CVE-id:n och CNA:er

De flesta säkerhetsmeddelanden har ett CVE-id så att kunder och verktyg kan matcha dem. Id:n tilldelas av CVE Numbering Authorities (CNA:er), organisationer med behörighet att tilldela id:n inom ett överenskommet område. Många programvaruleverantörer är CNA:er för sina egna produkter, vilket gör att de kan tilldela id:t och publicera posten enligt sitt eget schema. Om du inte är det tilldelar en CNA vars område omfattar din produkt, eller en CNA of Last Resort, id:t.

Samordning mellan flera parter

Vissa sårbarheter påverkar många leverantörer samtidigt: en brist i ett allmänt använt bibliotek, ett protokoll eller ett chip. Då hjälper en samordnare till att nå alla berörda leverantörer och komma överens om ett publiceringsdatum.

• CERT/CC, vid Software Engineering Institute på Carnegie Mellon University, samordnar ärenden med flera leverantörer och publicerar CERT:s CVD-guide.
• Nationella CSIRT i EU. Enligt NIS2 utser varje medlemsstat ett CSIRT till sin CVD-samordnare. Det fungerar som en betrodd mellanhand mellan rapportörer och leverantörer, förhandlar om tidslinjer för offentliggörande, hanterar sårbarheter som påverkar flera entiteter och tar emot anonyma rapporter.
• ENISA:s European Vulnerability Database (EUVD), inrättad enligt NIS2, har varit i drift sedan maj 2025 och publicerar information om offentligt kända sårbarheter, inklusive sådana som samordnats inom EU.

ISO/IEC 29147 täcker också fallet där du är båda: en leverantör vars produkt innehåller en annan leverantörs sårbara komponent, och som måste rapportera uppströms och informera sina egna kunder.

När en rapport har kommit in

1. Bekräfta inom den tid din policy lovar, och ge rapportören ett spårnings-id.
2. Verifiera rapporten och bedöm dess allvarlighetsgrad.
3. Hitta vad som berörs: varje produkt, release och gren som stöds och som innehåller den sårbara koden eller komponenten.
4. Åtgärda och släpp för varje berörd gren, och håll rapportören uppdaterad.
5. Publicera säkerhetsmeddelandet, med ett CVE-id, berörda versioner, åtgärd och erkännande. Maskinläsbara säkerhetsmeddelanden använder CSAF, och VEX talar om för kunderna vilka produkter som inte berörs.

Hela processen, med roller, tidslinjer och mätetal, finns i livscykeln för sårbarhetshantering.

Regelverk gör CVD-policyer obligatoriska

EU:s Cyber Resilience Act kräver att tillverkare inför och tillämpar en policy för samordnat offentliggörande av sårbarheter och tillhandahåller en kontaktadress för att rapportera sårbarheter, inklusive sådana i tredjepartskomponenter (bilaga I, del II). Dessa skyldigheter gäller från den 11 december 2027; se vad CRA kräver. NIS2 artikel 21.2 e anger hantering och offentliggörande av sårbarheter bland de säkerhetsåtgärder som väsentliga och viktiga entiteter måste vidta. I USA gav Executive Order 14028 uppdrag om vägledning för programvarans leveranskedja, som omfattar deltagande i ett program för sårbarhetsrapportering.

En rapport är bara så användbar som din registrering av vad du har levererat

Varje rapport väcker samma första fråga: vilka av våra releaser innehåller det här? CRACI kör dina GitHub Actions-byggen på sina egna runners och registrerar paketen som varje jobb faktiskt hämtade, inklusive transitiva beroenden, paket som återställs från CI-cachar och beroenden som ingen lockfile listar. Bygghistoriken visar vilka tidigare byggen som innehöll ett sårbart beroende, så att du vet under vilken period du var berörd, och inventeringsvyn visar vilka programvaruversioner som är driftsatta i vilka produkter.

CRACI sammanställer SBOM:er över byggen och repon och omvärderar bevakade SBOM:er löpande, så när en sårbarhet i en komponent från öppen källkod publiceras ser du överallt där den förekommer. Säkerhetsteamen triagerar fynd och skickar dem till teamen som äger åtgärden, CRACI har stöd för VEX, och policyspärrar kan blockera byggen som innehåller en specifik CVE när den väl är åtgärdad. Se sårbarhetsspårning.

Samordnat offentliggörande av sårbarheter: vanliga frågor

Vad är samordnat offentliggörande av sårbarheter?

Samordnat offentliggörande av sårbarheter (CVD) är processen där den som hittar en sårbarhet rapporterar den i förtroende till leverantören, leverantören åtgärdar den och detaljerna publiceras när användarna kan skydda sig, oftast vid ett datum som parterna kommer överens om. Samordnare som CERT/CC eller ett nationellt CSIRT träder in när en leverantör inte går att nå eller när flera leverantörer berörs.

Vad är skillnaden mellan ett VDP och en bug bounty?

Ett program för sårbarhetsrapportering (VDP) talar om för vem som helst hur en sårbarhet rapporteras och vad man kan förvänta sig, utan att betala för fynd. En bug bounty betalar forskare för giltiga fynd, oftast inom ett definierat område och ofta via en bounty-plattform. De flesta organisationer börjar med ett VDP; en bounty är ett valfritt tillägg ovanpå det, inte en ersättning.

Vad ska en policy för sårbarhetsrapportering innehålla?

Som minimum hur man rapporterar: en kontaktadress eller ett formulär. ISO/IEC 29147 rekommenderar också att ange vad en rapport ska innehålla, hur man kommunicerar säkert, vad rapportörer kan förvänta sig och när, vad som omfattas, hur du publicerar säkerhetsmeddelanden och hur du krediterar rapportörer. De flesta policyer lägger till ett safe harbor-åtagande och en tidslinje för offentliggörande.

Vad är security.txt?

security.txt är en ren textfil som definieras i RFC 9116 och serveras på /.well-known/security.txt. Den talar om för forskare var de ska rapportera sårbarheter. Den måste innehålla fälten Contact och Expires och kan länka till din policy, krypteringsnyckel och sida med erkännanden.

Hur lång är en typisk tidsfrist för offentliggörande?

90 dagar är den mest citerade normen. Google Project Zero ger leverantörer 90 dagar på sig att göra en patch tillgänglig och publicerar detaljerna 30 dagar efter patchen, med en tidsfrist på 7 dagar när en sårbarhet redan utnyttjas i det vilda. Din egen policy kan ange andra villkor, och samordnare förhandlar från fall till fall.

Är en policy för samordnat offentliggörande obligatorisk?

I allt högre grad, ja. EU:s Cyber Resilience Act kräver att tillverkare av produkter med digitala element inför och tillämpar en CVD-policy och tillhandahåller en kontaktadress för rapporter, och NIS2 anger hantering och offentliggörande av sårbarheter bland de obligatoriska säkerhetsåtgärderna. På andra håll efterfrågar kunder och upphandlingsregler ofta en sådan policy.

Måste jag vara CNA för att få ett CVE-id?

Nej. En CVE Numbering Authority (CNA) tilldelar CVE-id:n inom sitt eget område, och många leverantörer blir CNA:er för sina egna produkter. Om du inte är det kan en CNA vars område omfattar din produkt, eller en CNA of Last Resort, tilldela id:t.