CSAF: Common Security Advisory Framework för maskinläsbara säkerhetsmeddelanden

Vad är CSAF?

Common Security Advisory Framework (CSAF) är en standard från OASIS CSAF Technical Committee för att skriva säkerhetsmeddelanden som strukturerad JSON och distribuera dem så att de kan hittas och bearbetas automatiskt. Ett CSAF-dokument anger vilka produkter och versioner en sårbarhet påverkar, vilka som inte berörs, vilka som är åtgärdade och vad användarna ska göra.

Den aktuella versionen är CSAF 2.0, godkänd som OASIS Standard den 18 november 2022. CSAF 2.1 är på väg: dess tredje Committee Specification Draft gick igenom offentlig granskning i september 2026, och i oktober 2026 är den ännu inte en godkänd standard.

Säkerhetsmeddelanden skrivs av leverantörer, oftast av deras incidentteam för produktsäkerhet (PSIRT), och av samordnare som nationella CERT. För hur de två sorternas team skiljer sig åt, se PSIRT vs CSIRT.

Från CVRF till CSAF

CSAF växte fram ur Common Vulnerability Reporting Framework (CVRF), ett XML-format. ICASI publicerade CVRF 1.1 i maj 2012, och OASIS publicerade CVRF 1.2 i september 2017. CSAF 2.0 ersatte det med ett JSON-format, ett JSON-schema för validering, profiler för olika sorters dokument och regler för hur säkerhetsmeddelanden distribueras och hittas. Specifikationen definierar fortfarande hur CVRF-dokument konverteras till CSAF.

CSAF-dokumentets struktur

Ett CSAF-dokument har tre delar på toppnivå:

• document: metadata. Fem egenskaper är obligatoriska: kategorin (vilken profil dokumentet följer), CSAF-versionen, utgivaren, titeln och spårningsdata. Spårningsdata innehåller meddelandets id, dess status, dess version, datumen för första och aktuella utgåva samt en revisionshistorik.
• product_tree: varje produkt som dokumentet nämner, oftast som grenar från leverantör till produktnamn till version, med produkt-id:n som resten av dokumentet hänvisar till. Produkter kan också identifieras med package URL (purl), CPE eller hashvärden.
• vulnerabilities: en post per sårbarhet, med dess CVE eller andra id:n, anteckningar, poäng och en produktstatus som sorterar produkt-id:n i listor: known_affected, known_not_affected, fixed, first_affected, last_affected, first_fixed, recommended och under_investigation. Åtgärder kategoriseras som vendor_fix, workaround, mitigation, no_fix_planned eller none_available.

De fem CSAF-profilerna

Få fält är obligatoriska i CSAF som helhet. Profilerna anger vilka en viss sorts dokument måste ha, och värdet i /document/category anger vilken profil ett dokument följer:

Profil	Kategorivärde	Används för
CSAF Base	csaf_base	Miniminivån som varje CSAF-dokument uppfyller; samlingsprofilen för dokument som inte passar någon annan profil
Security incident response	csaf_security_incident_response	Hantering av ett säkerhetsintrång eller en säkerhetsincident, även hos en annan organisation
Informational advisory	csaf_informational_advisory	Problem som inte är sårbarheter, till exempel en farlig felkonfiguration
Security advisory	csaf_security_advisory	Sårbarheter och åtgärderna för dem; det klassiska säkerhetsmeddelandet från en leverantör
VEX	csaf_vex	Att ange om, och varför, varje produkt berörs eller inte berörs av en sårbarhet

Ett säkerhetsmeddelande måste ha ett produktträd, sårbarheterna, anteckningar för varje sårbarhet och en produktstatus. VEX-profilen går längre: varje produkt som listas som known_not_affected behöver en konsekvensbeskrivning, antingen som en maskinläsbar flagga eller som text, och varje known_affected-produkt behöver en åtgärd som talar om för användarna vad de ska göra.

CSAF VEX

VEX (Vulnerability Exploitability eXchange) talar om för användarna vilka sårbarheter i en produkts komponenter som faktiskt påverkar produkten. CSAF VEX är ett av tre vanliga VEX-format, vid sidan av OpenVEX och CycloneDX VEX. Dess flaggor använder samma fem motiveringar för att en produkt inte berörs som CISA:s VEX-krav, till exempel component_not_present och vulnerable_code_not_in_execute_path. Trivy och Grype läser båda CSAF VEX och tar bort fynd som markerats som ej berörda. Red Hat publicerar till exempel sina CSAF VEX-dokument i en särskild katalog bredvid sina CSAF-meddelanden.

Så distribueras CSAF-meddelanden

Ett standardformat hjälper bara om verktyg kan hitta dokumenten. Avsnitt 7 i CSAF 2.0 anger hur:

