Ressourcen
>
Blog
>
SBOM- und VEX-Work-flows für Schwachstellen-Management

SBOM- und VEX-Workflows für skalierbares Schwachstellen-Management

Tanja Sommer
Tanja Sommer
Tanja Sommer
Tanja Sommer
Tanja Sommer
Inhaltsverzeichniss

SIND SIE BEREIT, IHR RISIKOMANAGEMENT ZU VERBESSERN?

Machen Sie Cybersicherheit und Compliance mit ONEKEY effizient und effektiv.

Jetzt in Aktion sehen

Sichtbarkeit allein reicht nicht aus, um Product Security im großen Maßstab zu steuern. Eine SBOM zeigt, was im Produkt steckt. Welche Befunde zuerst Handlungsbedarf auslösen, geht daraus jedoch nicht hervor. Wer SBOM- und VEX-Workflows kombiniert, schafft einen klareren Pfad für Priorisierung, Compliance und schnellere Reaktion über den gesamten Produktlebenszyklus.

Das Wichtigste in Kürze

  • Eine SBOM dokumentiert,welche Software-Komponenten in einem Produkt stecken – inklusive Versionen,Lieferanten und Abhängigkeiten.
  • VEX ergänzt Kontext und macht sichtbar, ob bekannte Schwachstellen ein konkretes Produkt tatsächlich betreffen.
  • Zusammen helfen SBOM-VEX-Workflows,reale Risiken zu priorisieren, statt jeder Scanner-Meldung hinterher zulaufen.
  • Reife Workflows beschleunigen Remediation, klären Ownership, verbessern Kundenkommunikation und stärken Auditfähigkeit.
  • Der Cyber Resilience Act erhöht den Druck auf bessere Komponenten-Dokumentation und zeitnahe Vulnerability Handling-Prozesse.
  • Automatisierte SBOM-Erstellung in CI/CD schafft verlässliche Release-Evidenz und schnellere Traceability im Incident-Fall.
  • Lifecycle-Monitoring ist entscheidend, da Produkte im Feld oft Jahre nach dem Release aktiv bleiben.
  • Skalierbare Programme verbinden Tooling, Governance und Integrationen (z. B. Jira, Jenkins, Splunk).

Einordnung von SBOM und VEX in der Product Security

Vernetzte Produkte hängen von vielen internen und externen Softwarekomponenten ab. Das erzeugt Risiko, vor allem weil täglich neue Schwachstellen bekannt werden. SBOM- und VEX-Workflows helfen dabei, Exponierung zu verstehen und mit evidenzbasierten Entscheidungen zureagieren.

SBOM als strukturierte Komponentendokumentation

Eine SBOM (Software Bill of Materials) ist eine maschinenlesbare Liste der in einem Produkt eingesetzten Softwarekomponenten. Sie kann Open-Source-Bibliotheken, kommerzielle Pakete, interne Module, Firmware-Elemente und Versionsdaten enthalten. Das schafft eine verlässliche Aufzeichnung darüber, was ausgeliefert wurde und wo betroffene Komponenten vorhanden sein können.

Für Produktteams unterstützt eine SBOM schnellere Release-Entscheidungen und sauberere Übergaben zwischen Engineering,Security und Compliance. Für PSIRT-Teams reduziert sie den Zeitaufwand, um zuprüfen, ob eine verwundbare Komponente vorhanden ist. Für Führungskräfte verbessert sie die operative Sichtbarkeit über mehrere Produktlinien.

Ein reifer SBOM-Prozess erfasst:

  • Direkte und transitive Abhängigkeiten
  • Komponentenversionen und Lieferanten
  • Eindeutige Bezeichner wie PURL oder CPE
  • Build- und Release-Versionsmapping
  • Historische Aufzeichnungen für ausgelieferte Produkte

VEX: Status zur Ausnutzbarkeit und Priorisierung

