Jahrzehntelang war die Sicherheitsmeldung ein PDF oder eine hastig formatierte HTML-Seite, tief auf der Website eines Herstellers vergraben. Ein Sicherheitsingenieur in einem Unternehmen musste diese Textdokumente manuell lesen, die betroffenen Produktversionen deuten und diese Informationen manuell mit dem internen Asset-Inventar seines Unternehmens abgleichen, um festzustellen, ob er patchen musste.
Dieser manuelle, menschenzentrierte Ansatz der Schwachstellenoffenlegung ist langsam, fehleranfällig und in einer Ära komplexer Software-Lieferketten völlig nicht skalierbar.
Der Cyber Resilience Act (CRA) der Europäischen Union ermutigt Hersteller ausdrücklich, Schwachstellenoffenlegungen in maschinenlesbaren Formaten herauszugeben. Hier kommt CSAF (Common Security Advisory Framework) ins Spiel, der von OASIS entwickelte Standard, der rasch zur universellen Sprache für die automatisierte Schwachstellenkommunikation wird.
Hier ist eine technische Tiefenanalyse dessen, was CSAF ist, wie es funktioniert und warum Ihr Entwicklungsteam mit der Erstellung beginnen muss.
Was ist CSAF?
Das Common Security Advisory Framework (CSAF) Version 2.0 ist ein streng definiertes JSON-Schema zur Erstellung maschinenlesbarer Sicherheitsmeldungen.
Statt einen Absatz zu schreiben mit „Unser Routermodell X ist in den Firmware-Versionen 1.2 bis 1.4 für einen XSS-Fehler anfällig“, kodiert ein CSAF-Dokument diese Aussage in eine strukturierte JSON-Nutzlast. Das erlaubt es automatisierten Schwachstellenmanagement-Systemen, Asset-Scannern und Continuous-Integration-Pipelines, die Meldung sofort einzulesen und verwundbare Assets in einem Netzwerk automatisch zu kennzeichnen, ohne menschliches Zutun.
Derzeit definiert CSAF drei primäre Dokumentprofile:
- Sicherheitsmeldung (Security Advisory): Das Standardprofil, das eine Schwachstelle, ihren CVSS-Wert und Behebungsschritte darlegt.
- Vulnerability Exploitability eXchange (VEX): Ein spezialisiertes Profil, das aussagt, ob ein Produkt tatsächlich von einer bekannten Schwachstelle in einer seiner Komponenten betroffen ist (z. B. „Ja, wir liefern die verwundbare Log4j-Bibliothek aus, aber unsere Konfiguration macht eine Ausnutzung unmöglich; daher Status: nicht betroffen“).
- Informationsmeldung (Informational Advisory): Verwendet für allgemeine Sicherheitsupdates oder Bulletins, die keine spezifischen Schwachstellen betreffen.
Die Anatomie eines CSAF-2.0-JSON-Dokuments
Ein CSAF-JSON-Dokument ist um drei verpflichtende Objekte auf oberster Ebene strukturiert: document, product_tree und vulnerabilities. Schauen wir uns eine vereinfachte Kernstruktur an.
{
"document": { ... },
"product_tree": { ... },
"vulnerabilities": [ ... ]
}
1. Das document-Objekt (Metadaten)
Dieser Abschnitt enthält die administrativen Metadaten über die Meldung selbst. Er legt fest, wer die Information veröffentlicht, wann sie veröffentlicht wurde und wie Aktualisierungen verfolgt werden.
"document": {
"category": "csaf_security_advisory",
"csaf_version": "2.0",
"publisher": {
"category": "vendor",
"name": "Acme Widgets Corp",
"namespace": "https://acmewidgets.com"
},
"title": "Buffer Overflow in Widget-Manager API",
"tracking": {
"current_release_date": "2025-02-15T12:00:00Z",
"id": "ACME-SA-2025-001",
"initial_release_date": "2025-02-15T12:00:00Z",
"revision_history": [
{
"date": "2025-02-15T12:00:00Z",
"number": "1",
"summary": "Initial release."
}
],
"status": "final",
"version": "1"
}
}
2. Das product_tree-Objekt (Das Ziel)
Das ist der kritischste und oft komplexeste Teil eines CSAF-Dokuments. Es definiert erschöpfend, genau welche Produkte, Softwarepakete oder Hardwaregeräte in der Meldung behandelt werden.
Um die Automatisierung zu ermöglichen, muss jeder eigenständigen Produktvariante (z. B. Widget-Manager v1.2 vs. Widget-Manager v1.3) eine eindeutige product_id zugewiesen werden.
"product_tree": {
"branches": [
{
"category": "vendor",
"name": "Acme",
"branches": [
{
"category": "product_name",
"name": "Widget-Manager",
"branches": [
{
"category": "product_version",
"name": "1.2.0",
"product": {
"name": "Acme Widget-Manager 1.2.0",
"product_id": "CSAFPID-0001"
}
},
{
"category": "product_version",
"name": "1.3.0",
"product": {
"name": "Acme Widget-Manager 1.3.0",
"product_id": "CSAFPID-0002"
}
}
]
}
]
}
]
}
Hinweis: Fortgeschrittenes CSAF erlaubt es, CPEs (Common Platform Enumerations) oder PURLs (Package URLs) zu verwenden, um die product_id kryptografisch mit exakten Software-Hashes oder SBOM-Einträgen zu verknüpfen.
3. Das vulnerabilities-Objekt (Die Bedrohung und die Korrektur)
Dieses Array verbindet die Schwachstellen mit den spezifischen product_ids, die im product_tree definiert sind. Es legt die CVE, die CVSS-Werte und den genauen Behebungsstatus für jeden Produktknoten dar.
"vulnerabilities": [
{
"cve": "CVE-2025-09999",
"notes": [
{
"category": "description",
"text": "A buffer overflow in the auth endpoint allows remote code execution."
}
],
"product_status": {
"known_affected": [
"CSAFPID-0001"
],
"fixed": [
"CSAFPID-0002"
]
},
"remediations": [
{
"category": "vendor_fix",
"details": "Update to version 1.3.0 immediately.",
"product_ids": [
"CSAFPID-0001"
]
}
],
"scores": [
{
"cvss_v3": {
"baseScore": 9.8,
"baseSeverity": "CRITICAL",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"version": "3.1"
},
"products": [
"CSAFPID-0001"
]
}
]
}
]
In dieser Struktur kann ein maschineller Scanner sofort lesen: CVE-2025-09999 betrifft CSAFPID-0001 (Widget-Manager 1.2.0) mit einem CVSS von 9.8. Die Korrektur ist ein Upgrade, und sie ist in CSAFPID-0002 (Widget-Manager 1.3.0) behoben.
Die operative Herausforderung für Entwicklungsteams
Die JSON-Struktur zu verstehen, ist der einfache Teil. Der schwierige Teil für Entwicklungsorganisationen ist, diese Struktur konsistent zu befüllen.
Sie können CSAF-JSON-Dokumente nicht von Hand schreiben. Ist Ihre Produktreihe komplex, kann allein der product_tree Tausende von JSON-Zeilen umfassen.
Um CSAF einzuführen, muss Ihre Entwicklungsorganisation Schwachstellenmeldungen als Code behandeln. Sie brauchen eine Pipeline, die rohe Schwachstellendaten aus Ihrem internen Jira-/Issue-Tracker (CVE-ID, CVSS-Wert, betroffene Versionszweige) entgegennimmt und automatisch in gültiges CSAF-2.0-JSON kompiliert. Außerdem muss Ihr CSAF-Erstellungsmotor die Ausgabe vor der Veröffentlichung gegen die strengen OASIS-JSON-Schemata validieren.
Warum CSAF unvermeidlich ist
Der Wechsel von menschenlesbaren PDFs zu maschinenlesbarem JSON wird von der Notwendigkeit getrieben. Unternehmenskunden (und öffentliche Beschaffungsstellen) verlangen automatisierte VEX- und CSAF-Dokumente, um ihre enormen Lieferkettenrisiken zu verwalten.
Außerdem werden Regulierungsbehörden wie ENISA mit Beginn der CRA-Durchsetzung wahrscheinlich verlangen, dass Schwachstellenmeldungen über APIs in standardisierten, maschinenlesbaren Formaten eingereicht werden. Wenn Ihre Organisation heute nicht die Infrastruktur zur Erstellung von CSAF-Meldungen aufbaut, werden Sie morgen hektisch versuchen, sowohl die Kundenanforderungen als auch die regulatorischen Vorgaben zu erfüllen.