• provider-metadata.json beskriver utgivaren och var dess säkerhetsmeddelanden finns. Verktyg hittar filen på minst en av tre vägar: ett CSAF-fält i domänens security.txt, well-known-URL:en /.well-known/csaf/provider-metadata.json eller DNS-namnet csaf.data.security. framför domänen.
• Säkerhetsmeddelanden listas antingen i mappar per år med en index.txt och changes.csv, eller i ROLIE-flöden, som levereras över TLS utan omdirigeringar.
• Varje fil namnges efter sitt spårnings-id. Meddelanden med TLP:WHITE måste vara fritt tillgängliga, och meddelanden med TLP:AMBER eller TLP:RED måste ligga bakom åtkomstkontroll.
• Integritet: trusted providers lägger till ett hashvärde och en OpenPGP-signatur för varje dokument och publicerar sin offentliga nyckel.

Standarden definierar fem roller som en distribuerande part kan göra anspråk på:

Roll	Vad den gör
CSAF publisher	Publicerar giltiga CSAF-dokument, endast för egen räkning, över TLS
CSAF provider	En publisher som också erbjuder provider-metadata.json, en upptäcktsväg och en katalog eller ett ROLIE-flöde
CSAF trusted provider	En provider som också publicerar hashvärden, OpenPGP-signaturer och sin offentliga nyckel
CSAF lister	För en lista över var andra parters CSAF-dokument finns, utan att kopiera dem
CSAF aggregator	Speglar dokumenten från minst två oberoende utgivare på ett ställe, med hashvärden och signaturer

Mottagare sätter upp en nedladdare en gång och hämtar sedan nya säkerhetsmeddelanden från varje provider som deras produkter är beroende av, i stället för att bevaka dussintals leverantörers webbsidor.

Vilka som publicerar CSAF

CSAF är vanligast bland leverantörer inom industri, företagsprogramvara och infrastruktur och bland nationella CERT:

• Cisco tillhandahåller en provider-metadata.json på sin well-known-URL för CSAF.
• Siemens ProductCERT publicerar sina säkerhetsmeddelanden som ett CSAF ROLIE-flöde.
• Red Hat publicerar CSAF-meddelanden och, separat, CSAF VEX-dokument.
• BSI:s CERT-Bund, Tysklands nationella CERT, publicerar CSAF-flöden med sina säkerhetsmeddelanden.
• CISA meddelade i september 2023 att dess ICS-meddelanden kommer med CSAF-dokument, tillbaka till 2017, och uppmanade leverantörer att införa standarden.

Industriella leverantörer som arbetar enligt IEC 62443-4-1 behöver en process för att informera användare om säkerhetsproblem i sina produkter, och maskinläsbara säkerhetsmeddelanden är ett vanligt sätt att möta kundernas förväntningar.

Verktyg för CSAF

• Secvisogram är BSI:s webbeditor för CSAF-dokument, med en formulärredigerare, en JSON-editor, en HTML-förhandsvisning och validering.
• csaf-verktygen från BSI och Intevation (gocsaf/csaf, ofta kallade csaf_distribution) implementerar en trusted provider, ett kontrollverktyg, en aggregator och en nedladdare, med en CSAF 2.1-version under utveckling.
• Skannrar som Trivy och Grype läser CSAF VEX-dokument.

Så skriver du ett bra säkerhetsmeddelande

Med eller utan CSAF besvarar ett användbart säkerhetsmeddelande samma frågor. Det här är mallen som de flesta PSIRT landar i, med det CSAF-fält som innehåller varje svar:

Del av meddelandet	Vad du skriver	I CSAF
Id och titel	Ett stabilt id och en titel som anger produkten och typen av problem	tracking/id, title
Datum och revisioner	Första publicering, senaste uppdatering och vad som ändrades i varje revision	tracking-datum och revision_history
Berörda produkter	Exakta produkter och versionsintervall, inte "äldre versioner"	product_tree, known_affected
Ej berörda och åtgärdade	Vilka produkter och versioner som inte berörs, och vilka versioner som innehåller rättningen	known_not_affected, fixed, first_fixed
Sårbarhet	CVE-id:n, en tydlig beskrivning, konsekvenserna och hur den utnyttjas, utan ett recept för angripare	cve, ids, notes
Allvarlighetsgrad	En CVSS-poäng med dess vektor, så att läsarna kan kontrollera den	scores
Åtgärd	Den åtgärdade versionen, en tillfällig lösning eller begränsning, eller ett tydligt besked om att ingen rättning planeras	remediations
Erkännanden och referenser	Vem som rapporterade problemet, länkar till relaterade säkerhetsmeddelanden och rättningar	acknowledgments, references
Kontakt	Var man rapporterar problem och ställer frågor	publisher/contact_details

