Wie VEX eine SBOM von einer Stückliste in einen überprüfbaren Prüfnachweis verwandelt

Wichtigste Erkenntnisse

• Eine VEX-Meldung (Vulnerability Exploitability eXchange) gibt den Status einer Sicherheitslücke für ein oder mehrere Produkte an.
• Eine VEX-Aussage ist die Behauptung ihres Verfassers; daher prüft ein Prüfer, wer sie abgegeben hat, ob sie sich geändert hat und welche Analyse den Status untermauert.
• Die US-Behörde für Cybersicherheit und Infrastruktursicherheit (CISA) definiert vier VEX-Status; bei einer Erklärung mit dem Status „nicht betroffen“ muss der Grund dafür angegeben werden, entweder durch einen Begründungswert oder eine schriftliche Auswirkungserklärung.
• VEX kann in verschiedenen Formaten übertragen werden, und CycloneDX verwendet eigene Status- und Ausrichtungsbezeichnungen, sodass die Dokumente möglicherweise in die von CISA verwendeten Bezeichnungen übersetzt werden müssen.
• Wenn kein Upstream-Fix vorliegt, kann ein Lieferant den Status „nicht betroffen“ mit einer Begründung, den Status „betroffen“ mit einer Maßnahmenangabe oder den Status „behoben“ vergeben, sobald eine gepatchte Version in den Build aufgenommen wurde.

Eine Software-Stückliste (SBOM) gibt Auskunft darüber, was in einer Version enthalten ist, sagt jedoch nichts darüber aus, welche der von einem Scanner für diese Komponenten ermittelten Schwachstellen tatsächlich auf Ihr Produkt zutreffen. VEX (Vulnerability Exploitability eXchange) schließt diese Lücke: Damit gibt ein Lieferant oder ein Dritter an, ob eine bekannte Schwachstelle ein Softwareprodukt betrifft.

Die VEX-Leitlinien der CISA behandeln jede Aussage als Behauptung ihres Verfassers. Inwieweit sich ein Leser auf eine solche Aussage verlassen kann, hängt davon ab, wer sie abgegeben hat, wie sie unterzeichnet ist und welche Nachweise das Compliance-Rahmenwerk des Wirtschaftsprüfers akzeptiert. In diesem Artikel bezeichnet der Begriff „überprüfbare Prüfungsnachweise“ eine Behauptung, die ein Wirtschaftsprüfer anhand der ihr zugrunde liegenden Analyse überprüfen kann. Eine VEX-Aussage ist für sich genommen kein Beweis.

Was ist der „Vulnerability Exploitability eXchange“?

Wie die CISA es beschreibt, ist VEX eine Möglichkeit, den Status eines Softwareprodukts oder einer Softwarekomponente in Bezug auf eine Sicherheitslücke anzugeben. In den Mindestanforderungen der CISA für VEX, Version 1.0.0 vom April 2023, wird ein VEX-Dokument als Sammelbegriff für eine oder mehrere Aussagen definiert. Jede Aussage gibt einen einzelnen Status für eine einzelne Sicherheitslücke in einem oder mehreren Produkten an.

VEX ist so konzipiert, dass es sich in SBOMs, Schwachstellendatenbanken und Sicherheitshinweise integrieren lässt, doch laut CISA ist keines dieser Elemente zwingend erforderlich. In dem Dokument der CISA zu Anwendungsfällen vom April 2022 wird ein VEX-Dokument selbst als eine Form eines Sicherheitshinweises beschrieben.

VEX ist ein Datenformat. Es handelt sich dabei nicht um ein Gesetz, und laut den Mindestanforderungen der CISA stellen diese keine offizielle CISA-Richtlinie dar und sind nicht verbindlich. Auch die von der CISA und ihren Partnern festgelegten Mindestelemente für SBOMs für das Jahr 2026 enthalten VEX nicht.

Ein Lieferant oder ein Dritter kann ein VEX-Dokument erstellen. Der Verfasser muss als Person oder Organisation identifiziert werden und ist für den Inhalt verantwortlich.

Was VEX einem Wirtschaftsprüfer beweist und was nicht

