Software besteht meist aus eigenem Code und eingebundenen Bibliotheken. Wird in einer dieser Bibliotheken eine Sicherheitslücke bekannt, müssen Hersteller herausfinden, welche ihrer ausgelieferten Anwendungen betroffen sind. Dafür brauchen sie verlässliche Komponenteninformationen und einen Ablauf, der von der technischen Prüfung bis zur Kundeninformation reicht.
Eine SBOM liefert die Grundlage für diese Arbeit. Dieser Artikel zeigt, wie daraus ein laufender Schwachstellenprozess wird und welche Informationen bei der Entscheidung über Updates, Schutzmaßnahmen und Meldungen helfen.
Abkürzungen im Überblick
| Abkürzung | Ausgeschrieben | Bedeutung im Artikel |
|---|---|---|
| SBOM | Software Bill of Materials | Maschinenlesbare Übersicht der Softwarekomponenten und ihrer Abhängigkeiten |
| CVE | Common Vulnerabilities and Exposures | Kennung, mit der eine veröffentlichte Schwachstelle eindeutig referenziert wird |
| CVSS | Common Vulnerability Scoring System | Verfahren zur Bewertung der Eigenschaften und des technischen Schweregrads einer Schwachstelle |
| VEX | Vulnerability Exploitability eXchange | Maschinenlesbare Aussage darüber, ob eine bestimmte Produktversion von einer Schwachstelle betroffen ist |
| KEV-Katalog | Known Exploited Vulnerabilities Catalog | Von CISA geführter Katalog bekanntermaßen ausgenutzter Schwachstellen |
| CISA | Cybersecurity and Infrastructure Security Agency | US-Behörde für Cybersicherheit und Infrastruktursicherheit |
| CRA | Cyber Resilience Act | EU-Verordnung mit Cybersicherheitsanforderungen für Produkte mit digitalen Elementen |
Mit der Veröffentlichung einer Software endet die Arbeit an ihrer Sicherheit nicht. Eine Bibliothek, die beim Release unauffällig war, kann Monate später eine bekannte Sicherheitslücke enthalten. Dann zählt, wie schnell der Hersteller feststellen kann, welche ausgelieferten Versionen betroffen sind und was seine Kunden tun müssen.
Eine Software Bill of Materials (SBOM) schafft dafür die Informationsgrundlage. Sie dokumentiert die Komponenten einer Anwendung. Ihren praktischen Nutzen zeigt sie, wenn eine neue Warnung eintrifft: Die Suche beginnt mit einem bekannten Softwarebestand, statt mit der Frage, welche Bibliotheken irgendwann in das Projekt eingeflossen sind.
Damit daraus eine verlässliche Reaktion wird, müssen Komponenteninformationen, technische Bewertung und Kundenbetreuung zusammenarbeiten.
Die Warnung muss zur ausgelieferten Software passen
Ein Schwachstellenhinweis nennt meist eine Komponente und die betroffenen Versionen. Über eine CVE-Kennung lässt sich die veröffentlichte Sicherheitslücke eindeutig referenzieren. Der erste Abgleich mit den eigenen SBOMs zeigt, welche Produktversionen näher untersucht werden müssen.
Dafür sind die SBOMs früherer Releases genauso wichtig wie die aktuelle Datei. Ein Update im Entwicklungsprojekt beseitigt keine anfällige Bibliothek in einer bereits ausgelieferten Anwendung. Wer nur den neuesten Build betrachtet, kann den aktuellen Stand richtig bewerten und trotzdem die betroffenen Kunden übersehen.
Deshalb gehört die SBOM zum jeweiligen Release. Produktversion, Build-Konfiguration und Komponentenübersicht müssen zusammen auffindbar bleiben. Welche Kunden diese Version erhalten haben oder noch einsetzen, ergibt sich anschließend aus den Auslieferungs- und Installationsinformationen. Diese Zuordnung übernimmt die SBOM selbst nicht.
Fehlen Versionsangaben, entsteht zunächst eine Rechercheaufgabe. Ein automatischer Abgleich kann nur mit den Informationen arbeiten, die ihm vorliegen.
Die Bibliothek ist enthalten. Ist die Anwendung betroffen?
Ein Treffer im Schwachstellenabgleich ist ein Anlass zur Untersuchung. Er beweist noch nicht, dass sich die Sicherheitslücke in der eigenen Anwendung ausnutzen lässt.
Eine Bibliothek kann beispielsweise ein verwundbares Servermodul enthalten, während das eigene Produkt ausschließlich andere Teile verwendet. Entscheidend ist dann, ob der betroffene Code tatsächlich im ausgelieferten Build steckt und unter welchen Bedingungen er erreichbar ist.
Diese Prüfung gehört zur Entwicklung beziehungsweise zur verantwortlichen Stelle für Produktsicherheit. Die Sicherheitsmeldung liefert die Angriffsvoraussetzungen; Code, Build-Unterlagen und Tests zeigen, ob sie im eigenen Produkt erfüllt sind.
Auch die Begründung für „nicht betroffen“ muss belastbar sein. „Verwenden wir normalerweise nicht“ reicht dafür kaum aus. Eine Funktion kann vom Kunden aktiviert oder über einen anderen Programmweg erreicht werden. Eine dokumentierte Untersuchung macht dagegen nachvollziehbar, weshalb eine konkrete Produktversion keine Korrektur benötigt.
Für die Weitergabe solcher Bewertungen gibt es VEX. Damit können Hersteller Aussagen zur Betroffenheit bestimmter Produktstände maschinenlesbar bereitstellen. CycloneDX beschreibt, wie VEX diese Kommunikation unterstützt. Die Aussage bleibt an ihren Produktstand und ihre Begründung gebunden.
Die Bewertung muss eine Entscheidung ermöglichen
Ist die Anwendung betroffen, braucht es eine Entscheidung über Dringlichkeit und Abhilfe. Wie schwer ein Angriff wiegen würde, hängt unter anderem davon ab, welche Daten oder Funktionen gefährdet sind, welche Berechtigungen benötigt werden und ob die angreifbare Funktion öffentlich erreichbar ist.
Ein CVSS-Wert liefert Informationen zum technischen Schweregrad. Gerade ein Basiswert berücksichtigt jedoch noch nicht die konkrete Einsatzsituation. Die Bewertungsgrundlagen erläutert FIRST. Hinweise auf bereits bekannte Ausnutzung, etwa im KEV-Katalog von CISA, sind ein weiterer wichtiger Baustein.
Die Bewertung sollte deshalb in einem konkreten Auftrag enden: Wer stellt die Korrektur bereit, welcher Termin gilt und wie werden Nutzer bis dahin geschützt?
Manchmal lässt sich eine Bibliothek unmittelbar aktualisieren. In anderen Fällen braucht die Änderung zusätzliche Entwicklung und Tests. Dann kann eine vorläufige Maßnahme helfen, beispielsweise ein eingeschränkter Zugriff oder das Abschalten einer gefährdeten Funktion. Kunden müssen verstehen können, wie sie diese Maßnahme anwenden und welche Einschränkungen daraus entstehen.
Parallel läuft die Prüfung möglicher Meldepflichten. Für CRA-erfasste Produkte gelten seit dem 11. September 2026 Hersteller-Meldepflichten für aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle mit Auswirkungen auf die Produktsicherheit. Die frühe Meldung ist innerhalb von 24 Stunden, die ausführlichere innerhalb von 72 Stunden nach Kenntniserlangung erforderlich. Die EU-Kommission erläutert die Voraussetzungen und Fristen.
Eine veröffentlichte CVE allein löst keine automatische Meldung aus. Sobald die Voraussetzungen erfüllt sind, kann die Meldung aber auch nicht bis zum fertigen Update warten.
Fiktives Beispiel: Eine Warnung, eine klare Reaktion
Das folgende Unternehmen, die Bibliothek und die Sicherheitslücke sind frei erfunden.
Die Beispiel GmbH vertreibt eine Delphi-Anwendung zur Wartung von Industrieanlagen. Eine Warnung betrifft die Bibliothek für den Dateiimport: Präparierte Dateien könnten die Ausführung von Programmcode ermöglichen.
Der Abgleich mit den archivierten SBOMs grenzt die Untersuchung ein. Version 3.1 enthält eine nicht betroffene Bibliotheksversion. In Version 3.2 steckt die anfällige Version. Die Entwicklung bestätigt außerdem, dass die verwundbare Funktion beim Öffnen einer Importdatei erreichbar ist.
Damit steht die Entscheidung fest: Version 3.2 benötigt eine Korrektur. Bis sie verfügbar ist, empfiehlt das Unternehmen den betroffenen Kunden, den Dateiimport zu deaktivieren. Die Entwicklung aktualisiert die Bibliothek, prüft die Sicherheitskorrektur und testet die regulären Importfunktionen. Anschließend veröffentlicht sie Version 3.2.1 mit einer neuen SBOM.
Im geschilderten Fall gibt es weder Hinweise auf aktive Ausnutzung noch einen schwerwiegenden Sicherheitsvorfall. Daraus ergibt sich keine CRA-Meldung. Das Unternehmen dokumentiert diese Bewertung zusammen mit der Korrektur und informiert die Kunden über das Update.
Die SBOM hat hier die betroffenen Softwarestände eingegrenzt. Die technische Untersuchung hat die Entscheidung ermöglicht. Der vereinbarte Ablauf hat dafür gesorgt, dass die Abhilfe auch bei den Kunden ankommt.
Ein Update braucht verständliche Informationen
Eine korrigierte Version ist nur dann hilfreich, wenn Nutzer erkennen können, ob sie sie benötigen und wie sie sie installieren.
Die Kundeninformation sollte deshalb die betroffenen Versionen benennen, die verfügbare Korrektur erklären und gegebenenfalls vorläufige Schutzmaßnahmen beschreiben. Nach der Veröffentlichung muss außerdem nachvollziehbar bleiben, was geprüft und ausgeliefert wurde.
Auch ein Vorgang ohne Update braucht einen Abschluss: die untersuchte Produktversion, das Ergebnis und die Begründung. Diese Informationen helfen bei Rückfragen und verhindern, dass dieselbe Warnung immer wieder von vorn untersucht wird. Ändern sich das Produkt oder die Erkenntnisse zur Schwachstelle, wird die Bewertung erneut aufgegriffen.
Wie Maenken Systems den Ablauf unterstützt
Der Msys SBOM Generator erstellt CycloneDX-SBOMs für Delphi-Projekte. Bei aktivierter Projekteinstellung entsteht die Übersicht automatisch beim erfolgreichen Kompilieren. Zusätzliche Komponenteninformationen lassen sich über eigene oder virtuelle SBOMs und externe Module einbinden. Für automatisierte Build-Prozesse stehen Kommandozeilenwerkzeuge bereit.
So können Hersteller die Komponentenübersicht gemeinsam mit dem jeweiligen Release archivieren und für spätere Untersuchungen bereithalten.
Für die laufende Beobachtung entwickelt Maenken Systems den SBOM Monitor. Vorgesehen sind regelmäßige Abgleiche mit Schwachstelleninformationen und Benachrichtigungen zu relevanten Treffern. Diese sollen die technische Bearbeitung neuer Hinweise unterstützen.
Fazit
Eine SBOM spart bei einer neuen Sicherheitswarnung wertvolle Recherchezeit. Entscheidend ist anschließend, dass die Untersuchung zu einer begründeten Entscheidung führt und erforderliche Maßnahmen umgesetzt werden. Wer Komponentenübersicht, Entwicklung und Kundeninformation miteinander verbindet, kann schneller erklären, welche Software betroffen ist und welche Abhilfe bereitsteht.
Quellen und weiterführende Informationen
Quellen und weiterführende Informationen
- FIRST: CVSS-Benutzerleitfaden: Grundlagen zur Bewertung des technischen Schweregrads.
- CISA: Known Exploited Vulnerabilities Catalog: Informationen zu bekanntermaßen ausgenutzten Schwachstellen.
- CycloneDX: VEX: Maschinenlesbare Aussagen zur Betroffenheit konkreter Produkte.
- EU-Kommission: CRA-Meldepflichten: Meldepflichtige Ereignisse, Fristen und Meldeweg.
Stand: Oktober 2026. Die beschriebenen Abläufe sind praktische Empfehlungen. Gesetzliche Meldepflichten sind anhand des jeweiligen Ereignisses und der geltenden Vorschriften zu beurteilen.
