CSAF: das Common Security Advisory Framework für maschinenlesbare Advisories

Was ist CSAF?

Das Common Security Advisory Framework (CSAF) ist ein Standard des OASIS CSAF Technical Committee, mit dem sich Security Advisories als strukturiertes JSON schreiben und so verteilen lassen, dass sie automatisch gefunden und verarbeitet werden können. Ein CSAF-Dokument sagt, welche Produkte und Versionen eine Schwachstelle betrifft, welche nicht betroffen sind, welche behoben sind und was Nutzer tun sollten.

Die aktuelle Version ist CSAF 2.0, am 18. November 2022 als OASIS Standard verabschiedet. CSAF 2.1 ist unterwegs: Sein dritter Committee Specification Draft durchlief im September 2026 die öffentliche Prüfung, und Stand Oktober 2026 ist es noch kein verabschiedeter Standard.

Advisories schreiben Hersteller, meist ihr Product Security Incident Response Team (PSIRT), sowie Koordinatoren wie nationale CERTs. Wie sich diese beiden Arten von Teams unterscheiden, lesen Sie unter PSIRT vs. CSIRT.

Von CVRF zu CSAF

CSAF ging aus dem Common Vulnerability Reporting Framework (CVRF) hervor, einem XML-Format. ICASI veröffentlichte CVRF 1.1 im Mai 2012, OASIS veröffentlichte CVRF 1.2 im September 2017. CSAF 2.0 ersetzte es durch ein JSON-Format, ein JSON-Schema zur Validierung, Profile für verschiedene Dokumentarten und Regeln dafür, wie Advisories verteilt und gefunden werden. Die Spezifikation legt weiterhin fest, wie sich CVRF-Dokumente in CSAF umwandeln lassen.

Aufbau eines CSAF-Dokuments

Ein CSAF-Dokument besteht auf oberster Ebene aus drei Teilen:

• document: Metadaten. Fünf Eigenschaften sind Pflicht: die Kategorie (welchem Profil das Dokument folgt), die CSAF-Version, der Herausgeber, der Titel und die Tracking-Daten. Das Tracking enthält die Advisory-ID, ihren Status, ihre Version, das erste und das aktuelle Veröffentlichungsdatum und eine Revisionshistorie.
• product_tree: jedes im Dokument erwähnte Produkt, meist als Zweige vom Hersteller über den Produktnamen bis zur Version, mit Produkt-IDs, auf die sich der Rest des Dokuments bezieht. Produkte lassen sich auch über Package URL (purl), CPE oder Hashes identifizieren.
• vulnerabilities: ein Eintrag pro Schwachstelle, mit ihrer CVE- oder anderen IDs, Hinweisen, Scores und einem Produktstatus, der Produkt-IDs in Listen einsortiert: known_affected, known_not_affected, fixed, first_affected, last_affected, first_fixed, recommended und under_investigation. Behebungen werden als vendor_fix, workaround, mitigation, no_fix_planned oder none_available kategorisiert.

Die fünf CSAF-Profile

In CSAF insgesamt sind nur wenige Felder Pflicht. Profile legen fest, welche Felder eine bestimmte Dokumentart haben muss, und der Wert von /document/category sagt, welchem Profil ein Dokument folgt:

Profil	Wert der Kategorie	Einsatzzweck
CSAF Base	csaf_base	Das Minimum, das jedes CSAF-Dokument erfüllt; das Auffangprofil für Dokumente, die in kein anderes Profil passen
Security Incident Response	csaf_security_incident_response	Die Reaktion auf eine Sicherheitsverletzung oder einen Vorfall, auch bei einer anderen Organisation
Informational Advisory	csaf_informational_advisory	Probleme, die keine Schwachstellen sind, etwa eine gefährliche Fehlkonfiguration
Security Advisory	csaf_security_advisory	Schwachstellen und ihre Behebung; das klassische Hersteller-Advisory
VEX	csaf_vex	Die Aussage, ob und warum jedes Produkt von einer Schwachstelle betroffen ist oder nicht