VEX (Vulnerability Exploitability eXchange) ergänzt Schwachstellenbefunde um geschäftlichen und technischen Kontext. VEX erlaubt die strukturierte Aussage, ob ein bekanntes Problem das eigene Produkt tatsächlich betrifft und ob Remediation erforderlich ist. Hier entfalten SBOM-VEX-Workflows ihren größten Mehrwert.

Ein Scanner meldet möglicherweise eine verwundbare Bibliothek, aber das bedeutet nicht zwangsläufig, dass das Produkt ausnutzbar ist. Der verwundbare Code wird möglicherweise nicht verwendet, ist deaktiviert oder wurde bereits mitigiert. VEX ermöglicht es, diesen Status strukturiert zu kommunizieren.

Häufige VEX-Ergebnisse sind:

•      Betroffen

•      Nicht betroffen

•      Behoben

•      In Prüfung

Regulatorischer Rahmen: Cyber Resilience Act

Der Cyber Resilience Act (CRA) erhöht die Anforderungen an Hersteller von Produkten mit digitalen Elementen. Stärkere Sicherheitsprozesse, klarere Dokumentation und ein wiederholbares Schwachstellenmanagement-Modell sind gefragt. Das gilt besonders für vernetzte und eingebettete Produkte.

Viele Organisationen behandeln Product Cybersecurity noch wie klassische IT-Security. Das erzeugt Lücken, weil Produkte längere Lebenszyklen haben, Firmware-Abhängigkeiten aufweisen, Lieferantenkomplexität mit sich bringen und im Feld deployete Assets umfassen.Ein produktorientiertes Betriebsmodell ist unverzichtbar.

Anforderungen an die SBOM-Dokumentation

Der CRA legt Wert auf die Dokumentation der in Produkten eingesetzten Softwarekomponenten. Das macht die SBOM zur praktischen Grundlage für technische Unterlagen, Lieferantentransparenz und Lifecycle-Nachweise. Ohne strukturierte Komponentenaufzeichnungen wird der Compliance-Nachweis schwieriger.

AnforderungWarum es wichtig ist
KomponenteninventarBelegt Sichtbarkeit über eingesetzte Software
VersionshistorieUnterstützt Impact-Analyse und Rückverfolgbarkeit
LieferantenaufzeichnungenHilft beim Management von Drittanbieterrisiken
Release-MappingVerbindet SBOM-Daten mit ausgelieferten Versionen

Viele Organisationen verwalten Komponentenaufzeichnungen noch über Tabellenkalkulationen, E-Mails und entkoppelte Systeme. Ein SBOM-Management-Tool reduziert manuellen Tracking-Aufwand und verbessert Konsistenz über Teams hinweg. Es hilft außerdem dabei, genaue Versionshistorien zu pflegen und schneller zureagieren, wenn neue Schwachstellen bekannt werden.

Pflichten zu Behebung und Offenlegung von Schwachstellen

Der CRA rückt auch die zeitnahe Behandlung von Schwachstellen in den Fokus. Das bedeutet: Befunde bewerten, Risiko priorisieren, wesentliche Probleme beheben und Updates kommunizieren.Tempo zählt, aber Genauigkeit ebenso.

Wenn jeder Alert gleich behandelt wird, verschwenden Teams Kapazität und kritische Probleme können sich verzögern. VEX hilft dabei, Rauschen von echtem Produktrisiko zu trennen. Das unterstützt bessere Remediation-Entscheidungen und stärkt die Reporting-Disziplin.

Warum Transparenz allein nicht ausreicht

Viele Organisationen stoppen nach der SBOM-Generierung. Das verbessert Transparenz, löst aber den operativen Druck nicht. Zu entscheiden bleibt, was zu beheben ist, wer es verantwortet und wie Maßnahmen nachgewiesen werden.

