Modernes VEX Schwachstellenmanagement: Nur noch die 10 % der wirklich relevanten CVEs patchen!

Jeder Schwachstellen-Scan Deiner Software produziert CVE-Findings. Ein Großteil davon betrifft Dein Produkt gar nicht, da der verwundbare Code nie aufgerufen wird oder eine bestehende Schutzmaßnahme die Ausnutzung ohnehin verhindert. Der Vulnerability Exploitability eXchange (VEX) ist der Standard, um genau das maschinenlesbar festzuhalten. Dieser Artikel erklärt Dir das Konzept, rechnet vor, wie viel Entwicklerzeit dabei tatsächlich zusammenkommt, ordnet VEX in die Pflichten des Cyber Resilience Act ein und zeigt am Beispiel von container.gov.de, warum gerade das Teilen dieser Bewertungen der eigentliche Hebel ist.

Ein reales Beispiel: Der Scanner meldet über 200 offene Schwachstellen im Container-Image. Ein Entwickler arbeitet sich hindurch, und nach zwei Tagen steht das Ergebnis fest: Die allermeisten davon sind für die ausgelieferte Software schlicht nicht relevant. Die verwundbaren Software-Komponenten liegen zwar im Image, aber die betroffene Funktion wird nie aufgerufen. Später kommt der nächste Scan, und dieselbe Diskussion beginnt von vorn. Und das Frustrierende daran ist nicht der Vulnerability-Scanner, denn der macht seine Arbeit (meistens nur das Auslesen und Abgleichen von package manager files - mehr Zauber ist hier nicht vorhanden) größtenteils korrekt (mein Kollege Refaei hat eine ganze wissenschaftliche Arbeit über deren Erkennungsraten geschrieben). Das Frustrierende ist, dass die Antwort auf die Frage „Betrifft uns diese spezielle Schwachstelle?“ meistens jedes Mal neu erarbeitet und nirgendwo automatisiert verwertbar festgehalten wird. Genau dieses Problem löst VEX.

Was VEX ist, und was es nicht ist

Der Vulnerability Exploitability eXchange ist ein maschinenlesbares Format, mit dem ein Hersteller für eine konkrete Schwachstelle in einem konkreten Produkt festhält, ob diese ausnutzbar ist. Die Mindestanforderungen hat die CISA im April 2023 in Version 1.0.0 veröffentlicht, erarbeitet von einer internationalen Arbeitsgruppe, an der übrigens auch das BSI beteiligt war.

Die saubere Abgrenzung zur SBOM ist entscheidend, und sie fällt erstaunlich vielen schwer:

Die SBOM sagt, was drin ist. VEX sagt, ob es Dich betrifft.

Diese Trennung ist kein akademisches Detail, sondern normativ verankert. Die BSI TR-03183-2 verlangt ausdrücklich, dass eine SBOM keine Schwachstelleninformationen enthalten darf, und verweist für diesen Zweck auf CSAF und VEX. Der Grund liegt in der Natur der Daten: Eine SBOM ist eine statische Momentaufnahme einer Softwareversion. Schwachstelleninformationen sind dynamisch und ändern sich täglich. Wer beides in ein Dokument presst, bekommt ein Dokument, das ständig veraltet ist.

Und noch eine Abgrenzung, die ich für wichtig halte: VEX ist kein Ersatz für Patchen. Es ist ein Priorisierungsinstrument. Wo ein Update verfügbar und zumutbar ist, ist das Update die richtige Antwort. VEX beantwortet die Frage, was Du tust, wenn kein Update existiert, das Update nicht praktikabel ist, oder wenn schlicht kein Handlungsbedarf besteht, weil die Schwachstelle Dich nicht betrifft.

Vier Status, fünf Begründungen

Ein VEX-Statement ordnet genau einer Schwachstelle für ein oder mehrere Produkte genau einen Status zu:

• not_affected - Keine Maßnahme erforderlich, das Produkt ist nicht betroffen.
• affected - Maßnahmen werden empfohlen, ein action_statement ist Pflicht.
• fixed - Die genannten Produktversionen enthalten den Fix.
• under_investigation - Die Bewertung läuft noch.