Ein Security Advisory muss einen Produktbaum, die Schwachstellen, Hinweise zu jeder Schwachstelle und einen Produktstatus enthalten. Das VEX-Profil geht weiter: Jedes als known_not_affected aufgeführte Produkt braucht eine Auswirkungsaussage, entweder als maschinenlesbares Flag oder als Text, und jedes known_affected-Produkt braucht eine Behebung, die Nutzern sagt, was zu tun ist.

CSAF VEX

VEX (Vulnerability Exploitability eXchange) sagt Nutzern, welche Schwachstellen in den Komponenten eines Produkts das Produkt tatsächlich betreffen. CSAF VEX ist neben OpenVEX und CycloneDX VEX eines von drei gängigen VEX-Formaten. Seine Flags verwenden dieselben fünf Begründungen für „nicht betroffen“ wie die VEX-Anforderungen von CISA, etwa component_not_present und vulnerable_code_not_in_execute_path. Trivy und Grype lesen beide CSAF VEX und verwerfen Befunde, die es als nicht betroffen kennzeichnet. Red Hat zum Beispiel veröffentlicht seine CSAF-VEX-Dokumente in einem eigenen Verzeichnis neben seinen CSAF-Advisories.

Wie CSAF-Advisories verteilt werden

Ein Standardformat hilft nur, wenn Tools die Dokumente finden können. Abschnitt 7 von CSAF 2.0 legt fest, wie:

• provider-metadata.json beschreibt den Herausgeber und wo seine Advisories liegen. Tools finden die Datei über mindestens einen von drei Wegen: ein CSAF-Feld in der security.txt der Domain, die Well-known-URL /.well-known/csaf/provider-metadata.json oder den DNS-Namen csaf.data.security. vor der Domain.
• Advisories werden aufgelistet, entweder in Ordnern pro Jahr mit einer index.txt und changes.csv oder in ROLIE-Feeds, ausgeliefert über TLS ohne Weiterleitungen.
• Jede Datei ist nach ihrer Tracking-ID benannt. TLP:WHITE-Advisories müssen frei zugänglich sein, TLP:AMBER- oder TLP:RED-Advisories müssen hinter einer Zugriffskontrolle liegen.
• Integrität: Trusted Provider ergänzen für jedes Dokument einen Hash und eine OpenPGP-Signatur und veröffentlichen ihren öffentlichen Schlüssel.

Der Standard definiert fünf Rollen, die eine verteilende Partei beanspruchen kann:

Rolle	Was sie tut
CSAF Publisher	Veröffentlicht gültige CSAF-Dokumente, nur im eigenen Namen, über TLS
CSAF Provider	Ein Publisher, der zusätzlich provider-metadata.json, einen Weg zum Auffinden und ein Verzeichnis oder einen ROLIE-Feed anbietet
CSAF Trusted Provider	Ein Provider, der zusätzlich Hashes, OpenPGP-Signaturen und seinen öffentlichen Schlüssel veröffentlicht
CSAF Lister	Führt eine Liste, wo CSAF-Dokumente anderer Parteien zu finden sind, ohne sie zu kopieren
CSAF Aggregator	Spiegelt die Dokumente von mindestens zwei unabhängigen Herausgebern an einem Ort, mit Hashes und Signaturen

Konsumenten richten einmalig einen Downloader ein und rufen dann neue Advisories von jedem Provider ab, von dem ihre Produkte abhängen, statt Dutzende Webseiten von Herstellern zu beobachten.

Wer CSAF veröffentlicht

Am weitesten verbreitet ist CSAF bei Herstellern für Industrie, Unternehmen und Infrastruktur sowie bei nationalen CERTs:

• Cisco stellt eine provider-metadata.json unter seiner Well-known-URL für CSAF bereit.
• Siemens ProductCERT veröffentlicht seine Advisories als CSAF-ROLIE-Feed.
• Red Hat veröffentlicht CSAF-Advisories und, getrennt davon, CSAF-VEX-Dokumente.
• CERT-Bund des BSI, das nationale CERT Deutschlands, veröffentlicht CSAF-Feeds seiner Advisories.
• CISA gab im September 2023 bekannt, dass seine ICS-Advisories mit CSAF-Dokumenten erscheinen, rückwirkend bis 2017, und forderte Hersteller auf, den Standard zu übernehmen.