Ein großes Produktportfolio kann Tausende von Komponententreffern gegen öffentliche CVE-Datenbanken erzeugen.Manche sind schwerwiegend, manche irrelevant und viele unklar. Ohne SBOM-VEX-Prozesse verlassen sich Teams oft auf Tabellenkalkulationen, E-Mail-Ketten und langsame manuelle Triage.

Typische Folgeprobleme sind:

  • Backlogs ungeprüfter Befunde
  • Schlechte Priorisierung des Engineering-Aufwands
  • Inkonsistente Kundenkommunikation
  • Schwache Audit-Nachweise
  • Reibung zwischen Security- und Produktteams

SBOM und VEX gemeinsam überführen passive Sichtbarkeit in aktive Entscheidungsfindung.

Integrierter SBOM- und VEX-Workflow

Das wirksamste Modell bettet Security und Compliance in normale Delivery-Prozesse ein. Nachweise entstehen während der Entwicklung, nicht im Nachhinein. Ein zusammenhängender Workflow reduziert Kosten und steigert Tempo.

Automatisierte SBOM-Erstellung in CI/CD

Die CI/CD-Pipeline sollte für jeden produktionsreifen Build eine SBOM generieren. Das schafft eine konsistente Aufzeichnung, die an die exakte Release-Version geknüpft ist. Es entfällt die Abhängigkeit von manuellen Exporten oder veralteten Tabellenkalkulationen.

Vorteile der Automatisierung:

  • Wiederholbare Release-Nachweise
  • Schnellere Rückverfolgbarkeit bei Incidents
  • Bessere Sichtbarkeit von Lieferantenkomponenten
  • Sauberere Übergabe an Compliance-Teams

Vulnerability Scanning und Impact Assessment

Sobald eine SBOM vorliegt, kann sie gegen bekannte Schwachstellenquellen geprüft werden. Das identifiziert potenziell betroffene Komponenten schnell über aktuelle und historische Releases. Der nächste Schritt ist das Impact Assessment.

Das Impact Assessment sollte folgende Fragen klären:

  • Ist die Komponente vorhanden?
  • Wird die verwundbare Funktion genutzt?
  • Ist der Angriffspfad erreichbar?
  • Sind bereits Kontrollen vorhanden?
  • Welche Kunden oder Produkte sind betroffen?

Viele Security-Teams verbringen zu viel Zeit mit der Prüfung von Alerts, die kein reales Produktrisiko darstellen. Ein automatisiertes Schwachstellenmanagement-Tool schafft hier operativen Mehrwert, indem der manuelle Prüfaufwand sinkt, wesentliche Probleme schneller priorisiert werden und Engineering-Aufwand auf die relevantesten Befunde fokussiert wird.

VEX-Statements erstellen und pflegen

Nach der Bewertung können VEX-Statements für relevante Befunde erstellt oder aktualisiert werden. Diese Aufzeichnungen helfen internen Teams, Kunden und Regulatoren dabei, den aktuellen Status zu verstehen. Sie schaffen außerdem eine dokumentierte Entscheidungsspur.

Gute Governance bedeutet, VEX-Statements zu überprüfen, wenn:

  • Ein neuer CVE veröffentlicht wird
  • Die Produktarchitektur sich verändert
  • Ein Patch freigegeben wird
  • Neue Exploit-Informationen vorliegen
  • Kundenumgebungen die Risikoexposition verändern

Distribution und Lifecycle-Monitoring

Sicherheitsarbeit endet nicht mit dem Release. Produkte im Feld bleiben oft jahrelang aktiv, besonders in industriellen, automobilen und medizinischen Umgebungen. Kontinuierliches Monitoring nach der Auslieferung ist unverzichtbar.

Das umfasst das Vorhalten historischer SBOM-Aufzeichnungen, die Aktualisierung von VEX-Positionen und die Benachrichtigung von Stakeholdern bei wesentlichen Risikoänderungen. ONEKEY unterstützt dieses Lifecycle-Modell und hilft Teams dabei, Produkte von der Entwicklung bis zum End-of-Life zu monitoren.

