Eine neue Sicherheitsmeldung erreicht Sie heute typischerweise als PDF, als HTML-Seite oder als E-Mail vom Hersteller. Für einen Menschen ist das lesbar. Für eine Maschine ist es ein Alptraum: Jeder Hersteller nutzt ein anderes Format, andere Feldnamen, andere Formulierungen für dieselbe Aussage. Bei hundert Meldungen am Tag wird aus „lesbar" schnell „unbearbeitbar".
Zwei Standards ändern das gerade grundlegend: CSAF 2.0 macht Advisories maschinenlesbar, und VEX beantwortet die teuerste Frage im Schwachstellen-Management automatisch — „Betrifft mich diese Lücke überhaupt?"
Das Problem: Advisories für Menschen, nicht für Maschinen
Der klassische Ablauf sieht so aus: Eine Meldung kommt herein, jemand liest sie, sucht die betroffenen Produkte und Versionen heraus, gleicht sie im Kopf oder in einer Tabelle mit der eigenen Landschaft ab und entscheidet, ob gehandelt werden muss. Jeder dieser Schritte kostet Minuten bis Stunden — pro Meldung.
Bei der Menge an täglich erscheinenden Advisories skaliert dieser manuelle Prozess nicht. Die Folge kennen wir aus der Praxis: Meldungen stauen sich, die Bearbeitung geschieht stichprobenartig, und die eine Lücke, die wirklich zählt, geht im Rauschen unter. Wie teuer diese Verzögerung wird, sobald eine Lücke aktiv ausgenutzt wird, haben wir am Beispiel der VPN-Zero-Days beschrieben: Wenn das VPN zur offenen Tür wird.
Hinzu kommt die Fehleranfälligkeit der Handarbeit: Versionsbereiche werden falsch gelesen, ein betroffenes Produkt wird übersehen, eine Meldung landet im falschen Postfach. Jeder dieser Fehler ist einzeln menschlich — in der Summe entsteht daraus genau die Lücke, durch die ein Angreifer schlüpft. Nicht weil niemand zuständig war, sondern weil die schiere Menge unstrukturierter Meldungen jede zuverlässige Bearbeitung sprengt.
Was CSAF 2.0 ist
Das Common Security Advisory Framework (CSAF) 2.0 ist ein offener OASIS-Standard, der Security Advisories in einem einheitlichen, maschinenlesbaren JSON-Format beschreibt. Statt Fließtext enthält ein CSAF-Dokument klar strukturierte Felder: betroffene Produkte, Versionsbereiche, Schwachstellen-IDs, Scores, Abhilfemaßnahmen — alles an definierter Stelle, für jeden Hersteller gleich.
Der entscheidende Vorteil: Ein System kann ein CSAF-Dokument ohne menschliches Zutun einlesen und verarbeiten. Advisories werden dabei über sogenannte ROLIE-Feeds bereitgestellt und automatisch abgeholt — ähnlich wie ein Newsfeed, nur für Schwachstellen. Wer die technischen Details nachlesen möchte, findet in der offiziellen CSAF-Dokumentation einen guten Einstieg.
Deutschland treibt den Standard. Das BSI gehört zu den internationalen Vorreitern bei CSAF und stellt über CERT-Bund maschinenlesbare Advisories bereit (siehe das Warn- und Informationsdienst-Portal). Für deutsche Organisationen ist der Standard damit keine ferne Zukunft, sondern bereits Realität.
Wie ein CSAF-Advisory aufgebaut ist
Man muss kein Entwickler sein, um den Nutzen zu verstehen. Ein CSAF-Dokument gliedert sich grob in drei Teile. Der erste ist der Rahmen: Wer hat das Advisory herausgegeben, wann, in welcher Version, mit welchem Vertraulichkeitsgrad. Der zweite ist der Produktbaum: eine exakte, maschinenlesbare Liste der betroffenen Produkte samt Versionsbereichen — kein Fließtext wie „Versionen vor 3.2", sondern eindeutig auswertbare Angaben. Der dritte Teil sind die Schwachstellen: CVE-IDs, Scores, und pro Produkt die Aussage, ob und wie es betroffen ist.
Der Unterschied zum PDF-Advisory ist fundamental. Ein Mensch muss beim PDF lesen, interpretieren und übertragen. Ein System liest beim CSAF-Dokument den Produktbaum, vergleicht ihn mit dem Asset-Register und weiß in Sekunden, ob eine der betroffenen Versionen bei Ihnen läuft. Die Fehlerquelle „übersehen" oder „falsch interpretiert" entfällt.
VEX: die Antwort auf „betrifft mich das?"
CSAF löst das Format-Problem. Aber die eigentlich teure Frage ist eine andere: Selbst wenn ich weiß, dass es eine Lücke in Produkt X gibt — betrifft sie meine konkrete Version, in meiner Konfiguration? Genau hier setzt VEX an: Vulnerability Exploitability eXchange.
VEX ist ein Aussageformat, mit dem ein Hersteller pro Produkt und Version verbindlich erklärt, ob eine bestimmte Schwachstelle das Produkt tatsächlich betrifft. Der Kern ist der product_status mit vier möglichen Werten (siehe die VEX-Mindestanforderungen der CISA):
not_affected. Das Produkt ist nicht verwundbar — etwa weil der betroffene Code nicht ausgeführt wird. Sie können die Meldung guten Gewissens schließen, ohne zu patchen.
affected. Das Produkt ist betroffen und erfordert Handlung. Diese Meldung wird hochgestuft.
fixed. Die Lücke wurde in dieser Version bereits behoben. Sofern Sie aktuell sind, ist nichts zu tun.
under_investigation. Der Hersteller prüft noch. Beobachten, aber noch nicht in Alarm verfallen.
Der Effekt ist enorm: Ein „not_affected" oder „fixed" vom Hersteller bedeutet, dass sich die Betroffenheitsfrage herstellerseitig und revisionssicher beantwortet — bevor Ihr Team auch nur eine Minute mit Recherche verbringt. Statt jede Meldung selbst zu bewerten, prüfen Sie nur noch die echten „affected"-Fälle.
CSAF und VEX greifen ineinander. CSAF ist der Umschlag (das maschinenlesbare Advisory), VEX die entscheidende Aussage darin (der product_status). Zusammen verwandeln sie eine Sicherheitsmeldung von einer Leseaufgabe in einen automatisierbaren Datensatz.
Warum das gerade jetzt Fahrt aufnimmt
Der Treiber heißt Regulierung. Der Cyber Resilience Act (CRA) der EU verpflichtet Hersteller vernetzter Produkte künftig dazu, Schwachstellen strukturiert zu kommunizieren — und maschinenlesbare Advisories sind der naheliegende Weg, diese Pflicht in der Breite zu erfüllen. Parallel wächst mit den SBOM-Anforderungen (Software Bill of Materials) der Bedarf, Schwachstellen automatisiert gegen Komponenten-Inventare abzugleichen. VEX ist das Bindeglied, das aus einer SBOM-Liste eine handlungsfähige Aussage macht.
Für Organisationen heißt das: Der Zustrom maschinenlesbarer Advisories wird in den kommenden Jahren stark zunehmen. Wer seine Prozesse jetzt darauf ausrichtet, verwandelt eine regulatorische Pflicht in einen operativen Vorteil.
SBOM und VEX: Transparenz für die Lieferkette
CSAF und VEX entfalten ihre volle Wirkung im Zusammenspiel mit einem weiteren Baustein: der Software Bill of Materials (SBOM). Eine SBOM ist die Stückliste einer Software — sie listet auf, welche Komponenten und Bibliotheken in einem Produkt stecken. In modernen Anwendungen sind das oft hunderte Open-Source-Bausteine, jeder mit eigener Versionshistorie und eigenen Schwachstellen.
Ohne SBOM ist die Frage „steckt die verwundbare Bibliothek in unserer Software?" eine tagelange Sucherei. Mit SBOM wird sie zur Datenbankabfrage. Und hier schließt sich der Kreis: Die SBOM sagt, was enthalten ist, das CSAF-Advisory sagt, was verwundbar ist, und VEX sagt, ob es Sie in Ihrer konkreten Konstellation tatsächlich betrifft. Erst diese drei zusammen machen aus Lieferketten-Transparenz eine handlungsfähige Aussage.
Der regulatorische Druck wächst von beiden Seiten: Der Cyber Resilience Act verlangt von Herstellern SBOMs und strukturierte Schwachstelleninformationen, und Einkäufer beginnen, beides in Ausschreibungen einzufordern. Wer heute lernt, SBOM, CSAF und VEX zusammenzuführen, ist auf die Anforderungen der nächsten Jahre vorbereitet, statt ihnen hinterherzulaufen.
Was Sie davon haben
Der Nutzen entsteht erst durch Verarbeitung. Ein System, das CSAF-Feeds automatisch abholt, den VEX-product_status auswertet und das Ergebnis gegen Ihr Asset-Register hält, kann den größten Teil des Triage-Aufwands eliminieren: „not_affected" und „fixed" werden automatisch geschlossen, „affected" wird — angereichert mit CVSS, EPSS und KEV-Status — priorisiert vorgelegt.
Genau so arbeitet ein Security Advisory Register: Es liest CSAF-2.0-Advisories maschinenlesbar ein, wertet VEX versionsgenau aus und macht aus dem Meldungsstrom eine kurze, priorisierte Arbeitsliste — revisionssicher dokumentiert. Wie der zugehörige Gesamtprozess aussieht, beschreibt der Leitfaden zum Umgang mit Security Advisories.
„Die Frage ist nicht mehr, ob ein Advisory Sie erreicht — sondern ob Ihre Systeme es lesen können, bevor ein Mensch es tun muss."
Was CSAF und VEX nicht leisten
So wertvoll die Standards sind — sie sind kein Selbstläufer, und drei Grenzen sollte man kennen. Erstens: Ein Standard ist nur so gut wie seine Verbreitung. Noch stellen nicht alle Hersteller CSAF-Feeds bereit; für Produkte ohne maschinenlesbares Advisory bleibt der manuelle Weg vorerst bestehen. Der regulatorische Druck durch den Cyber Resilience Act wird das über die nächsten Jahre ändern, aber der Übergang läuft.
Zweitens: VEX ist eine Herstelleraussage, keine unabhängige Prüfung. Ein „not_affected" ist so vertrauenswürdig wie der Hersteller dahinter. In der Praxis ist das ein enormer Fortschritt, ersetzt aber keine kritische Prüfung bei sicherheitsrelevanten Systemen.
Drittens: Die Standards lösen das Format- und Betroffenheitsproblem, nicht das Asset-Problem. Ein maschinenlesbares Advisory nützt nur, wenn es etwas gibt, wogegen es abgeglichen werden kann. Ohne ein aktuelles, versionsgenaues Inventar Ihrer Systeme läuft auch die beste Automatisierung ins Leere. CSAF und VEX sind die halbe Miete — die andere Hälfte ist zu wissen, was Sie überhaupt betreiben.
Häufige Fragen
Was ist der Unterschied zwischen CSAF und VEX?
CSAF ist das Format des gesamten maschinenlesbaren Advisories, VEX ist die spezifische Aussage darin, ob ein Produkt von einer Schwachstelle betroffen ist (der product_status). VEX kann als Teil eines CSAF-Dokuments transportiert werden.
Brauche ich CSAF nur, wenn ich Software herstelle?
Nein. Hersteller erzeugen CSAF-Dokumente, aber der größere Nutzen liegt auf der Anwenderseite: Jede Organisation, die Advisories verarbeitet, kann maschinenlesbare Feeds automatisch einlesen und sich damit den manuellen Triage-Aufwand sparen.
Was bedeutet „not_affected" konkret für mich?
Der Hersteller erklärt verbindlich, dass Ihre Produktversion trotz der Schwachstelle nicht verwundbar ist. Sie können die Meldung schließen, ohne zu patchen — und haben die Begründung revisionssicher dokumentiert, falls ein Auditor nachfragt.
Löst CSAF/VEX das Priorisierungsproblem?
Es löst das Betroffenheitsproblem — welche Meldungen Sie überhaupt betreffen. Die Priorisierung der verbleibenden „affected"-Fälle erfolgt dann über CVSS, EPSS und den KEV-Status.
Fazit: Von der Leseaufgabe zum Datensatz
CSAF 2.0 und VEX sind keine akademischen Standards, sondern die Antwort auf ein sehr praktisches Problem: zu viele Advisories, zu wenig Zeit. CSAF macht Meldungen maschinenlesbar, VEX beantwortet die Betroffenheitsfrage herstellerseitig — und beide zusammen machen aus stundenlanger Handarbeit einen automatisierbaren Vorgang.
Der Cyber Resilience Act wird den Zustrom solcher Advisories in den nächsten Jahren vervielfachen. Die Organisationen, die davon profitieren, sind die, deren Prozesse maschinenlesbare Meldungen schon heute verarbeiten können.
Advisories, die Maschinen lesen können, sind Advisories, die Menschen nicht mehr manuell sichten müssen.