CSAF: Common Security Advisory Framework for maskinlesbare advisories

Hva er CSAF?

Common Security Advisory Framework (CSAF) er en standard fra OASIS CSAF Technical Committee for å skrive sikkerhetsadvisories som strukturert JSON og distribuere dem slik at de kan finnes og behandles automatisk. Et CSAF-dokument forteller hvilke produkter og versjoner en sårbarhet berører, hvilke som ikke er berørt, hvilke som er rettet, og hva brukerne bør gjøre.

Gjeldende versjon er CSAF 2.0, godkjent som OASIS Standard 18. november 2022. CSAF 2.1 er på vei: Det tredje utkastet, Committee Specification Draft, var ute på offentlig høring i september 2026, og per oktober 2026 er det ennå ikke en godkjent standard.

Advisories skrives av leverandører, vanligvis av teamet for produktsikkerhetshendelser (PSIRT), og av koordinatorer som nasjonale CERT-er. Hvordan disse to typene team skiller seg fra hverandre, ser du i PSIRT vs. CSIRT.

Fra CVRF til CSAF

CSAF vokste ut av Common Vulnerability Reporting Framework (CVRF), et XML-format. ICASI publiserte CVRF 1.1 i mai 2012, og OASIS publiserte CVRF 1.2 i september 2017. CSAF 2.0 erstattet det med et JSON-format, et JSON-skjema for validering, profiler for ulike typer dokumenter og regler for hvordan advisories distribueres og finnes. Spesifikasjonen definerer fortsatt hvordan CVRF-dokumenter konverteres til CSAF.

Strukturen i et CSAF-dokument

Et CSAF-dokument har tre deler på øverste nivå:

• document: metadata. Fem egenskaper er obligatoriske: kategorien (hvilken profil dokumentet følger), CSAF-versjonen, utgiveren, tittelen og sporingsdata. Sporingsdataene inneholder advisory-ID-en, statusen, versjonen, første og gjeldende utgivelsesdato og en revisjonshistorikk.
• product_tree: alle produkter dokumentet nevner, vanligvis som grener fra leverandør til produktnavn til versjon, med produkt-ID-er som resten av dokumentet viser til. Produkter kan også identifiseres med package URL (purl), CPE eller hasher.
• vulnerabilities: én oppføring per sårbarhet, med CVE- eller andre ID-er, merknader, score og en produktstatus som sorterer produkt-ID-er i lister: known_affected, known_not_affected, fixed, first_affected, last_affected, first_fixed, recommended og under_investigation. Utbedringer kategoriseres som vendor_fix, workaround, mitigation, no_fix_planned eller none_available.

De fem CSAF-profilene

Få felt er obligatoriske i CSAF som helhet. Profilene sier hvilke felt en gitt type dokument må ha, og verdien av /document/category sier hvilken profil et dokument følger:

Profil	Kategoriverdi	Bruk den til
CSAF Base	csaf_base	Minstekravet alle CSAF-dokumenter oppfyller; samleprofilen for dokumenter som ikke passer i noen annen profil
Respons på sikkerhetshendelser	csaf_security_incident_response	Respons på et sikkerhetsbrudd eller en sikkerhetshendelse, også hos en annen organisasjon
Informasjonsadvisory	csaf_informational_advisory	Problemer som ikke er sårbarheter, for eksempel en farlig feilkonfigurasjon
Sikkerhetsadvisory	csaf_security_advisory	Sårbarheter og utbedringer av dem; den klassiske leverandøradvisoryen
VEX	csaf_vex	Å oppgi om, og hvorfor, hvert produkt er eller ikke er berørt av en sårbarhet

En sikkerhetsadvisory må ha et produkttre, sårbarhetene, merknader for hver sårbarhet og en produktstatus. VEX-profilen går lenger: Hvert produkt som er oppført som known_not_affected, trenger en konsekvenserklæring, enten som et maskinlesbart flagg eller som tekst, og hvert known_affected-produkt trenger en utbedring som forteller brukerne hva de skal gjøre.

CSAF VEX

VEX (Vulnerability Exploitability eXchange) forteller brukerne hvilke sårbarheter i et produkts komponenter som faktisk berører produktet. CSAF VEX er ett av tre vanlige VEX-formater, ved siden av OpenVEX og CycloneDX VEX. Flaggene bruker de samme fem begrunnelsene for ikke berørt som CISAs VEX-krav, for eksempel component_not_present og vulnerable_code_not_in_execute_path. Både Trivy og Grype leser CSAF VEX og fjerner funn det markerer som ikke berørt. Red Hat publiserer for eksempel CSAF VEX-dokumentene sine i en egen katalog ved siden av CSAF-advisoryene.

Slik distribueres CSAF-advisories