Der interessante Fall ist not_affected. Hier verlangt der Standard eine Begründung aus einem festen Set von fünf Werten, und genau diese Standardisierung macht die Aussage maschinell auswertbar:

• component_not_present - Die verwundbare Komponente ist gar nicht Teil des ausgelieferten Produkts. Typisch bei Build- oder Test-Abhängigkeiten, die ein Multi-Stage-Build wieder verwirft.
• vulnerable_code_not_present - Die Bibliothek ist enthalten, der verwundbare Code aber nicht. Der häufigste Grund in der Praxis sind Backports (das Einbauen von Fehlerbehebungen (Patches), Schließen von Sicherheitslücken oder neuen Funktionen aus einer neueren Software-Version in eine ältere Version derselben Software): Debian ändert die Versionsnummer wenn sie backporten. Der Scanner kann aber vielleicht nicht mit dieser Änderung umgehen.
• vulnerable_code_not_in_execute_path - Der Code ist da, wird aber nie aufgerufen. Das ist die Begründung, die sich am rigorosesten belegen lässt, etwa über eine Symbolanalyse des Binaries.
• vulnerable_code_cannot_be_controlled_by_adversary - Der Code läuft, aber kein angreiferkontrollierter Input erreicht ihn. Die schwierigste Begründung, weil sie auf einer Aussage über die gesamte Trust Boundary beruht.
• inline_mitigations_already_exist - Eine vorhandene Schutzmaßnahme verhindert die Ausnutzung: ein Input-Filter, eine WAF-Regel, ein seccomp-Profil.

Meine Empfehlung: Arbeite diese Liste in genau dieser Reihenfolge ab. Die vorderen Begründungen sind die stärkeren Aussagen und die einfacher zu prüfenden. Und benenne bei inline_mitigations_already_exist immer die konkrete Maßnahme samt Ort, eine Mitigation, die niemand wiederfindet, ist nicht auditierbar. Wird sie später entfernt, wird die Begründung stillschweigend falsch.

Ein minimales OpenVEX-Dokument sieht dann so aus:

{
  "@context": "https://openvex.dev/ns/v0.2.0",
  "author": "Security Team <security@example.com>",
  "timestamp": "2026-08-09T10:00:00Z",
  "version": 1,
  "statements": [
    {
      "vulnerability": { "name": "CVE-2025-12345" },
      "products": [
        { "@id": "pkg:oci/meine-app@sha256:abc123..." }
      ],
      "status": "not_affected",
      "justification": "vulnerable_code_not_in_execute_path",
      "impact_statement": "Die betroffene Parser-Funktion wird von der Anwendung nicht aufgerufen."
    }
  ]
}

Als Formate stehen CSAF, OpenVEX und CycloneDX VEX zur Verfügung. Ein Hinweis, der für die praktische Verwendung wichtig ist (bevor es ungewollte Überraschungen durch fehlende Funktionalitäten gibt): Nur CSAF und OpenVEX transportieren die standardisierte Begründung so, dass die Tools des Empfängers automatisch darauf reagieren können. CycloneDX VEX überträgt lediglich, dass Du das Finding für einen Fehlalarm hältst, plus Deinen Freitext. Die Begründung steht dort für einen Menschen, nicht für eine Maschine. Wenn Deinen Empfängern, zum Beispiel Kunden oder Kollegen, die maschinelle Auswertbarkeit wichtig ist, gib ihnen CSAF oder OpenVEX.

Die Rechnung: Wie viel Zeit hier tatsächlich liegt

Jetzt zum Teil, der vor allem Entscheider und Budgetverantwortliche interessiert. Wie groß ist der Effizienz-Hebel wirklich?