Da der Autor für den Inhalt eines VEX-Dokuments verantwortlich ist, stellt alles darin eine Aussage dieses Autors dar. Die Leitlinien der CISA sehen vor, dass Dokumente und Aussagen signiert werden sollten, wobei die Identität des Autors kryptografisch mit der Signatur verknüpft sein muss. Außerdem ist bei jeder inhaltlichen Änderung eine höhere Dokumentversion erforderlich, ebenso wie Zeitstempel für die Erstveröffentlichung und die letzte Aktualisierung. Anhand dieser Angaben kann ein Prüfer nachvollziehen, wer die Aussage getroffen hat, wann dies geschah und ob sie sich seitdem geändert hat.

Aus dem Dokument der CISA zu Anwendungsfällen: In der Veröffentlichung vom April 2022 heißt es, dass VEX-Status nicht dazu dienen, eine Diskussion zu beenden. Sie sollen Verbrauchern helfen, fundierte Entscheidungen zu treffen, sodass ein Leser einen Status hinterfragen kann, anstatt ihn als endgültig anzusehen.

Die CISA und ihre Partner veröffentlichten am 29. Juli 2026 die „Mindestanforderungen für eine Software-Stückliste (SBOM) 2026 “. Der Abschnitt „Abgleich der SBOM mit Sicherheitshinweisen“ befasst sich mit VEX und dem Common Security Advisory Framework (CSAF). Darin heißt es, dass eine Statusaktualisierung dazu beiträgt, unnötigen Aufwand zu vermeiden, wenn eine vertrauenswürdige Quelle zu dem Schluss kommt, dass ein potenzielles Risiko nicht zu einem tatsächlichen Risiko führt. Dieser Vorteil hängt vom Vertrauen in die Quelle ab, sodass die Identität des Herausgebers darüber entscheidet, ob ein Leser auf einen Status reagieren kann.

Die Verknüpfung von VEX mit einer SBOM setzt zudem eine vollständige SBOM voraus. Das Element „Coverage“ des Dokuments von 2026 besagt, dass ein Empfänger zu dem Schluss kommen sollte, dass eine neu gemeldete Schwachstelle ihn nicht betrifft, wenn die Komponente nicht in der SBOM aufgeführt ist – und diese Schlussfolgerung ist nur dann sicher, wenn die SBOM alle Komponenten enthält. Dasselbe Dokument ordnet die Überprüfung der Genauigkeit, Abdeckung und Vollständigkeit einer SBOM den Mindestanforderungen zu, sodass eine VEX-Meldung, die sich auf eine SBOM stützt, etwaige Fehler der SBOM übernehmen kann.

Eine VEX-Meldung bezieht sich zudem ausschließlich auf Schwachstellen in einer Komponente; sie gibt also keinen Aufschluss darüber, ob das von Ihnen heruntergeladene Paket manipuliert wurde oder schädlich ist. Wenn Ihr Produkt auf Open-Source-Paketen basiert, sind Ihre VEX-Meldungen nur so zuverlässig wie Ihre Aufzeichnungen darüber, was in den einzelnen Builds enthalten war.

Einige Prüfer fragen auch nach der Analyse, die hinter jedem Befund steht. Bei Medizinprodukten fordert die US-amerikanische Food and Drug Administration (FDA) in ihren unverbindlichen Leitlinien zur Cybersicherheit vor der Markteinführung vom Februar 2026 von den Herstellern eine Sicherheits- und Risikobewertung jeder bekannten Schwachstelle in ihren Komponenten sowie die entsprechenden Risikokontrollmaßnahmen. Ein Status ohne zugrunde liegende Analyse bietet einem solchen Prüfer kaum Anhaltspunkte für die Prüfung, daher sind die Felder, die die Begründung enthalten – auf die im Folgenden eingegangen wird –, von größter Bedeutung.

Die vier Rechtsstellungen und was eine Erklärung über die Nichtbetroffenheit enthalten muss

Gemäß den Mindestanforderungen der CISA, Version 1.0.0, muss jede Angabe einen von vier Status aufweisen. Zwei davon erfordern eine bestimmte Angabe; in der Tabelle ist aufgeführt, welche.

Im Dokument zu den Anwendungsfällen vom April 2022 wird für jede „nicht betroffen“-Angabe eine Auswirkungserklärung verlangt. Die Mindestanforderungen vom April 2023 sehen vor, dass anstelle einer solchen Erklärung eine Begründung abgegeben werden kann.

Die Mindestanforderungen definieren fünf Ausrichtungswerte, wobei der letzte strenger ist, als sein Name vermuten lässt:

• „Komponente nicht vorhanden“ gilt, wenn die anfällige Unterkomponente nicht im Produkt enthalten ist.
• „Anfälliger Code nicht vorhanden“ bezieht sich auf eine Komponente, die zwar vorhanden ist, der anfällige Code jedoch nicht – in der Regel, weil sie durch die Build-Konfiguration ausgeschlossen wird.
• „Anfälliger Code, der nicht im Ausführungspfad liegt“ bezieht sich auf Code, der aufgrund der Art und Weise, wie das Produkt ihn nutzt, nicht ausgeführt werden kann.
• „Von Angreifern nicht kontrollierbarer Code“ bezeichnet Code, der zwar vorhanden ist und verwendet wird, den ein Angreifer jedoch nicht so steuern kann, dass er die Schwachstelle ausnutzen kann.
• Es gibt bereits Inline-Abwehrmaßnahmen, die integrierte Schutzmechanismen erfordern, die ein Angreifer nicht umgehen kann, die ein Benutzer nicht konfigurieren oder deaktivieren kann und die eine Ausnutzung durch bekannte Angriffsvektoren vollständig verhindern.

Jeder Wert erfordert in der Regel eine andere Art von Beleg: eine SBOM oder einen anderen Zusammensetzungsnachweis, eine Build-Konfiguration, eine Analyse des Aufrufpfads, eine Analyse der Eingabeverarbeitung oder die Abhilfemaßnahme selbst. Die Anforderungen der CISA sehen vor, dass eine Aussage Statusvermerke darüber enthalten kann, wie der Status ermittelt wurde; halten Sie diese Belege daher dort oder neben der Aussage fest. Der Wert für die Begründung allein reicht nicht aus, um einem Prüfer zu verdeutlichen, warum Sie diese Aussage getroffen haben.

Passen Sie den Status an die von Ihnen geleistete Arbeit an. Der Status „Betroffen“ signalisiert den Lesern, dass das Produkt einer Sicherheitslücke ausgesetzt ist und der Autor Maßnahmen empfiehlt. Verwenden Sie ihn nicht für einen Befund, den Sie noch nicht analysiert haben: Solange die Analyse noch läuft, kennzeichnen Sie den Befund als „in Untersuchung“. Die CISA geht davon aus, dass sich dieser Status nach Abschluss der Untersuchung ändert; eine Angabe, bei der der Status ohne Aktualisierung beibehalten wird, lässt einen Prüfer vermuten, dass die Analyse ins Stocken geraten sein könnte.

Formate und Spezifikationen, die VEX unterstützen

In den Mindestanforderungen der CISA für 2023 werden drei Formate genannt, die VEX-Dokumente enthalten oder zu deren Erstellung verwendet werden können: CSAF, CycloneDX und OpenVEX. Die Anforderungen definieren ihre Datenelemente unabhängig von einem bestimmten Format. Das Software Package Data Exchange (SPDX), das in der Liste der CISA nicht genannt wird, kann ebenfalls alle vier Status enthalten: Sein Sicherheitsprofil in Version 3.0.1 verfügt für jeden Status über eine VEX-Beziehungsklasse. Die VEX-Spezifikation jedes Formats definiert ihre eigenen Felder, wobei sich die Versionen und der Status unterscheiden.

Nicht alle Formate verwenden die Bezeichnungen der CISA. Laut der Projektdokumentation von OpenVEX definiert CycloneDX VEX eigene Status- und Begründungsbezeichnungen, sodass Dokumente möglicherweise angepasst werden müssen, um den CISA-Bezeichnungen zu entsprechen. In diesem Artikel werden durchgehend die Bezeichnungen der CISA verwendet. Wählen Sie das Format, das Ihre Toolchain und Ihre Kunden bereits unterstützen, da die VEX-Datenelemente davon unabhängig sind.

Wenn keine Korrektur auf der vorgelagerten Seite vorliegt

Was Sie nachweisen müssen, hängt davon ab, ob es einen Fix gibt. Wenn der Upstream-Entwickler einen veröffentlicht hat und Sie diesen ausliefern, kann die Erklärung den Vermerk „behoben“ enthalten und die Produktversionen nennen, die den Fix enthalten. Eine „Behoben“-Erklärung erfordert in der Regel keine Analyse, ob der anfällige Code ausgeführt werden kann, da sie auf eine Abhilfe hinweist. Als Beleg dienen typischerweise das gepatchte Artefakt und ein Versionsnachweis. Da es sich bei der Erklärung weiterhin um eine Aussage des Herausgebers handelt, sind genaue Versionsangaben wichtig. Das Anwendungsfalldokument der CISA empfiehlt, Versionen nach Möglichkeit explizit aufzulisten, da komplexe Versionsbereiche schwieriger zu interpretieren sind.