Et standardformat hjelper bare hvis verktøy kan finne dokumentene. Kapittel 7 i CSAF 2.0 beskriver hvordan:

• provider-metadata.json beskriver utgiveren og hvor advisoryene ligger. Verktøy finner filen gjennom minst én av tre ruter: et CSAF-felt i domenets security.txt, well-known-URL-en /.well-known/csaf/provider-metadata.json eller DNS-navnet csaf.data.security. foran domenet.
• Advisories listes opp enten i mapper per år med en index.txt og changes.csv, eller i ROLIE-feeder, levert over TLS uten omdirigeringer.
• Hver fil får navn etter sporings-ID-en. TLP:WHITE-advisories må være fritt tilgjengelige, og TLP:AMBER- eller TLP:RED-advisories må ligge bak tilgangskontroll.
• Integritet: Betrodde leverandører legger til en hash og en OpenPGP-signatur for hvert dokument og publiserer den offentlige nøkkelen sin.

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

Rolle	Hva den gjør
CSAF-utgiver	Publiserer gyldige CSAF-dokumenter, bare på egne vegne, over TLS
CSAF-leverandør	En utgiver som også tilbyr provider-metadata.json, en oppdagelsesrute og en katalog eller ROLIE-feed
Betrodd CSAF-leverandør	En leverandør som også publiserer hasher, OpenPGP-signaturer og den offentlige nøkkelen sin
CSAF-listefører	Fører en liste over hvor andre parters CSAF-dokumenter finnes, uten å kopiere dem
CSAF-aggregator	Speiler dokumentene til minst to uavhengige utstedere på ett sted, med hasher og signaturer

Mottakere setter opp en nedlaster én gang og henter deretter nye advisories fra alle leverandørene produktene deres er avhengige av, i stedet for å følge med på dusinvis av leverandørnettsider.

Hvem publiserer CSAF

CSAF er mest utbredt blant leverandører innen industri, bedriftsprogramvare og infrastruktur og blant nasjonale CERT-er:

• Cisco leverer en provider-metadata.json på sin well-known-URL for CSAF.
• Siemens ProductCERT publiserer advisoryene sine som en CSAF ROLIE-feed.
• Red Hat publiserer CSAF-advisories og, separat, CSAF VEX-dokumenter.
• BSIs CERT-Bund, Tysklands nasjonale CERT, publiserer CSAF-feeder med advisoryene sine.
• CISA kunngjorde i september 2023 at ICS-advisoryene deres kommer med CSAF-dokumenter, tilbake til 2017, og oppfordret leverandører til å ta i bruk standarden.

Industrielle leverandører som arbeider etter IEC 62443-4-1, trenger en prosess for å informere brukerne om sikkerhetsproblemer i produktene sine, og maskinlesbare advisories er en vanlig måte å møte kundenes forventninger på.

Verktøy for CSAF

• Secvisogram er BSIs nettbaserte editor for CSAF-dokumenter, med skjemaeditor, JSON-editor, HTML-forhåndsvisning og validering.
• csaf-verktøyene fra BSI og Intevation (gocsaf/csaf, ofte kalt csaf_distribution) implementerer en betrodd leverandør, en kontrollør, en aggregator og en nedlaster, med en versjon for CSAF 2.1 under utvikling.
• Skannere som Trivy og Grype leser CSAF VEX-dokumenter.

Slik skriver du en god sikkerhetsadvisory

Med eller uten CSAF svarer en nyttig advisory på de samme spørsmålene. Dette er malen de fleste PSIRT-er ender opp med, med CSAF-feltet som inneholder hvert svar:

Element i advisoryen	Hva du skal skrive	I CSAF
ID og tittel	En stabil advisory-ID og en tittel som navngir produktet og typen problem	tracking/id, title
Datoer og revisjoner	Først publisert, sist oppdatert og hva som ble endret i hver revisjon	tracking-datoer og revision_history
Berørte produkter	Nøyaktige produkter og versjonsområder, ikke "eldre versjoner"	product_tree, known_affected
Ikke berørt og rettet	Hvilke produkter og versjoner som ikke er berørt, og hvilke versjoner som inneholder rettingen	known_not_affected, fixed, first_fixed
Sårbarhet	CVE-ID-er, en enkel beskrivelse, konsekvensen og hvordan den utnyttes, uten en oppskrift for angripere	cve, ids, notes
Alvorlighetsgrad	En CVSS-score med vektoren, så leserne kan sjekke den	scores
Utbedring	Den rettede versjonen, en workaround eller et mottiltak, eller en tydelig opplysning om at ingen retting er planlagt	remediations
Anerkjennelser og referanser	Hvem som rapporterte det, lenker til relaterte advisories og rettinger	acknowledgments, references
Kontakt	Hvor man rapporterer problemer og stiller spørsmål	publisher/contact_details