Industriezulieferer, die nach IEC 62443-4-1 arbeiten, brauchen einen Prozess, um Nutzer über Sicherheitsprobleme in ihren Produkten zu informieren, und maschinenlesbare Advisories sind ein gängiger Weg, die Erwartungen ihrer Kunden zu erfüllen.

Tools für CSAF

• Secvisogram ist der Web-Editor des BSI für CSAF-Dokumente, mit Formular-Editor, JSON-Editor, HTML-Vorschau und Validierung.
• Die csaf-Tools von BSI und Intevation (gocsaf/csaf, oft csaf_distribution genannt) implementieren einen Trusted Provider, einen Checker, einen Aggregator und einen Downloader; eine Version für CSAF 2.1 ist in Entwicklung.
• Scanner wie Trivy und Grype verarbeiten CSAF-VEX-Dokumente.

Ein gutes Security Advisory schreiben

Mit oder ohne CSAF beantwortet ein nützliches Advisory dieselben Fragen. Dies ist die Vorlage, auf die sich die meisten PSIRTs einpendeln, mit dem CSAF-Feld, das die jeweilige Antwort enthält:

Bestandteil des Advisorys	Was hineingehört	In CSAF
ID und Titel	Eine stabile Advisory-ID und ein Titel, der das Produkt und die Art des Problems nennt	tracking/id, title
Daten und Revisionen	Erstveröffentlichung, letzte Aktualisierung und was sich in jeder Revision geändert hat	tracking-Daten und revision_history
Betroffene Produkte	Genaue Produkte und Versionsbereiche, nicht „ältere Versionen“	product_tree, known_affected
Nicht betroffen und behoben	Welche Produkte und Versionen nicht betroffen sind und welche Versionen den Fix enthalten	known_not_affected, fixed, first_fixed
Schwachstelle	CVE-IDs, eine verständliche Beschreibung, die Auswirkung und wie sie ausgenutzt wird, ohne Anleitung für Angreifer	cve, ids, notes
Schweregrad	Ein CVSS-Score mit Vektor, damit Leser ihn prüfen können	scores
Behebung	Die behobene Version, ein Workaround oder eine Mitigation oder die klare Aussage, dass kein Fix geplant ist	remediations
Danksagungen und Referenzen	Wer es gemeldet hat, Links zu verwandten Advisories und Fixes	acknowledgments, references
Kontakt	Wo sich Probleme melden und Fragen stellen lassen	publisher/contact_details

Einige Gewohnheiten machen den Unterschied zwischen einem Advisory, auf das Menschen reagieren, und einem, das sie ignorieren:

• Seien Sie bei Versionen genau. Nach dem betroffenen Bereich richten sich Kunden. Nennen Sie für jede Produktlinie die erste betroffene und die erste behobene Version.
• Sagen Sie, was nicht betroffen ist. Kunden mit Produkten, die Sie ausgeschlossen haben, hören auf nachzufragen, und ihre Scanner melden sie nicht mehr, wenn Sie auch VEX veröffentlichen.
• Aktualisieren statt ersetzen. Führen Sie ein Advisory pro Problem und ergänzen Sie Revisionen, wenn Fixes ausgeliefert werden.
• Veröffentlichen Sie zum vereinbarten Datum. Advisories sind der Endpunkt der koordinierten Offenlegung von Schwachstellen und erscheinen, wenn der Fix verfügbar ist und die meldende Person informiert wurde.

Die Schritte vor dem Advisory, von der Annahme und Triage bis zum Fix, behandelt der Lebenszyklus des Schwachstellenmanagements, und die Menschen, die diese Arbeit leisten, die Seite zur PSIRT-Rolle.

Das Schwierige ist zu wissen, was betroffen ist

Jedes Advisory, ob in CSAF oder einem anderen Format, hängt von einer Antwort ab: Welche Produkte und Versionen enthalten die verwundbare Komponente? Bei Software aus Open-Source-Paketen heißt das zu wissen, welche Abhängigkeitsversionen genau in jedes Release eingeflossen sind, einschließlich der transitiven.