Några vanor skiljer ett säkerhetsmeddelande som folk agerar på från ett som de ignorerar:

• Var exakt med versioner. Det berörda intervallet är vad kunderna agerar på. Ange den första berörda och den första åtgärdade versionen för varje produktlinje.
• Säg vad som inte berörs. Kunder som kör produkter du har uteslutit slutar fråga, och deras skannrar slutar flagga dem om du också publicerar VEX.
• Uppdatera, ersätt inte. Ha ett säkerhetsmeddelande per problem och lägg till revisioner när rättningar levereras.
• Publicera på det överenskomna datumet. Säkerhetsmeddelanden är slutpunkten för samordnat offentliggörande av sårbarheter och släpps när rättningen finns tillgänglig och rapportören har informerats.

Stegen före säkerhetsmeddelandet, från mottagning och triage till rättning, beskrivs i livscykeln för sårbarhetshantering, och personerna som gör arbetet i PSIRT-rollen.

Det svåra är att veta vad som berörs

Varje säkerhetsmeddelande, i CSAF eller något annat format, hänger på ett svar: vilka produkter och versioner som innehåller den sårbara komponenten. För programvara som byggs av paket med öppen källkod innebär det att veta exakt vilka beroendeversioner som ingick i varje release, inklusive transitiva.

CRACI kör GitHub Actions-byggen på egna runners och registrerar paketen som varje jobb faktiskt hämtade, inklusive transitiva beroenden, paket som återställs från cachar och beroenden som ingen lockfile listar. När en ny sårbarhet publiceras omvärderas bevakade SBOM:er, och bygghistoriken visar vilka tidigare byggen och releaser som innehöll det sårbara beroendet, direkt eller transitivt, så att du vet under vilken period du var drabbad. Inventeringsvyn visar vilka versioner som är driftsatta i vilka produkter, och triagen skickar varje fynd till teamet som äger åtgärden. SBOM:er exporteras som CycloneDX eller SPDX, och CRACI har stöd för VEX. Se sårbarhetsspårning.

CSAF: vanliga frågor

Vad står CSAF för?

Inom säkerhet står CSAF för Common Security Advisory Framework, en OASIS-standard för att skriva säkerhetsmeddelanden som maskinläsbara JSON-dokument och distribuera dem så att verktyg kan hitta och bearbeta dem automatiskt.

Vilken är den aktuella versionen av CSAF?

CSAF 2.0, godkänd som OASIS Standard den 18 november 2022. CSAF 2.1 är på gång: dess tredje Committee Specification Draft avslutade den offentliga granskningen den 29 september 2026, och i oktober 2026 är den ännu inte en godkänd OASIS Standard.

Vad är skillnaden mellan CSAF och CVE?

En CVE-post identifierar en sårbarhet och beskriver den i allmänna termer. Ett CSAF-meddelande publiceras av en leverantör eller samordnare och anger hur den sårbarheten, och ofta flera andra, påverkar specifika produkter och versioner och vad du ska göra åt det. CSAF-meddelanden hänvisar till CVE-id:n.

Vad är CSAF VEX?

CSAF VEX är CSAF-profilen csaf_vex. Den innehåller VEX-uttalanden: för varje produkt om den berörs, inte berörs, är åtgärdad eller under utredning, med en konsekvensbeskrivning för produkter som inte berörs och en åtgärd för produkter som berörs. Trivy och Grype kan läsa den för att undertrycka fynd.

Vad är en CSAF-provider?

En CSAF-provider är en organisation som publicerar sina egna CSAF-dokument på ett sätt som verktyg kan upptäcka: en provider-metadata.json-fil, som går att hitta via security.txt, en well-known-URL eller ett DNS-namn, och en katalog eller ett ROLIE-flöde med säkerhetsmeddelanden. En trusted provider lägger till hashvärden, OpenPGP-signaturer och en publicerad offentlig nyckel.

Vad ersatte CSAF?

Common Vulnerability Reporting Framework (CVRF), ett XML-format. CVRF 1.1 publicerades av ICASI 2012 och CVRF 1.2 av OASIS 2017. CSAF 2.0 gick över till JSON och lade till profiler, produktträd och regler för distribution.

Hur skriver jag ett CSAF-meddelande?

De flesta team börjar i en editor som Secvisogram, BSI:s webbeditor för CSAF, eller genererar JSON från sin egen sårbarhetsspårning. Välj en profil, oftast csaf_security_advisory, fyll i utgivare, spårningsdata, produktträd och sårbarheter, validera mot schemat och publicera genom en provider.