CSAF: Common Security Advisory Framework til maskinlæsbare advisories

Hvad er CSAF?

Common Security Advisory Framework (CSAF) er en standard fra OASIS CSAF Technical Committee til at skrive sikkerhedsadvisories som struktureret JSON og distribuere dem, så de kan findes og behandles automatisk. Et CSAF-dokument fortæller, hvilke produkter og versioner en sårbarhed rammer, hvilke der ikke er ramt, hvilke der er rettet, og hvad brugerne skal gøre.

Den aktuelle version er CSAF 2.0, godkendt som OASIS Standard den 18. november 2022. CSAF 2.1 er på vej: Dens tredje Committee Specification Draft var i offentlig gennemgang i september 2026, og i oktober 2026 er den endnu ikke en godkendt standard.

Advisories skrives af leverandører, som regel af deres product security incident response team (PSIRT), og af koordinatorer som nationale CERT'er. Hvordan de to slags teams adskiller sig, kan du læse i PSIRT vs CSIRT.

Fra CVRF til CSAF

CSAF udsprang af Common Vulnerability Reporting Framework (CVRF), et XML-format. ICASI udgav CVRF 1.1 i maj 2012, og OASIS udgav CVRF 1.2 i september 2017. CSAF 2.0 erstattede det med et JSON-format, et JSON-skema til validering, profiler til forskellige typer dokumenter og regler for, hvordan advisories distribueres og findes. Specifikationen definerer stadig, hvordan CVRF-dokumenter konverteres til CSAF.

Strukturen i et CSAF-dokument

Et CSAF-dokument har tre dele på øverste niveau:

• document: metadata. Fem egenskaber er obligatoriske: kategorien (hvilken profil dokumentet følger), CSAF-versionen, udgiveren, titlen og sporingsdata. Sporingsdata indeholder advisoryens ID, dens status, dens version, datoerne for første og seneste udgivelse og en revisionshistorik.
• product_tree: hvert produkt, dokumentet nævner, som regel som grene fra leverandør til produktnavn til version, med produkt-ID'er, som resten af dokumentet henviser til. Produkter kan også identificeres med package URL (purl), CPE eller hashes.
• vulnerabilities: én post pr. sårbarhed, med dens CVE eller andre ID'er, noter, scorer og en produktstatus, der sorterer produkt-ID'er i lister: known_affected, known_not_affected, fixed, first_affected, last_affected, first_fixed, recommended og under_investigation. Afhjælpninger kategoriseres som vendor_fix, workaround, mitigation, no_fix_planned eller none_available.

De fem CSAF-profiler

Få felter er obligatoriske i CSAF som helhed. Profiler angiver, hvilke felter en given type dokument skal have, og værdien af /document/category angiver, hvilken profil et dokument følger:

Profil	Kategoriværdi	Bruges til
CSAF Base	csaf_base	Det minimum, ethvert CSAF-dokument opfylder; opsamlingsprofilen for dokumenter, der ikke passer til andre profiler
Security incident response	csaf_security_incident_response	Reaktion på et sikkerhedsbrud eller en hændelse, også hos en anden organisation
Informational advisory	csaf_informational_advisory	Problemer, der ikke er sårbarheder, for eksempel en farlig fejlkonfiguration
Security advisory	csaf_security_advisory	Sårbarheder og deres afhjælpning; den klassiske leverandør-advisory
VEX	csaf_vex	Angivelse af, om og hvorfor hvert produkt er eller ikke er ramt af en sårbarhed

En security advisory skal have et produkttræ, sårbarhederne, noter for hver sårbarhed og en produktstatus. VEX-profilen går videre: Hvert produkt, der er angivet som known_not_affected, skal have en konsekvenserklæring, enten som et maskinlæsbart flag eller som tekst, og hvert known_affected-produkt skal have en afhjælpning, der fortæller brugerne, hvad de skal gøre.

CSAF VEX

VEX (Vulnerability Exploitability eXchange) fortæller brugerne, hvilke sårbarheder i et produkts komponenter der faktisk rammer produktet. CSAF VEX er et af tre almindelige VEX-formater ved siden af OpenVEX og CycloneDX VEX. Dets flag bruger de samme fem begrundelser for ikke at være ramt som CISA's VEX-krav, for eksempel component_not_present og vulnerable_code_not_in_execute_path. Både Trivy og Grype læser CSAF VEX og fjerner fund, det markerer som ikke ramt. Red Hat offentliggør for eksempel sine CSAF VEX-dokumenter i en separat mappe ved siden af sine CSAF-advisories.

Sådan distribueres CSAF-advisories

Et standardformat hjælper kun, hvis værktøjer kan finde dokumenterne. Afsnit 7 i CSAF 2.0 beskriver hvordan:

• provider-metadata.json beskriver udgiveren, og hvor dens advisories ligger. Værktøjer finder filen ad mindst én af tre veje: et CSAF-felt i domænets security.txt, den well-known URL /.well-known/csaf/provider-metadata.json eller DNS-navnet csaf.data.security. foran domænet.
• Advisories oplistes enten i mapper pr. år med en index.txt og changes.csv eller i ROLIE-feeds, serveret over TLS uden omdirigeringer.
• Hver fil navngives efter sit sporings-ID. TLP:WHITE-advisories skal være frit tilgængelige, og TLP:AMBER- eller TLP:RED-advisories skal ligge bag adgangskontrol.
• Integritet: Trusted providers tilføjer en hash og en OpenPGP-signatur for hvert dokument og offentliggør deres offentlige nøgle.

Standarden definerer fem roller, en distribuerende part kan gøre krav på:

Rolle	Hvad den gør
CSAF publisher	Offentliggør gyldige CSAF-dokumenter, kun på egne vegne, over TLS
CSAF provider	En publisher, der også tilbyder provider-metadata.json, en vej til at finde den og en mappe eller et ROLIE-feed
CSAF trusted provider	En provider, der også offentliggør hashes, OpenPGP-signaturer og sin offentlige nøgle
CSAF lister	Fører en liste over, hvor andre parters CSAF-dokumenter findes, uden at kopiere dem
CSAF aggregator	Spejler dokumenterne fra mindst to uafhængige udstedere ét sted, med hashes og signaturer

Modtagere sætter en downloader op én gang og henter derefter nye advisories fra hver provider, deres produkter afhænger af, i stedet for at holde øje med snesevis af leverandørers websider.

Hvem offentliggør CSAF

CSAF er mest udbredt blandt leverandører af industri-, enterprise- og infrastrukturprodukter og blandt nationale CERT'er:

• Cisco serverer en provider-metadata.json på sin well-known CSAF-URL.
• Siemens ProductCERT offentliggør sine advisories som et CSAF ROLIE-feed.
• Red Hat offentliggør CSAF-advisories og, separat, CSAF VEX-dokumenter.
• BSI's CERT-Bund, Tysklands nationale CERT, offentliggør CSAF-feeds med sine advisories.
• CISA meddelte i september 2023, at dets ICS-advisories leveres med CSAF-dokumenter, tilbage til 2017, og opfordrede leverandører til at tage standarden i brug.

Industrielle leverandører, der arbejder efter IEC 62443-4-1, har brug for en proces til at informere brugere om sikkerhedsproblemer i deres produkter, og maskinlæsbare advisories er en almindelig måde at imødekomme kundernes forventninger på.

CSAF-værktøjer

• Secvisogram er BSI's webeditor til CSAF-dokumenter, med en formulareditor, en JSON-editor, en HTML-forhåndsvisning og validering.
• csaf-værktøjerne fra BSI og Intevation (gocsaf/csaf, ofte kaldet csaf_distribution) implementerer en trusted provider, en checker, en aggregator og en downloader, og en CSAF 2.1-version er under udvikling.
• Scannere som Trivy og Grype bruger CSAF VEX-dokumenter.

Sådan skriver du en god sikkerhedsadvisory

Med eller uden CSAF besvarer en nyttig advisory de samme spørgsmål. Dette er den skabelon, de fleste PSIRT'er ender med, med det CSAF-felt, der rummer hvert svar:

Element i advisoryen	Hvad du skal skrive	I CSAF
ID og titel	Et stabilt advisory-ID og en titel, der nævner produktet og typen af problem	tracking/id, title
Datoer og revisioner	Første offentliggørelse, seneste opdatering, og hvad der ændrede sig i hver revision	tracking-datoer og revision_history
Ramte produkter	Præcise produkter og versionsintervaller, ikke "ældre versioner"	product_tree, known_affected
Ikke ramt og rettet	Hvilke produkter og versioner der ikke er ramt, og hvilke versioner der indeholder rettelsen	known_not_affected, fixed, first_fixed
Sårbarhed	CVE-ID'er, en letforståelig beskrivelse, konsekvensen og hvordan den udnyttes, uden en opskrift til angribere	cve, ids, notes
Alvorlighed	En CVSS-score med vektor, så læserne kan kontrollere den	scores
Afhjælpning	Den rettede version, en workaround eller en afhjælpende foranstaltning, eller en klar erklæring om, at der ikke er planlagt en rettelse	remediations
Anerkendelser og referencer	Hvem der rapporterede den, og links til relaterede advisories og rettelser	acknowledgments, references
Kontakt	Hvor man rapporterer problemer og stiller spørgsmål	publisher/contact_details