CRACI führt GitHub-Actions-Builds auf eigenen Runnern aus und zeichnet die Pakete auf, die jeder Job tatsächlich geladen hat, einschließlich transitiver Abhängigkeiten, aus Caches wiederhergestellter Pakete und Abhängigkeiten, die in keinem Lockfile stehen. Wird eine neue Schwachstelle veröffentlicht, werden überwachte SBOMs neu bewertet, und die Build-Historie zeigt, welche früheren Builds und Releases die verwundbare Abhängigkeit direkt oder transitiv enthielten, sodass Sie den Zeitraum kennen, in dem Sie betroffen waren. Die Inventaransicht zeigt, welche Versionen auf welchen Produkten im Einsatz sind, und die Triage leitet jeden Befund an das Team weiter, das für den Fix zuständig ist. SBOMs lassen sich als CycloneDX oder SPDX exportieren, und CRACI unterstützt VEX. Siehe Schwachstellenverfolgung.

CSAF: häufig gestellte Fragen

Wofür steht CSAF?

Im Sicherheitsbereich steht CSAF für das Common Security Advisory Framework, einen OASIS-Standard, mit dem sich Security Advisories als maschinenlesbare JSON-Dokumente schreiben und so verteilen lassen, dass Tools sie automatisch finden und verarbeiten können.

Was ist die aktuelle Version von CSAF?

CSAF 2.0, am 18. November 2022 als OASIS Standard verabschiedet. CSAF 2.1 ist in Arbeit: Die öffentliche Prüfung des dritten Committee Specification Draft endete am 29. September 2026, und Stand Oktober 2026 ist CSAF 2.1 noch kein verabschiedeter OASIS Standard.

Was ist der Unterschied zwischen CSAF und CVE?

Ein CVE-Eintrag identifiziert eine Schwachstelle und beschreibt sie allgemein. Ein CSAF-Advisory wird von einem Hersteller oder Koordinator veröffentlicht und sagt, wie sich diese Schwachstelle, oft auch mehrere weitere, auf bestimmte Produkte und Versionen auswirkt und was zu tun ist. CSAF-Advisories verweisen auf CVE-IDs.

Was ist CSAF VEX?

CSAF VEX ist das Profil csaf_vex von CSAF. Es enthält VEX-Aussagen: für jedes Produkt, ob es betroffen, nicht betroffen, behoben oder in Untersuchung ist, mit einer Auswirkungsaussage für nicht betroffene Produkte und einer Behebung für betroffene. Trivy und Grype können es lesen, um Befunde zu unterdrücken.

Was ist ein CSAF Provider?

Ein CSAF Provider ist eine Organisation, die ihre eigenen CSAF-Dokumente so veröffentlicht, dass Tools sie finden können: mit einer Datei provider-metadata.json, auffindbar über security.txt, eine Well-known-URL oder einen DNS-Namen, und einem Verzeichnis oder ROLIE-Feed mit Advisories. Ein Trusted Provider ergänzt Hashes, OpenPGP-Signaturen und einen veröffentlichten öffentlichen Schlüssel.

Was hat CSAF abgelöst?

Das Common Vulnerability Reporting Framework (CVRF), ein XML-Format. CVRF 1.1 wurde 2012 von ICASI veröffentlicht, CVRF 1.2 im Jahr 2017 von OASIS. CSAF 2.0 wechselte zu JSON und ergänzte Profile, Produktbäume und Verteilungsregeln.

Wie schreibe ich ein CSAF-Advisory?

Die meisten Teams beginnen in einem Editor wie Secvisogram, dem Web-Editor des BSI für CSAF, oder erzeugen das JSON aus ihrem eigenen Schwachstellen-Tracking. Wählen Sie ein Profil, meist csaf_security_advisory, tragen Sie Herausgeber, Tracking-Daten, Produktbaum und Schwachstellen ein, validieren Sie das Dokument gegen das Schema und veröffentlichen Sie es über einen Provider.