Noen få vaner utgjør forskjellen mellom en advisory folk handler på, og en de overser:

• Vær nøyaktig med versjoner. Det berørte versjonsområdet er det kundene handler ut fra. Oppgi første berørte og første rettede versjon for hver produktlinje.
• Si hva som ikke er berørt. Kunder som kjører produkter du har utelukket, slutter å spørre, og skannerne deres slutter å flagge dem hvis du også publiserer VEX.
• Oppdater, ikke erstatt. Ha én advisory per problem, og legg til revisjoner etter hvert som rettinger leveres.
• Publiser på den avtalte datoen. Advisories er sluttpunktet for koordinert offentliggjøring av sårbarheter, og slippes når rettingen er tilgjengelig og den som rapporterte, er informert.

Stegene før advisoryen, fra mottak og triage til retting, dekkes i livssyklusen for sårbarhetshåndtering, og menneskene som gjør dette arbeidet, i PSIRT-rollen.

Det vanskelige er å vite hva som er berørt

Hver advisory, i CSAF eller et annet format, avhenger av ett svar: hvilke produkter og versjoner som inneholder den sårbare komponenten. For programvare bygget av pakker med åpen kildekode betyr det å vite nøyaktig hvilke avhengighetsversjoner som gikk inn i hver utgivelse, inkludert de transitive.

CRACI kjører GitHub Actions-bygg på egne runnere og registrerer pakkene hver jobb faktisk hentet, inkludert transitive avhengigheter, pakker gjenopprettet fra cacher og avhengigheter ingen lockfile oppgir. Når en ny sårbarhet publiseres, vurderes overvåkede SBOM-er på nytt, og byggehistorikken viser hvilke tidligere bygg og utgivelser som inneholdt den sårbare avhengigheten, direkte eller transitivt, så du vet i hvilken periode du var berørt. Inventarvisningen viser hvilke versjoner som er rullet ut til hvilke produkter, og triage sender hvert funn til teamet som eier rettingen. SBOM-er eksporteres som CycloneDX eller SPDX, og CRACI støtter VEX. Se sporing av sårbarheter.

CSAF: ofte stilte spørsmål

Hva står CSAF for?

Innen sikkerhet står CSAF for Common Security Advisory Framework, en OASIS-standard for å skrive sikkerhetsadvisories som maskinlesbare JSON-dokumenter og distribuere dem slik at verktøy kan finne og behandle dem automatisk.

Hva er gjeldende versjon av CSAF?

CSAF 2.0, godkjent som OASIS Standard 18. november 2022. CSAF 2.1 er under arbeid: Det tredje utkastet, Committee Specification Draft, var ferdig med offentlig høring 29. september 2026, og per oktober 2026 er det ennå ikke en godkjent OASIS Standard.

Hva er forskjellen på CSAF og CVE?

En CVE-oppføring identifiserer én sårbarhet og beskriver den i generelle termer. En CSAF-advisory publiseres av en leverandør eller koordinator og forteller hvordan den sårbarheten, og ofte flere andre, berører bestemte produkter og versjoner, og hva du bør gjøre. CSAF-advisories viser til CVE-ID-er.

Hva er CSAF VEX?

CSAF VEX er csaf_vex-profilen i CSAF. Den inneholder VEX-erklæringer: for hvert produkt om det er berørt, ikke berørt, rettet eller under undersøkelse, med en konsekvenserklæring for produkter som ikke er berørt, og en utbedring for produkter som er det. Trivy og Grype kan lese den for å undertrykke funn.

Hva er en CSAF-leverandør?

En CSAF-leverandør er en organisasjon som publiserer egne CSAF-dokumenter på en måte verktøy kan oppdage: en provider-metadata.json-fil, som kan finnes gjennom security.txt, en well-known-URL eller et DNS-navn, og en katalog eller ROLIE-feed med advisories. En betrodd leverandør legger til hasher, OpenPGP-signaturer og en publisert offentlig nøkkel.

Hva erstattet CSAF?

Common Vulnerability Reporting Framework (CVRF), et XML-format. CVRF 1.1 ble publisert av ICASI i 2012, og CVRF 1.2 av OASIS i 2017. CSAF 2.0 gikk over til JSON og la til profiler, produkttrær og regler for distribusjon.

Hvordan skriver jeg en CSAF-advisory?

De fleste team begynner i en editor som Secvisogram, BSIs nettbaserte editor for CSAF, eller genererer JSON-en fra sin egen sårbarhetssporing. Velg en profil, vanligvis csaf_security_advisory, fyll ut utgiver, sporingsdata, produkttre og sårbarheter, valider mot skjemaet og publiser gjennom en leverandør.