How Structured Vulnerability Advisories Accelerate Incident Response

Das Problem mit ad-hoc Vulnerability-Notifications

Wer kennt es nicht: Eine kritische Schwachstelle wird bekannt, und kurz darauf landet eine PDF-Datei im Postfach – formatiert nach dem Geschmack des jeweiligen Herstellers, mal mit CVSS-Score, mal ohne, manchmal mit betroffenen Versionen, manchmal nicht. Sicherheitsteams müssen diese Informationen manuell lesen, interpretieren und in ihre eigenen Systeme übertragen. Das kostet Zeit, erzeugt Fehler und verzögert genau das, was zählt: eine schnelle, fundierte Reaktion.

Das eigentliche Problem ist der Medienbruch. Zwischen dem Eingang einer Benachrichtigung und dem Moment, in dem ein Ticket im SIEM geöffnet oder eine betroffene Komponente im SBOM-Bestand markiert wird, liegen oft Stunden oder Tage manueller Arbeit. In einer Welt, in der Angreifer Schwachstellen innerhalb von Stunden nach Veröffentlichung ausnutzen, ist das ein strukturelles Risiko.

Unstrukturierte Notifikationen sind kein Nischenproblem. Sie sind der Normalzustand in den meisten Lieferketten – und sie skalieren nicht. Je mehr Lieferanten, je mehr Softwarekomponenten, desto größer das Rauschen. Genau hier setzt CSAF an.

Was CSAF ist und warum es wichtig ist

CSAF steht für Common Security Advisory Framework und ist ein offener, maschinenlesbarer Standard für Sicherheitshinweise. Er wurde von OASIS Open entwickelt und ist der direkte Nachfolger des älteren CVRF-Standards (Common Vulnerability Reporting Framework). Während CVRF noch XML-basiert und vergleichsweise starr war, setzt CSAF auf JSON und bietet eine deutlich flexiblere, toolfreundlichere Struktur.

Die aktuelle Version ist CSAF 2.0. Sie definiert mehrere Profile, die unterschiedliche Anwendungsfälle abdecken – vom einfachen informativen Advisory bis hin zum sicherheitskritischen VEX-Dokument (Vulnerability Exploitability eXchange), das explizit aussagt, ob ein Produkt von einer bekannten Schwachstelle betroffen ist oder nicht. Diese Profile machen CSAF zu mehr als einem Dokumentenformat: Sie etablieren eine gemeinsame Sprache zwischen Herstellern, CERTs und Abnehmern.

In den kommenden Wochen wird CSAF 2.1 erwartet. Die neue Version bringt unter anderem Erweiterungen rund um Metriken, verbesserte Unterstützung für Remediation-Informationen und weitere Profilverfeinerungen. Wer jetzt mit CSAF beginnt, investiert in eine Infrastruktur, die zukunftssicher ist.

Das CVE-Ökosystem und Coordinated Vulnerability Disclosure (CVD)

Bevor CSAF-Dokumente sinnvoll eingesetzt werden können, braucht es ein Verständnis dafür, wie Schwachstellen überhaupt entstehen und kommuniziert werden. Im Zentrum steht das CVE-System (Common Vulnerabilities and Exposures): eine öffentliche Datenbank, in der Schwachstellen mit einer eindeutigen Kennung (z. B. CVE-2024-12345) referenziert werden.

Schwachstellen werden nicht direkt von einer zentralen Stelle vergeben. Stattdessen existieren weltweit sogenannte CNAs (CVE Numbering Authorities) – autorisierte Organisationen, die CVE-IDs für ihren jeweiligen Zuständigkeitsbereich vergeben. Das können Hersteller sein, Sicherheitsforscher oder nationale CERTs.

Aufgrund der Finanzierungsprobleme der National Vulnerability Database (NVD) Anfang diesen Jahres ist getrieben durch das CIRCL (CERT Luxemburg) die Idee der global-CVE entstanden, ein alternatives Konzept das einen stärker dezentralen Ansatz mit CNA-spezifischen Nummernräumen ermöglicht, sogenannte GNAs, s.a. https://gcve.eu/gna/ . Diese vergeben Nummern in Eigenregie, idealerweise folgend den Best Practises s. https://gcve.eu/bcp/ . Dieses erweitert die CVE um einen GNA-Identifier, bspw. 102 für EACG oder 0 für NVD und führt zu einer ID, wie gCVE-102-2026-00001.