Ohne eine Korrektur haben Sie drei Möglichkeiten. Sie können den Befund analysieren und entweder mit einer Begründung „nicht betroffen“ melden, mit einer Maßnahmenangabe „betroffen“ melden oder eine gepatchte Version in Ihren Build integrieren und „behoben“ melden. Die erste Möglichkeit erfordert eine Analyse, die mit Codeänderungen schnell veraltet. Das Anwendungsfalldokument der CISA warnt davor, dass eine Aussage über alle Versionen auch zukünftige Versionen abdeckt und Versionen einschließen kann, die sich bereits am Ende ihres Lebenszyklus befinden. Als Beispiel wird angeführt, dass die Behauptung, ein Rust-Programm könne nicht von einer Java-Sicherheitslücke betroffen sein, irreführend wird, wenn eine spätere Version Java einbindet und niemand das Dokument aktualisiert. Der zweite Weg hat seine eigenen Einschränkungen. Wenn die Analyse ergibt, dass Ihr Produkt gefährdet ist, kann die Maßnahmenerklärung den Lesern nicht empfehlen, auf eine behobene Version zu aktualisieren, die es noch nicht gibt. Sie sollte stattdessen eine Abhilfemaßnahme oder einen anderen Schritt beschreiben, den die Leser ergreifen können.

Der dritte Weg ist der, der durch nicht mehr gepflegte Komponenten erschwert wird. Möglicherweise arbeitet niemand im Upstream an der von Ihnen gewünschten Korrektur, sodass jemand die von Ihnen verwendete Version patchen und anschließend überprüfen muss, ob sie sich weiterhin so verhält, wie es Ihr Produkt erwartet. Die Alternative zum Patchen ist der Austausch der Komponente, was in der Regel Nacharbeiten an allen Stellen Ihres Codes erfordert, an denen sie verwendet wird.

Eine sinnvolle Reihenfolge, wenn Sie selbst die Aussagen treffen:

1. Stellen Sie sicher, dass die SBOM mit dem ausgelieferten Produkt übereinstimmt. Sollte eine Komponente versehentlich aufgeführt sein, korrigieren Sie die SBOM, anstatt für diese Komponente eine Erklärung abzugeben, dass sie nicht betroffen ist.
2. Wenden Sie die vorhandenen Korrekturen an und geben Sie anschließend korrigierte Anweisungen heraus, in denen die Versionen genannt werden, die diese Korrekturen enthalten.
3. Bei Komponenten, für die es keine Lösung gibt, entscheiden Sie sich entweder dafür, eine gepatchte Version in Ihren Build aufzunehmen, zu prüfen, ob eine „nicht betroffen“-Angabe vorliegt, oder eine „betroffen“-Angabe mit einer Maßnahmenangabe zu veröffentlichen.
4. Kennzeichnen Sie alles, was sich noch in der Analyse befindet, als „in Bearbeitung“ und aktualisieren Sie die Erklärung, sobald die Arbeit abgeschlossen ist. Jede Änderung erhöht die Dokumentversion.

Jeder Schritt hinterlässt einen Nachweis, den ein Prüfer überprüfen kann: die korrigierte SBOM, die korrigierten Versionen, die Analyse in den Statusnotizen und den Versionsverlauf des Dokuments.

Steuerung dessen, was in den Build gelangt

Da ein VEX-Status nicht anzeigen kann, ob ein Paket manipuliert wurde oder mit der vom Projekt veröffentlichten Quelle übereinstimmt, muss die Integrität des Builds separat überprüft werden.

SecureChain von TuxCare scannt den Quellcode jedes Pakets auf Malware und verdächtige Codemuster, blockiert alle Pakete, die den Scan nicht bestehen, und erstellt die übrigen Pakete aus dem Quellcode in gehärteten, isolierten Umgebungen neu. Solange der Upstream-Entwickler weiterhin Korrekturen bereitstellt, werden die jeweiligen Pakete im Rahmen eines vertraglich festgelegten SLA gepatcht. Alle Pakete werden mit einer Herkunftsnachweis nach SLSA (Supply-chain Levels for Software Artifacts) Level 3, SBOMs und VEX-Erklärungen bereitgestellt. Für den dritten oben genannten Fall, in dem der Upstream-Entwickler die Fehlerbehebung für eine Komponente einstellt, übergibt SecureChain automatisch an den „Endless Lifecycle Support“ (ELS), der die Bereitstellung von Korrekturen auch nach Beendigung der Upstream-Wartung fortsetzt. Die Abdeckung umfasst die Ökosysteme von JavaScript, Python, Java, Go und PHP.