Zwei Größenordnungen helfen bei der Einordnung, die Anzahl der relevanten Schwachstellen und die benötigte Zeit, um festzustellen, ob eine Schwachstelle für die eigene Software relevant ist.. Kommerzielle SCA-Anbieter berichten, dass 70 bis 80 Prozent der (vulnerablen) Abhängigkeiten in einer Anwendung überhaupt nie referenziert werden, der Code liegt im Artefakt, wird aber nie aufgerufen. Zwei empirische Studien untermauern das für die konkrete Frage, ob die verwundbare Funktion tatsächlich erreichbar ist. Eine Untersuchung von Zapata et al. (2018) auf Funktionsebene für npm-/JavaScript-Pakete kam zu dem Ergebnis, dass bis zu 73,3 Prozent der betroffenen Clients in Wirklichkeit gar nicht bedroht waren, weil sie die verwundbare Funktion nie aufriefen. Eine deutlich größere Studie von 2026 (KAUST) über 2.414 Open-Source-Repositories in Python, Rust, Ruby und PHP maß eine False-Positive-Rate von 92,0 Prozent bei nachgelagerten Schwachstellen-Scannern und identifizierte nicht erreichbaren Code als Hauptursache. Je nach Studie, Programmiersprache und Ökosystem liegen also etwa 73 bis 92 Prozent der gemeldeten Findings als False-Positives vor, das heißt die verwundbaren Funktionen werden nie aufgerufen. Für die Kalkulation entscheidend bleibt daneben der Aufwand pro Fall: Die manuelle Prüfung eines einzelnen Findings durch einen erfahrenen Entwickler dauert im Schnitt etwa zehn Minuten.

Rechnen wir es an einem realistischen Beispiel durch. Ein Produkt mit 400 offenen Findings, quartalsweise neu bewertet:

400 Findings × 10 Minuten ≈ 67 Stunden pro Quartal (sollte man seine Software nur so selten prüfen wollen). Über ein Jahr: etwa 267 Stunden, knapp sieben Personenwochen. Für ein einziges Produkt.

Und jetzt kommt der eigentliche Punkt: Diese Arbeit wird in unserem Beispiel ohne VEX jedes Quartal erneut geleistet. Nicht, weil sich etwas geändert hätte, sondern weil das Ergebnis der letzten Bewertung nirgendwo maschinenlesbar hinterlegt ist. Im besten Fall wird die Bewertung in einer Wissensdatenbank oder einer Excel-Tabelle abgespeichert und kann nicht leichtgewichtig und automatisiert an Kollegen mit denselben Schwachstellen oder Nutzern der entsprechenden Softwarekomponentekommuniziert werden. Bei fünf Produkten mit überlappendem Technologie-Stack bewertest Du dieselbe CVE in derselben Bibliothek fünfmal parallel.

Mit VEX wird jede Schwachstelle einmal basierend auf ihrem Erreichbarkeitspfad bewertet (außer sie wird "affected bewertet"). Die Entscheidung wird zum Artefakt: versioniert, begründet, signierbar, wiederverwendbar. Der nächste Scan erkennt sie und stellt das Finding gar nicht erst wieder in die Warteschlange.

Der ökonomische Effekt ist dabei nicht primär die eingesparte Stunde. Es ist die Verlagerung: Deine Entwickler beschäftigen sich mit den zehn Schwachstellen, die tatsächlich ausnutzbar sind, statt mit den 390, die es nicht sind. Da die Untersuchung von Softwareschwachstellen, insbesondere von False-Positives, nicht unbedingt zu den Lieblingsaufgaben von Softwareentwicklern gehört, freuen sich über diese Arbeitsersparnis also nicht nur die Budgetverantwortlichen, sondern auch die Entwicklerinnen und Entwickler.

VEX und CRA-Compliance: Wo aus Kür Pflicht wird

Hier wird es für alle konkret, die den Cyber Resilience Act umsetzen müssen. Schauen wir uns die relevanten Stellen an.

Anhang I Teil I (2) a verlangt, dass Produkte ohne bekannte ausnutzbare Schwachstellen in Verkehr gebracht werden. Das Wort „ausnutzbar“ trägt hier das gesamte Gewicht. Der CRA verlangt eben nicht, dass Dein Produkt frei von CVEs ist, das wäre bei realistischer Betrachtung für kaum ein kommerzielles Softwareprodukt erreichbar. Er verlangt, dass Du die Ausnutzbarkeit bewertet hast. Diese Bewertung ist also keine Fleißaufgabe, sondern eine Voraussetzung für den Marktzugang.