Coordinated Vulnerability Disclosure (CVD) beschreibt den Prozess, bei dem eine Schwachstelle nicht sofort öffentlich gemacht wird, sondern zunächst koordiniert zwischen dem Entdecker (Researcher), dem betroffenen Hersteller und ggf. einem koordinierenden CERT behandelt wird. Ziel ist es, dem Hersteller ausreichend Zeit zu geben, einen Patch zu entwickeln und bereitzustellen, bevor die Öffentlichkeit – und damit auch potenzielle Angreifer – informiert wird.

Dieses Modell bietet klare Vorteile gegenüber unilateraler Veröffentlichung: Nutzer sind besser geschützt, Hersteller können kontrolliert reagieren, und Researcher erhalten dennoch die Anerkennung für ihre Arbeit. CVD ist nicht Altruismus – es ist strukturierte Verantwortungsteilung.

Wie CSAF die Incident Response in der Praxis beschleunigt

Der entscheidende Vorteil von CSAF liegt in der Automatisierbarkeit. Ein maschinenlesbares JSON-Dokument kann direkt von Tools verarbeitet werden – ohne menschliche Zwischenschritte.

Konkret bedeutet das:

• Automatisierte Ingestion in SIEM/SOAR: Ein eingehender CSAF-Feed kann automatisch Tickets erzeugen, Schweregrade setzen und Eskalationen auslösen – basierend auf strukturierten Feldern wie CVSS-Score, Produktliste oder Remediation-Status.
• Direktes Matching gegen SBOM-Bestände: Enthält ein CSAF-Advisory eine betroffene Komponente (z. B. libssl 3.0.2), kann ein Tool diesen Eintrag automatisch mit dem eigenen Software-Inventar abgleichen und betroffene Produkte identifizieren – in Sekunden statt Stunden.
• Verkürzte Time-to-Triage: Weil Felder standardisiert sind, entfällt die Interpretation. Security-Teams sehen sofort, ob eine Schwachstelle für sie relevant ist, welche Versionen betroffen sind und welche Gegenmaßnahmen empfohlen werden.
• Reduzierter manueller Aufwand: Weniger Copy-Paste, weniger Fehlinterpretationen, weniger Rückfragen beim Hersteller.

Kurz: CSAF verschiebt den Aufwand vom Lesen und Interpretieren hin zum Handeln.

Inbound vs. Outbound: Zwei Seiten der CSAF-Nutzung

CSAF-Nutzung lässt sich in zwei Richtungen unterscheiden, die unterschiedliche Rollen und Verantwortlichkeiten mit sich bringen.

Inbound bezeichnet den Empfang von Advisories externer Lieferanten. Hier ist die eigene Organisation Konsument: Man abonniert CSAF-Feeds, verarbeitet eingehende Dokumente und matcht sie gegen den eigenen Softwarebestand. Das setzt voraus, dass Lieferanten überhaupt CSAF-Dokumente bereitstellen – und genau das ist eine der größten aktuellen Herausforderungen.

Besonders bei Open-Source-Projekten ist die Lage schwierig. Die wenigsten Open-Source-Maintainer haben die Kapazität oder das Wissen, um strukturierte CSAF-Advisories zu erstellen. Es ist derzeit nicht absehbar, dass sich das in der Breite ändern wird. Für Organisationen, die stark auf Open-Source-Komponenten setzen, bedeutet das: Der Inbound-Kanal über CSAF funktioniert vor allem für kommerzielle Anbieter; für Open-Source-Abhängigkeiten bleibt die manuelle Prüfung (z. B. über NVD oder OSV-Datenbanken) vorerst unvermeidlich.

Outbound bezeichnet die Erstellung und Veröffentlichung eigener Advisories als Hersteller oder Anbieter. Hier ist die eigene Organisation Produzent: Man beschreibt Schwachstellen in eigenen Produkten, definiert betroffene Versionen, stellt Patches bereit und veröffentlicht das Advisory im standardisierten Format – idealerweise über einen CSAF-Provider-Endpoint, der von Kunden und Aggregatoren automatisch abgerufen werden kann.