Nogle få vaner gør forskellen på en advisory, folk handler på, og en, de ignorerer:

• Vær præcis med versioner. Det ramte interval er det, kunderne handler på. Angiv den første ramte og første rettede version for hver produktlinje.
• Sig, hvad der ikke er ramt. Kunder, der kører produkter, du har udelukket, holder op med at spørge, og deres scannere holder op med at markere dem, hvis du også offentliggør VEX.
• Opdatér, erstat ikke. Hold dig til én advisory pr. problem, og tilføj revisioner, efterhånden som rettelser leveres.
• Offentliggør på den aftalte dato. Advisories er slutpunktet for koordineret offentliggørelse af sårbarheder og udgives, når rettelsen er tilgængelig, og rapportøren er blevet informeret.

Trinene før advisoryen, fra modtagelse og triage til rettelsen, er beskrevet i livscyklussen for sårbarhedsstyring, og de personer, der udfører dette arbejde, i PSIRT-rollen.

Det svære er at vide, hvad der er ramt

Enhver advisory, i CSAF eller et andet format, afhænger af ét svar: hvilke produkter og versioner der indeholder den sårbare komponent. For software bygget af open source-pakker betyder det at vide præcis, hvilke afhængighedsversioner der indgik i hver release, inklusive de transitive.

CRACI kører GitHub Actions-builds på sine egne runnere og registrerer de pakker, hvert job faktisk hentede, inklusive transitive afhængigheder, pakker gendannet fra caches og afhængigheder, som ingen lockfile angiver. Når en ny sårbarhed offentliggøres, genvurderes overvågede SBOM'er, og build-historikken viser, hvilke tidligere builds og releases der indeholdt den sårbare afhængighed, direkte eller transitivt, så du ved, i hvilken periode du var ramt. Inventarvisningen viser, hvilke versioner der er udrullet til hvilke produkter, og triage sender hvert fund til det team, der ejer rettelsen. SBOM'er eksporteres som CycloneDX eller SPDX, og CRACI understøtter VEX. Se sårbarhedssporing.

CSAF: ofte stillede spørgsmål

Hvad står CSAF for?

Inden for sikkerhed står CSAF for Common Security Advisory Framework, en OASIS-standard til at skrive sikkerhedsadvisories som maskinlæsbare JSON-dokumenter og distribuere dem, så værktøjer automatisk kan finde og behandle dem.

Hvad er den aktuelle version af CSAF?

CSAF 2.0, godkendt som OASIS Standard den 18. november 2022. CSAF 2.1 er på vej: Dens tredje Committee Specification Draft afsluttede den offentlige gennemgang den 29. september 2026, og i oktober 2026 er den endnu ikke en godkendt OASIS Standard.

Hvad er forskellen på CSAF og CVE?

En CVE-post identificerer én sårbarhed og beskriver den i generelle vendinger. En CSAF-advisory offentliggøres af en leverandør eller koordinator og fortæller, hvordan den sårbarhed, og ofte flere andre, påvirker bestemte produkter og versioner, og hvad du skal gøre. CSAF-advisories henviser til CVE-ID'er.

Hvad er CSAF VEX?

CSAF VEX er CSAF-profilen csaf_vex. Den indeholder VEX-erklæringer: for hvert produkt, om det er ramt, ikke ramt, rettet eller under undersøgelse, med en konsekvenserklæring for produkter, der ikke er ramt, og en afhjælpning for produkter, der er. Trivy og Grype kan læse den for at undertrykke fund.

Hvad er en CSAF provider?

En CSAF provider er en organisation, der offentliggør sine egne CSAF-dokumenter på en måde, værktøjer kan finde: en provider-metadata.json-fil, der kan findes via security.txt, en well-known URL eller et DNS-navn, og en mappe eller et ROLIE-feed med advisories. En trusted provider tilføjer hashes, OpenPGP-signaturer og en publiceret offentlig nøgle.

Hvad blev erstattet af CSAF?

Common Vulnerability Reporting Framework (CVRF), et XML-format. CVRF 1.1 blev udgivet af ICASI i 2012 og CVRF 1.2 af OASIS i 2017. CSAF 2.0 gik over til JSON og tilføjede profiler, produkttræer og regler for distribution.

Hvordan skriver jeg en CSAF-advisory?

De fleste teams starter i en editor som Secvisogram, BSI's webeditor til CSAF, eller genererer JSON'en fra deres egen sårbarhedssporing. Vælg en profil, som regel csaf_security_advisory, udfyld udgiver, sporingsdata, produkttræ og sårbarheder, validér mod skemaet, og offentliggør gennem en provider.