Und wie belegst Du gegenüber einer Marktüberwachungsbehörde, dass Du diese Bewertung durchgeführt hast? Ein Ticket-Kommentar aus dem Jira-Backlog ist dafür ein schwacher Beleg. Ein signiertes, zeitgestempeltes VEX-Dokument mit standardisierter Begründung ist ein starker.

Anhang I Teil II verlangt, Schwachstellen zu identifizieren, zu dokumentieren und Informationen über behobene Schwachstellen zu veröffentlichen. Genau dafür ist CSAF gebaut, und ein CSAF-Dokument kann zugleich ein gültiges VEX-Dokument sein.

Artikel 14 bringt die Meldepflichten, die bereits ab dem 11. September 2026 greifen: 24 Stunden für die Frühwarnung bei aktiv ausgenutzten Schwachstellen. Wer innerhalb eines Tages belastbar sagen muss, ob und wie das eigene Produkt betroffen ist, braucht die Ausnutzbarkeitsbewertung nicht erst am Tag des Vorfalls. Er braucht sie vorher, gepflegt und abrufbar.

Der Zeitgewinn bei der Compliance entsteht damit an zwei Stellen: Du sparst die wiederholte Bewertungsarbeit, und Du sparst die Nachweisführung, weil der Nachweis als Nebenprodukt des normalen Arbeitsablaufs entsteht statt in einem Kraftakt vor dem Audit.

Ein angenehmer Nebeneffekt für den Vertrieb: Eine öffentliche VEX-URL ersetzt die wiederkehrende Kunden-E-Mail „Sind Ihre Softwareprodukte von CVE-XY betroffen?“ wie es bei Log4J Ende 2021 üblich war. Wenn ein Kunde die Schwachstelle z. B. durch einen SCA angezeigt bekommt und die VEX-URL hat, kann die Antwort selbst abrufen.

Crowdsourced VEXing: der eigentliche Hebel

Bis hierhin haben wir Zeit innerhalb eines Unternehmens gespart. Jetzt wird es sogar noch interessanter.

Wenn dieselbe Bibliothek in tausenden Produkten steckt, und das tut sie (denk an Log4j oder OpenSSL), dann steckt sie dort meistens auch auf demselben Weg: über dieselbe Zwischenbibliothek, in derselben Version, mit demselben Aufrufpfad. Genau dann beantworten gerade tausende Teams unabhängig voneinander exakt dieselbe Frage. Mit demselben Ergebnis. Das ist, vorsichtig formuliert, keine besonders effiziente Allokation von Sicherheitsexpertise (wir haben spannendere Probleme, die wir lösen könnten).

Teilbar ist dabei nicht die pauschale Aussage „diese CVE ist harmlos“, sondern die Bewertung eines konkreten Abhängigkeitspfads. Wer denselben Teilbaum in seiner SBOM hat, bekommt damit eine Frage beantwortet, die er sonst selbst durcharbeiten müsste.

Die Eskalationslogik ist simpel: einmal pro Team → einmal pro Unternehmen → einmal pro Community. Jede Stufe multipliziert die Zeitersparnis.

Wie das in der Praxis funktioniert, lässt sich in Deutschland gerade sehr gut bei container.gov.de beobachten. Im Rahmen der Secure Government Container Initiative (SGCI) von ZenDiS und openCode werden dort gehärtete Container-Images für die öffentliche Verwaltung bereitgestellt. Der Grundgedanke ist genau der beschriebene: Statt dass jede Behörde ihre Images einzeln härtet und bewertet, werden sie gemeinsam in einer Community gepflegt.

Die Compliance-Anforderung ist dabei bemerkenswert konkret. Damit ein Image gelistet wird, müssen alle bekannten Schwachstellen mit hohem oder kritischem Schweregrad explizit bewertet sein. Das VEX-Dokument hängt als In-Toto-Attestierung mit dem Predicate-Typ https://cyclonedx.org/vex am Image selbst, signiert mit cosign, nicht als lose Datei daneben. Wer das Image zieht, bekommt die Bewertung mit.

Der Effekt: Eine Behörde, die ein Basis-Image aus dem Verzeichnis verwendet, erbt die Schwachstellenbewertungen des Maintainers. Die Arbeit wurde einmal geleistet, nicht in jeder Organisation neu.