Wenn Sie nicht sagen können, was in einem Build enthalten war, oder wenn Ihre Untersuchungen immer wieder ins Stocken geraten, weil die Entwickler der Upstream-Pakete keine Fehlerbehebungen mehr vornehmen, fragen Sie unser Team, wie SecureChain damit umgeht.

FAQ

Ist VEX gesetzlich vorgeschrieben?

Das VEX-Format (Vulnerability Exploitability eXchange) ist kein Gesetz. Die US-Behörde für Cybersicherheit und Infrastruktursicherheit (CISA) erklärt, dass ihre VEX-Mindestanforderungen keine offizielle Richtlinie darstellen und keine Einhaltung vorschreiben, und dass VEX in den Mindestanforderungen für Software-Stücklisten (SBOM) für 2026 nicht als Pflichtfeld aufgeführt ist. In einem Kundenvertrag kann dies jedoch weiterhin vorgeschrieben werden.

Wer kann eine VEX-Anweisung schreiben?

Laut der US-Behörde für Cybersicherheit und Infrastruktursicherheit (CISA) kann eine „Vulnerability Exploitability eXchange“ (VEX)-Meldung vom Anbieter der Software oder von einem Dritten stammen. Der Verfasser muss als Person oder Organisation namentlich genannt werden und ist für den Inhalt verantwortlich. Der Verfasser kann zudem eine Rolle angeben, beispielsweise „Anbieter“.

Was enthält eine VEX-Datei?

Eine VEX-Datei (Vulnerability Exploitability eXchange), die von der US-Behörde für Cybersicherheit und Infrastruktursicherheit (CISA) als VEX-Dokument bezeichnet wird, enthält Dokument-Metadaten und mindestens eine Anweisung. Jede Anweisung gibt einen Status für eine Sicherheitslücke in einem oder mehreren Produkten an sowie alle für diesen Status erforderlichen Details, wie beispielsweise eine Handlungsanweisung oder eine Begründung.

Was bedeutet es, wenn eine Sicherheitslücke keinen VEX-Status hat?

Daraus lassen sich keine Schlussfolgerungen ziehen. Die US-Behörde für Cybersicherheit und Infrastruktursicherheit (CISA) erklärt, dass „Vulnerability Exploitability eXchange“ (VEX) keinen Standardstatus impliziert, der über die ausdrücklichen Angaben in einer Erklärung hinausgeht, und dass ein Dokument unvollständig sein kann. Eine Schwachstelle, zu der keine Erklärung vorliegt, gilt nicht als nicht betroffen.

Muss ein VEX-Dokument unterschrieben werden?

Die US-Behörde für Cybersicherheit und Infrastruktursicherheit (CISA) empfiehlt, dass Dokumente und Erklärungen im Rahmen des „Vulnerability Exploitability eXchange“ (VEX) signiert werden sollten. Die Identität des Autors sollte mit der Signatur verknüpft sein, und die Signatur eines Dokuments muss alle darin enthaltenen Metadaten und Erklärungen abdecken. Implementierungen müssen allgemein anerkannte Signaturmechanismen unterstützen.

Kann man VEX auch ohne SBOM nutzen?

Ja. Nach Angaben der US-Behörde für Cybersicherheit und Infrastruktursicherheit (CISA) ist „Vulnerability Exploitability eXchange“ (VEX) so konzipiert, dass es sich in eine Software-Stückliste (SBOM), Schwachstellendatenbanken und Sicherheitshinweise integrieren lässt, setzt jedoch keines dieser Elemente voraus. Liegt eine SBOM vor, sollten die VEX-Produktkennungen auf die darin enthaltenen Kennungen verweisen.

Zusammenfassung

Artikel Name

Wie VEX eine SBOM in überprüfbare Prüfungsnachweise umwandelt

Beschreibung

Erfahren Sie, wie VEX (Vulnerability Exploitability eXchange) feststellt, ob eine Sicherheitslücke Ihr Produkt betrifft, und was das System nachweisen kann und was nicht.

Autor

Artem Karasev

Name des Herausgebers

TuxCare

Logo des Herausgebers