Diese Unterscheidung ist wichtig für die interne Zuständigkeit: Inbound gehört typischerweise ins Security Operations Center, Outbound in den Bereich Product Security oder ein dediziertes PSIRT (Product Security Incident Response Team).

TrustSource v3: CSAF und CVD-Unterstützung in der Praxis

Mit TrustSource v3 wird sowohl Inbound- als auch Outbound-CSAF-Unterstützung in eine integrierte Plattform gebracht – ergänzt um eine native CVD-Funktion.

Auf der Inbound-Seite kann TrustSource v3 externe CSAF-Advisories importieren und automatisch gegen den bekannten Komponentenbestand matchen. Wird eine betroffene Abhängigkeit identifiziert, wird das Advisory direkt mit den entsprechenden Projekten und Produkten verknüpft. Security-Teams sehen auf einen Blick, welche Systeme betroffen sind und welche Maßnahmen empfohlen werden.

Auf der Outbound-Seite unterstützt die Plattform die Erstellung valider CSAF-Dokumente. Hersteller können Advisories strukturiert erfassen, die relevanten Felder befüllen – inklusive Produktbaum, Schwachstellenbeschreibung, CVSS-Scoring und Remediation – und das fertige Dokument publizieren oder intern weiterleiten.

Der CVD-Workflow in TrustSource v3 koordiniert den gesamten Prozess zwischen Meldern (Researchern) und Herstellern: von der initialen Meldung über die interne Bewertung bis hin zur abgestimmten Veröffentlichung. Deadlines, Status-Updates und Kommunikationsverläufe werden nachvollziehbar dokumentiert – ein wichtiger Aspekt, wenn es später um Compliance oder Haftungsfragen geht.

Erste Schritte: Was Sicherheitsteams jetzt tun sollten

Der Einstieg in strukturiertes Vulnerability Management muss nicht komplex sein. Folgende Schritte helfen, den Prozess zu strukturieren:

1. CSAF-Tooling evaluieren: Tools wie csaf-validator (OASIS) oder kommerzielle Plattformen wie TrustSource ermöglichen den Einstieg ohne viel Aufwand. Bestehende Workflows lassen schrittweise ergänzen, bzw. erweitern.

2. SBOM-Grundlage schaffen: CSAF entfaltet seinen vollen Nutzen erst im Zusammenspiel mit einem gepflegten SBOM-Inventar. Wer noch keine SBOMs für seine Produkte erstellt, sollte das parallel angehen.

3. CVD-Prozess definieren: Unabhängig vom Tooling braucht es klare Verantwortlichkeiten: Wer nimmt Meldungen entgegen? Welche SLAs gelten für die Reaktion? Wer entscheidet über den Veröffentlichungszeitpunkt?

4. Lieferanten befragen: Welche kommerziellen Lieferanten bieten bereits CSAF-Feeds an? Diese sollten bevorzugt abonniert werden.

5. Mit Outbound beginnen: Wer selbst Software entwickelt und vertreibt, sollte frühzeitig beginnen, Advisories im CSAF-Format bereitzustellen; auch um regulatorischen Anforderungen (z. B. im Kontext des Cyber Resilience Act) vorzugreifen.

---

Fazit

Drei Kernergebnisse, die aus diesem Artikel mitgenommen werden sollten:

• CSAF ersetzt das PDF-Chaos durch maschinenlesbare, standardisierte Advisories – und macht damit automatisierte Incident Response erst möglich.
• Coordinated Vulnerability Disclosure schützt alle Beteiligten – Nutzer, Hersteller und Researcher – und funktioniert am besten mit klaren Prozessen und geeignetem Tooling.
• TrustSource v3 bietet eine integrierte Lösung für Inbound-Verarbeitung, Outbound-Erstellung und CVD-Koordination – und ermöglicht Security-Teams den direkten Einstieg ohne Eigenentwicklung.

Der Zeitpunkt zum Handeln ist jetzt: Mit CSAF 2.1 vor der Tür und wachsendem regulatorischem Druck wird strukturiertes Vulnerability Disclosure in den kommenden Monaten vom Differenzierungsmerkmal zur Grundanforderung.