Und was ist mit dem Vertrauen?

Hier müssen wir kurz die Euphoriebremse ziehen, denn geteilte Bewertungen werfen zwei Fragen auf, die man ernst nehmen sollte.

Erstens: Eine Bewertung gilt für den Pfad, nicht für die Komponente. vulnerable_code_not_in_execute_path bezieht sich immer auf einen konkreten Abhängigkeitspfad. Hält eine Bewertung fest, dass über deine-app → http-client → openssl die verwundbare Funktion nie erreicht wird, dann bleibt das richtig, egal wie viel Code Du über diesen HTTP-Client schreibst. Bindest Du später ein zweites Modul ein, das OpenSSL direkt anspricht, ist deine-app → eigenes-tls-modul → openssl ein anderer Pfad und damit ein eigenes Finding. Die übernommene Bewertung wird dadurch nicht falsch, sie deckt diesen Fall nur nicht ab. Fremde Bewertungen gelten also genau für die Teilbäume, für die sie erstellt wurden, und Du musst prüfen, ob Deiner wirklich derselbe ist.

Zweitens: Herkunft. Der CISA-Standard verlangt, dass VEX-Dokumente signiert sind und die Autorenidentität kryptografisch an der Signatur hängt. Das sagt Dir allerdings nur, wer eine Bewertung erstellt hat, nicht, ob sie stimmt: Ein Angreifer würde Dir sehr gerne sauber signiert bestätigen, dass Dich eine Schwachstelle nicht betrifft. Der Ausweg ist, sich gar nicht erst auf eine einzelne Quelle zu verlassen, sondern die Bewertungen vieler Organisationen zum selben Abhängigkeitspfad zu sammeln und daraus eine Mehrheitsentscheidung zu bilden. Damit diese Abstimmung nicht selbst zum Einfallstor wird, zählt nicht jede Stimme gleich viel: Etablierte Organisationen wiegen schwerer, weitere Stimmen derselben Person verlieren rapide an Gewicht, ganz neue Accounts dürfen noch nicht mitstimmen, und bei zu wenigen oder uneinigen Stimmen gibt das System bewusst gar keine Empfehlung aus. Ausgearbeitet hat dieses Verfahren mein Kollege Dennis Tuan Anh Quach in Developing a Trust-Based Knowledge-Based Collaborative Filtering Hybrid Recommender System to share vulnerability management decisions in DevGuard.

Wie DevGuard das abbildet

Wir haben DevGuard genau für diesen Ablauf gebaut, deshalb an dieser Stelle konkret, was das Werkzeug tut.

• Bewerten statt abhaken. Bei einem Dependency-Finding zeigt DevGuard den Pfad zur verwundbaren Komponente als Graph. Jede Kante ist mit der Annahme beschriftet, dass die verwundbare Funktion aufgerufen wird. Weißt Du, dass eine bestimmte Kante nicht zutrifft, klickst Du sie an, daraus entsteht eine VEX-Regel, die nicht nur dieses eine Finding erledigt, sondern jedes künftige, das über denselben Abhängigkeits-Pfad hereinkommt.
• Regeln statt Einzelfälle. Eine VEX-Regel koppelt eine CEL-Expression an eine Entscheidung und wendet sie auf alle passenden Findings an, bestehende wie zukünftige. Ein Playground zeigt vor dem Speichern an, wie viele Schwachstellen eine neue Expression betreffen wird.
• Import von Lieferanten. VEX-Dokumente Deiner Lieferanten lassen sich als Datei hochladen oder per URL dauerhaft anbinden; DevGuard erkennt CycloneDX, CSAF und OpenVEX automatisch und macht aus jedem Statement eine Regel. Wenn Du der Quelle nicht vollständig traust, aktiviere einfach den Paranoid Mode: Importierte Regeln bleiben dann inaktiv, bis Du sie freigibst.
• Crowdsourced Recommendations. Haben genügend unabhängige Organisationen dieselbe Regel für eine Schwachstelle geschrieben, erscheint sie als Empfehlung. Gewichtet wird über einen Trust Score der Organisation, wiederholte Stimmen desselben Erstellers werden abgeschwächt, ein einzelner Account kann also keinen Konsens fabrizieren. Und: Übernommen wird nichts automatisch. Du erstellst die Regel selbst.
• Export und Nachweis. Aus denselben Entscheidungen erzeugt DevGuard CycloneDX VEX, OpenVEX und CSAF, als Download oder als stets aktuelle öffentliche URL. Für CSAF wird die vollständige Trusted-Provider-Struktur ausgeliefert, inklusive OpenPGP-Signaturen und Prüfsummen je Advisory.