Governance und operative Verantwortlichkeiten

Tools allein schaffen keine skalierbare Security. Klare Ownership, Freigabepunkte und Kommunikationswege sind ebenso wichtig. Starke Governance hält die Reaktionsaktivität auch unter Druckkonsistent.

PSIRT-Verantwortung

PSIRT-Teams führen oft Intake, Triage,Koordination und Disclosure Management durch. Sie brauchen genaue Produktdaten,schnelle Engineering-Inputs und ein klares Eskalationsmodell. SBOM- undVEX-Workflows liefern strukturierte Nachweise als Arbeitsgrundlage.

Typische PSIRT-Ownership umfasst:

  • Schwachstellen-Intake und Triage
  • Schweregrad-Review
  • Cross-funktionale Koordination
  • Externe Kommunikation
  • Abschlussnachweis und Reporting

Abstimmung zwischen Produkt und Entwicklung

Product Owner balancieren Roadmap Delivery,Kundenerwartungen und Risikoentscheidungen. Engineering Teams brauchen klare Prioritäten statt langer Scanner-Listen. Gemeinsame Workflows verbessern Vertrauen und Umsetzung.

Ein praktisches Modell:

TeamPrimäre Verantwortung
ProductRelease-Prioritäten und Kundenwirkung
EngineeringFixes, Validierung, Architekturänderungen
Security / PSIRTRisikobewertung und Koordination
ComplianceNachweise, Dokumentation, Audit Readiness

Compliance-Dokumentation und Audit-Fähigkeit

Wenn Regulatoren, Kunden oder Auditoren Nachweise verlangen, erzeugt Verzögerung Druck. Komponentenaufzeichnungen, Remediation-Historien und Entscheidungsbegründungen sollten schnell abrufbar sein. Strukturierte Workflows machen das möglich.

Nützliche Nachweise umfassen:

  • Versionsspezifische SBOMs
  • Vulnerability-Review-Protokolle
  • VEX-Status-Aufzeichnungen
  • Patch-Timelines
  • Disclosure-Kommunikation

SBOM- und VEX-Workflows mit Automatisierung skalieren

Manuelle Prozesse mögen für ein Produkt funktionieren. Über mehrere Teams, häufige Releases und globale Produktflotten scheitern sie meist. Skalierung erfordert Automatisierung, Integration und standardisierte Kontrollen.

Eine moderne Plattform sollte sich mit Tools wie Jenkins, Jira und Splunk verbinden, damit Security-Aktivität in den bestehenden Betrieb passt. Repetitive Aufwände für Engineering- und Compliance-Teams sollten sinken. Hier liefert ONEKEY Mehrwert über den gesamten Lifecycle.

Zusuchende Fähigkeiten:

  • Kontinuierliche SBOM-Generierung
  • Vulnerability-Korrelation
  • Zentrales VEX-Management
  • Workflow-Integrationen
  • Nachweis-Reporting
  • Multi-Produkt-Sichtbarkeit

Compliance-Checkliste

Mit dieser Checkliste lässt sich der aktuelle Reifegrad einschätzen. Mehrere Nein-Antworten deuten darauf hin, dass der Prozess möglicherweise nicht skaliert.

  • Wird für jeden Release eine SBOM generiert?
  • Lassen sich Befunde auf exakte Produktversionen zurückverfolgen?
  • Wird VEX eingesetzt, um relevante Probleme zu priorisieren?
  • Sind Ownership-Rollen klar definiert?
  • Können Audit-Nachweise schnell bereitgestellt werden?
  • Werden Produkte im Feld kontinuierlich gemonitort?
  • Ist die Kundenkommunikation konsistent und zeitnah?

Fazit

SBOMs liefern Sichtbarkeit, aber Sichtbarkeit allein reduziert kein Risiko. VEX ergänzt den Kontext, der für Priorisierung, Teamabstimmung und klare Kommunikation benötigt wird. Wer SBOM- und VEX-Workflows in Delivery- und Governance-Prozesse integriert, macht Schwachstellenmanagement schneller, präziser und leichter skalierbar.

