{"id":137,"date":"2026-11-09T08:36:57","date_gmt":"2026-11-09T07:36:57","guid":{"rendered":"https:\/\/sweva.maenken.cloud\/?p=137"},"modified":"2026-11-09T13:03:20","modified_gmt":"2026-11-09T12:03:20","slug":"von-der-sbom-zum-schwachstellenprozess","status":"publish","type":"post","link":"https:\/\/maenken.systems\/de\/von-der-sbom-zum-schwachstellenprozess\/","title":{"rendered":"Von der SBOM zum Schwachstellenprozess"},"content":{"rendered":"\n
\"Illustration:<\/figure>\n\n\n\n

Software besteht meist aus eigenem Code und eingebundenen Bibliotheken. Wird in einer dieser Bibliotheken eine Sicherheitsl\u00fccke bekannt, m\u00fcssen Hersteller herausfinden, welche ihrer ausgelieferten Anwendungen betroffen sind. Daf\u00fcr brauchen sie verl\u00e4ssliche Komponenteninformationen und einen Ablauf, der von der technischen Pr\u00fcfung bis zur Kundeninformation reicht.<\/p>\n\n\n\n

Eine SBOM liefert die Grundlage f\u00fcr diese Arbeit. Dieser Artikel zeigt, wie daraus ein laufender Schwachstellenprozess wird und welche Informationen bei der Entscheidung \u00fcber Updates, Schutzma\u00dfnahmen und Meldungen helfen.<\/p>\n\n\n\n

Abk\u00fcrzungen im \u00dcberblick<\/h2>\n\n\n\n
Abk\u00fcrzung<\/th>Ausgeschrieben<\/th>Bedeutung im Artikel<\/th><\/tr><\/thead>
SBOM<\/td>Software Bill of Materials<\/td>Maschinenlesbare \u00dcbersicht der Softwarekomponenten und ihrer Abh\u00e4ngigkeiten<\/td><\/tr>
CVE<\/td>Common Vulnerabilities and Exposures<\/td>Kennung, mit der eine ver\u00f6ffentlichte Schwachstelle eindeutig referenziert wird<\/td><\/tr>
CVSS<\/td>Common Vulnerability Scoring System<\/td>Verfahren zur Bewertung der Eigenschaften und des technischen Schweregrads einer Schwachstelle<\/td><\/tr>
VEX<\/td>Vulnerability Exploitability eXchange<\/td>Maschinenlesbare Aussage dar\u00fcber, ob eine bestimmte Produktversion von einer Schwachstelle betroffen ist<\/td><\/tr>
KEV-Katalog<\/td>Known Exploited Vulnerabilities Catalog<\/td>Von CISA gef\u00fchrter Katalog bekannterma\u00dfen ausgenutzter Schwachstellen<\/td><\/tr>
CISA<\/td>Cybersecurity and Infrastructure Security Agency<\/td>US-Beh\u00f6rde f\u00fcr Cybersicherheit und Infrastruktursicherheit<\/td><\/tr>
CRA<\/td>Cyber Resilience Act<\/td>EU-Verordnung mit Cybersicherheitsanforderungen f\u00fcr Produkte mit digitalen Elementen<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Mit der Ver\u00f6ffentlichung einer Software endet die Arbeit an ihrer Sicherheit nicht. Eine Bibliothek, die beim Release unauff\u00e4llig war, kann Monate sp\u00e4ter eine bekannte Sicherheitsl\u00fccke enthalten. Dann z\u00e4hlt, wie schnell der Hersteller feststellen kann, welche ausgelieferten Versionen betroffen sind und was seine Kunden tun m\u00fcssen.<\/p>\n\n\n\n

Eine Software Bill of Materials (SBOM) schafft daf\u00fcr 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.<\/p>\n\n\n\n

Damit daraus eine verl\u00e4ssliche Reaktion wird, m\u00fcssen Komponenteninformationen, technische Bewertung und Kundenbetreuung zusammenarbeiten.<\/p>\n\n\n\n

Die Warnung muss zur ausgelieferten Software passen<\/h3>\n\n\n\n
\n
\n

Ein Schwachstellenhinweis nennt meist eine Komponente und die betroffenen Versionen. \u00dcber eine CVE-Kennung l\u00e4sst sich die ver\u00f6ffentlichte Sicherheitsl\u00fccke eindeutig referenzieren. Der erste Abgleich mit den eigenen SBOMs zeigt, welche Produktversionen n\u00e4her untersucht werden m\u00fcssen.<\/p>\n\n\n\n

Daf\u00fcr sind die SBOMs fr\u00fcherer Releases genauso wichtig wie die aktuelle Datei. Ein Update im Entwicklungsprojekt beseitigt keine anf\u00e4llige Bibliothek in einer bereits ausgelieferten Anwendung. Wer nur den neuesten Build betrachtet, kann den aktuellen Stand richtig bewerten und trotzdem die betroffenen Kunden \u00fcbersehen.<\/p>\n<\/div>\n\n\n\n

\n

Deshalb geh\u00f6rt die SBOM zum jeweiligen Release. Produktversion, Build-Konfiguration und Komponenten\u00fcbersicht m\u00fcssen zusammen auffindbar bleiben. Welche Kunden diese Version erhalten haben oder noch einsetzen, ergibt sich anschlie\u00dfend aus den Auslieferungs- und Installationsinformationen. Diese Zuordnung \u00fcbernimmt die SBOM selbst nicht.<\/p>\n\n\n\n

Fehlen Versionsangaben, entsteht zun\u00e4chst eine Rechercheaufgabe. Ein automatischer Abgleich kann nur mit den Informationen arbeiten, die ihm vorliegen.<\/p>\n<\/div>\n<\/div>\n\n\n\n

Die Bibliothek ist enthalten. Ist die Anwendung betroffen?<\/h3>\n\n\n\n
\n
\n

Ein Treffer im Schwachstellenabgleich ist ein Anlass zur Untersuchung. Er beweist noch nicht, dass sich die Sicherheitsl\u00fccke in der eigenen Anwendung ausnutzen l\u00e4sst.<\/p>\n\n\n\n

Eine Bibliothek kann beispielsweise ein verwundbares Servermodul enthalten, w\u00e4hrend das eigene Produkt ausschlie\u00dflich andere Teile verwendet. Entscheidend ist dann, ob der betroffene Code tats\u00e4chlich im ausgelieferten Build steckt und unter welchen Bedingungen er erreichbar ist.<\/p>\n\n\n\n

Diese Pr\u00fcfung geh\u00f6rt zur Entwicklung beziehungsweise zur verantwortlichen Stelle f\u00fcr Produktsicherheit. Die Sicherheitsmeldung liefert die Angriffsvoraussetzungen; Code, Build-Unterlagen und Tests zeigen, ob sie im eigenen Produkt erf\u00fcllt sind.<\/p>\n<\/div>\n\n\n\n

\n

Auch die Begr\u00fcndung f\u00fcr \u201enicht betroffen\u201c muss belastbar sein. \u201eVerwenden wir normalerweise nicht\u201c reicht daf\u00fcr kaum aus. Eine Funktion kann vom Kunden aktiviert oder \u00fcber einen anderen Programmweg erreicht werden. Eine dokumentierte Untersuchung macht dagegen nachvollziehbar, weshalb eine konkrete Produktversion keine Korrektur ben\u00f6tigt.<\/p>\n\n\n\n

F\u00fcr die Weitergabe solcher Bewertungen gibt es VEX. Damit k\u00f6nnen Hersteller Aussagen zur Betroffenheit bestimmter Produktst\u00e4nde maschinenlesbar bereitstellen. CycloneDX<\/a> beschreibt, wie VEX diese Kommunikation unterst\u00fctzt. Die Aussage bleibt an ihren Produktstand und ihre Begr\u00fcndung gebunden.<\/p>\n<\/div>\n<\/div>\n\n\n\n

Die Bewertung muss eine Entscheidung erm\u00f6glichen<\/h3>\n\n\n\n

Ist die Anwendung betroffen, braucht es eine Entscheidung \u00fcber Dringlichkeit und Abhilfe. Wie schwer ein Angriff wiegen w\u00fcrde, h\u00e4ngt unter anderem davon ab, welche Daten oder Funktionen gef\u00e4hrdet sind, welche Berechtigungen ben\u00f6tigt werden und ob die angreifbare Funktion \u00f6ffentlich erreichbar ist.<\/p>\n\n\n\n

Ein CVSS-Wert liefert Informationen zum technischen Schweregrad. Gerade ein Basiswert ber\u00fccksichtigt jedoch noch nicht die konkrete Einsatzsituation. Die Bewertungsgrundlagen erl\u00e4utert FIRST<\/a>. Hinweise auf bereits bekannte Ausnutzung, etwa im KEV-Katalog von CISA<\/a>, sind ein weiterer wichtiger Baustein.<\/p>\n\n\n\n

Die Bewertung sollte deshalb in einem konkreten Auftrag enden: Wer stellt die Korrektur bereit, welcher Termin gilt und wie werden Nutzer bis dahin gesch\u00fctzt?<\/p>\n\n\n\n

Manchmal l\u00e4sst sich eine Bibliothek unmittelbar aktualisieren. In anderen F\u00e4llen braucht die \u00c4nderung zus\u00e4tzliche Entwicklung und Tests. Dann kann eine vorl\u00e4ufige Ma\u00dfnahme helfen, beispielsweise ein eingeschr\u00e4nkter Zugriff oder das Abschalten einer gef\u00e4hrdeten Funktion. Kunden m\u00fcssen verstehen k\u00f6nnen, wie sie diese Ma\u00dfnahme anwenden und welche Einschr\u00e4nkungen daraus entstehen.<\/p>\n\n\n\n

Parallel l\u00e4uft die Pr\u00fcfung m\u00f6glicher Meldepflichten. F\u00fcr CRA-erfasste Produkte gelten seit dem 11. September 2026 Hersteller-Meldepflichten f\u00fcr aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorf\u00e4lle mit Auswirkungen auf die Produktsicherheit. Die fr\u00fche Meldung ist innerhalb von 24 Stunden, die ausf\u00fchrlichere innerhalb von 72 Stunden nach Kenntniserlangung erforderlich. Die EU-Kommission<\/a> erl\u00e4utert die Voraussetzungen und Fristen.<\/p>\n\n\n\n

Eine ver\u00f6ffentlichte CVE allein l\u00f6st keine automatische Meldung aus. Sobald die Voraussetzungen erf\u00fcllt sind, kann die Meldung aber auch nicht bis zum fertigen Update warten.<\/p>\n\n\n\n

Fiktives Beispiel: Eine Warnung, eine klare Reaktion<\/h3>\n\n\n\n

Das folgende Unternehmen, die Bibliothek und die Sicherheitsl\u00fccke sind frei erfunden.<\/em><\/p>\n\n\n\n

\n
\n

Die Beispiel GmbH vertreibt eine Delphi-Anwendung zur Wartung von Industrieanlagen. Eine Warnung betrifft die Bibliothek f\u00fcr den Dateiimport: Pr\u00e4parierte Dateien k\u00f6nnten die Ausf\u00fchrung von Programmcode erm\u00f6glichen.<\/p>\n\n\n\n

Der Abgleich mit den archivierten SBOMs grenzt die Untersuchung ein. Version 3.1 enth\u00e4lt eine nicht betroffene Bibliotheksversion. In Version 3.2 steckt die anf\u00e4llige Version. Die Entwicklung best\u00e4tigt au\u00dferdem, dass die verwundbare Funktion beim \u00d6ffnen einer Importdatei erreichbar ist.<\/p>\n<\/div>\n\n\n\n

\n

Damit steht die Entscheidung fest: Version 3.2 ben\u00f6tigt eine Korrektur. Bis sie verf\u00fcgbar ist, empfiehlt das Unternehmen den betroffenen Kunden, den Dateiimport zu deaktivieren. Die Entwicklung aktualisiert die Bibliothek, pr\u00fcft die Sicherheitskorrektur und testet die regul\u00e4ren Importfunktionen. Anschlie\u00dfend ver\u00f6ffentlicht sie Version 3.2.1 mit einer neuen SBOM.<\/p>\n\n\n\n

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 \u00fcber das Update.<\/p>\n<\/div>\n<\/div>\n\n\n\n

Die SBOM hat hier die betroffenen Softwarest\u00e4nde eingegrenzt. Die technische Untersuchung hat die Entscheidung erm\u00f6glicht. Der vereinbarte Ablauf hat daf\u00fcr gesorgt, dass die Abhilfe auch bei den Kunden ankommt.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Ein Update braucht verst\u00e4ndliche Informationen<\/h3>\n\n\n\n

Eine korrigierte Version ist nur dann hilfreich, wenn Nutzer erkennen k\u00f6nnen, ob sie sie ben\u00f6tigen und wie sie sie installieren.<\/p>\n\n\n\n

\n
\n

Die Kundeninformation sollte deshalb die betroffenen Versionen benennen, die verf\u00fcgbare Korrektur erkl\u00e4ren und gegebenenfalls vorl\u00e4ufige Schutzma\u00dfnahmen beschreiben. Nach der Ver\u00f6ffentlichung muss au\u00dferdem nachvollziehbar bleiben, was gepr\u00fcft und ausgeliefert wurde.<\/p>\n<\/div>\n\n\n\n

\n

Auch ein Vorgang ohne Update braucht einen Abschluss: die untersuchte Produktversion, das Ergebnis und die Begr\u00fcndung. Diese Informationen helfen bei R\u00fcckfragen und verhindern, dass dieselbe Warnung immer wieder von vorn untersucht wird. \u00c4ndern sich das Produkt oder die Erkenntnisse zur Schwachstelle, wird die Bewertung erneut aufgegriffen.<\/p>\n<\/div>\n<\/div>\n\n\n\n

Wie Maenken Systems den Ablauf unterst\u00fctzt<\/h3>\n\n\n\n

Der Msys SBOM Generator erstellt CycloneDX<\/a>-SBOMs f\u00fcr Delphi-Projekte. Bei aktivierter Projekteinstellung entsteht die \u00dcbersicht automatisch beim erfolgreichen Kompilieren. Zus\u00e4tzliche Komponenteninformationen lassen sich \u00fcber eigene oder virtuelle SBOMs und externe Module einbinden. F\u00fcr automatisierte Build-Prozesse stehen Kommandozeilenwerkzeuge bereit.<\/p>\n\n\n\n

So k\u00f6nnen Hersteller die Komponenten\u00fcbersicht gemeinsam mit dem jeweiligen Release archivieren und f\u00fcr sp\u00e4tere Untersuchungen bereithalten.<\/p>\n\n\n\n

F\u00fcr die laufende Beobachtung entwickelt Maenken Systems den SBOM Monitor. Vorgesehen sind regelm\u00e4\u00dfige Abgleiche mit Schwachstelleninformationen und Benachrichtigungen zu relevanten Treffern. Diese sollen die technische Bearbeitung neuer Hinweise unterst\u00fctzen.<\/p>\n\n\n\n

Fazit<\/h3>\n\n\n\n

Eine SBOM spart bei einer neuen Sicherheitswarnung wertvolle Recherchezeit. Entscheidend ist anschlie\u00dfend, dass die Untersuchung zu einer begr\u00fcndeten Entscheidung f\u00fchrt und erforderliche Ma\u00dfnahmen umgesetzt werden. Wer Komponenten\u00fcbersicht, Entwicklung und Kundeninformation miteinander verbindet, kann schneller erkl\u00e4ren, welche Software betroffen ist und welche Abhilfe bereitsteht.<\/p>\n\n\n\n

Quellen und weiterf\u00fchrende Informationen<\/strong><\/summary>\n

Quellen und weiterf\u00fchrende Informationen<\/h2>\n\n\n\n