Dass dieser Ansatz trägt, zeigt sich daran, dass DevGuard als openCode-Plattform-Service hinter der VEX-Attestierung von container.gov.de steht.

Fazit

VEX löst kein technisches Problem, sondern ein organisatorisches: Es sorgt dafür, dass eine einmal getroffene Sicherheitsentscheidung mit anderen geteilt werden kann. Der Aufwand für die Bewertung entsteht ohnehin, er wird bisher bei jeder Prüfung in jedem Projekt neu bezahlt. Diese doppelte Arbeit kann zu einem großen Teil eingespart werden, wenn die Ergebnisse untereinander geteilt werden und somit kostbare Arbeitszeit für die wirklich großen Probleme frei wird.

Für die CRA-Compliance kommt hinzu, dass die Ausnutzbarkeitsbewertung nicht optional ist. Anhang I Teil I (2) a verlangt sie im Kern, und ab September 2026 verlangen die Meldefristen, dass sie schnell verfügbar ist. Wer sie als maschinenlesbares, signiertes Dokument führt, hat den Nachweis bereits erbracht, wenn die Frage gestellt wird.

Ein konkreter erster Schritt für diese Woche: Nimm Dir das Produkt mit den meisten offenen Findings, greif Dir die zehn ältesten davon und schau nach, wie oft sie schon bewertet wurden. Wenn die Antwort „mehr als einmal“ lautet, kennst Du Deinen Business Case.

Häufige Fragen zum VEX

Referenzen

1. Cybersecurity and Infrastructure Security Agency (CISA). (2023). Minimum Requirements for Vulnerability Exploitability eXchange (VEX), Version 1.0.0.
2. CISA. (2022). Vulnerability Exploitability eXchange (VEX) - Status Justifications.
3. Bundesamt für Sicherheit in der Informationstechnik (BSI). (2025). Technical Guideline TR-03183 - Part 2: Software Bill of Materials (SBOM), Version 2.1.0.
4. Europäisches Parlament und Rat. (2024). Verordnung (EU) 2024/2847 über horizontale Cybersicherheitsanforderungen für Produkte mit digitalen Elementen (Cyber Resilience Act).
5. Verordnung (EU) 2024/2847 des Europäischen Parlaments und des Rates vom 23. Oktober 2024 (Cyber Resilience Act), Anhang I.
6. ZenDiS / openCode. (2026). Anleitung: VEX-Attestierung erstellen.
7. ZenDiS / openCode. (2026). Vulnerability Exploitability eXchange (VEX) verstehen.
8. ZenDiS / openCode. (2026). Secure Government Container Initiative - Dokumentation.
9. Help Net Security. (2025). 91% noise: A look at what’s wrong with traditional SAST tools.
10. Foo, D. et al. (2019). The Dynamics of Software Composition Analysis. arXiv:1909.00973.
11. Zapata, R. E., Kula, R. G., Chinthanet, B., Ishio, T., Matsumoto, K., und Ihara, A. (2018). Towards Smoother Library Migrations: A Look at Vulnerable Dependency Migrations at Function Level for npm JavaScript Packages. 2018 IEEE International Conference on Software Maintenance and Evolution (ICSME), 559-563.
12. Zhou, L., Dacier, M., und Konstantinou, C. (2026). A Reality Check on SBOM-based Vulnerability Management: An Empirical Study and A Path Forward. Proceedings of the Sixteenth ACM Conference on Data and Application Security and Privacy (CODASPY), 255-268.
13. OpenSSF. OpenVEX Specification.
14. OASIS. Common Security Advisory Framework (CSAF) 2.0 - VEX Profile.
15. DevGuard-Dokumentation. Working with VEX in DevGuard.