Für Hersteller vernetzter Produkte wird dieser Wandel zunehmend unverzichtbar. Regulatorischer Druck steigt, Software-Lieferketten wachsen und Kunden erwarten Transparenz. Einstrukturiertes Betriebsmodell schafft jetzt Resilienz und Readiness.

Ist eine SBOM unter dem Cyber Resilience Act verpflichtend?

Der CRA erhöht die Erwartungen an die Dokumentation von Softwarekomponenten in Produkten mit digitalen Elementen. In der Praxis ist eine SBOM der effizienteste Weg, um diese Anforderung zu erfüllen und Rückverfolgbarkeit zu gewährleisten. Sie unterstützt außerdem genaue Aufzeichnungen für Audits, Vulnerability Response und Lifecycle-Management.

Verlangt der Cyber Resilience Act explizit VEX?

Der Begriff VEX wird möglicherweise nicht immer explizit genannt, aber die Notwendigkeit, Schwachstellen zu bewerten, zu beheben und zu kommunizieren, ist klar. VEX ist ein praktischer und skalierbarer Weg, diese Erwartungen zu erfüllen. Er bietet eine strukturierte Methode, um Ausnutzbarkeits-Status gegenüber Kunden, Regulatoren und internen Teams zu kommunizieren.

Worin liegt der Unterschied zwischen SBOM und VEX?

Eine SBOM listet die Softwarekomponenten im Produkt auf. VEX erklärt, ob bekannte Schwachstellen dieser Komponenten für das spezifische Produkt relevant sind. Zusammen liefern sie Transparenz und Entscheidungskontext.

Wie reduziert VEX False Positives im Schwachstellenmanagement?

VEX ermöglicht es, Probleme als nicht betroffen, behoben oder in Prüfung zu markieren. Das reduziert verschwendeten Aufwand bei Befunden, die kein reales Produktrisiko darstellen. Engineering-Teams können sich so auf die Schwachstellen konzentrieren, die zuerst Maßnahmen erfordern.

Wie lassen sich SBOM und VEX in CI/CD-Prozesse integrieren?

Die SBOM-Generierung lässt sich beim Build automatisieren, Schwachstellenprüfungen gegen freigegebene Versionen laufen und VEX-Aufzeichnungen bei der Bewertung von Befunden aktualisieren. Das schafft kontinuierliche Nachweise und schnellere Reaktionszyklen. Es verbessert außerdem die Release-Readiness, indem Security-Prozesse in normale Entwicklungs-Workflows eingebettet werden.

Teilen

Über Onekey

ONEKEY ist der führende europäische Spezialist für Product Cybersecurity & Compliance Management und Teil des Anlageportfolios von PricewaterhouseCoopers Deutschland (PwC). Die einzigartige Kombination der automatisierten ONEKEY Product Cybersecurity & Compliance Platform (OCP) mit Expertenwissen und Beratungsdiensten bietet schnelle und umfassende Analyse-, Support- und Verwaltungsfunktionen zur Verbesserung der Produktsicherheit und -konformität — vom Kauf über das Design, die Entwicklung, die Produktion bis hin zum Ende des Produktlebenszyklus.

KONTAKT:
Sara Fortmann

Senior Marketing Manager
sara.fortmann@onekey.com

euromarcom public relations GmbH
team@euromarcom.de

VERWANDTES BLOG POST

Der KI-getriebene Vulnerability-Sturm ist da. Embedded-Hersteller brauchen VulnOps.
Jenseits des Hypes: LLMs, Mythen und die Zukunft der Firmware-Analyse
RTOS Cyber Security und Compliance in Embedded Systems

Machen Sie Cybersicherheit und Compliance mit ONEKEY effizient und effektiv.