Eine Komponentenliste enthält Paketnamen und Versionen. Ein Analysewerkzeug verknüpft diese Daten mit bekannten Sicherheitsmeldungen. Dazwischen liegt ein entscheidender Schritt: Stimmen die Identität der Komponente und die Zuordnung des Befunds? Wer eine SBOM im Vulnerability Management nutzt, braucht nachvollziehbare Antworten auf diese technischen Fragen.
Unsere Experten und Referenten Ruben Brick und Yvette Teiken veranschaulichen diese Arbeit im Vortrag anhand von Dependency-Track. Dieser Beitrag konzentriert sich auf die Arbeit mit dem Inventar und den Analyseergebnissen: Komponenten erkennen, Meldungen prüfen, den Produktkontext ergänzen und neue Informationen erneut bewerten.
SBOM im Vulnerability Management: vom Inventar zum Befund
In der Demo sind die Komponenten des Beispielprojekts mit ihren Versionen sichtbar. Dependency-Track zeigt unter anderem veraltete Pakete und zugeordnete Schwachstellen. Anschließend wird ein als „Critical“ eingestufter Fund für NuGet.Packaging 6.8.0 geöffnet. Die Ansicht enthält eine Advisory-Beschreibung und einen CVSS-Vektor.
Das ist ein konkreter Nutzen der SBOM: Eine Sicherheitsmeldung lässt sich mit einer Komponente im Projekt verbinden. Die angezeigte Einstufung gehört zum damaligen Demo-Stand; daraus lässt sich keine aktuelle Aussage über ein anderes Produkt ableiten.
Auch die angezeigten Informationen beantworten unterschiedliche Fragen. Eine veraltete Version ist ein Hinweis auf einen neueren Paketstand. Ein zugeordneter Sicherheitsbefund verweist auf eine bekannte Schwachstelle. Beides sollte einzeln untersucht werden, statt jede Aktualisierung automatisch als Sicherheitsfix zu behandeln.
Zuerst die Komponenten-Zuordnung prüfen
Für einen belastbaren Befund muss klar sein, welches Paket untersucht wurde. Ein Name allein kann uneindeutig sein. Prüfen Sie deshalb Version, Paketökosystem und vorhandene Kennungen wie die Package URL, kurz PURL. Vergleichen Sie diese Angaben mit dem Paket, das im betreffenden Build tatsächlich verwendet wird.
Anschließend folgt die Sicherheitsmeldung: Welcher Versionsbereich wird genannt? Welche Voraussetzungen beschreibt das Advisory? Passt die Zuordnung zur enthaltenen Komponente? Fehlende Angaben oder Widersprüche sollten dokumentiert werden. Eine formal gültige SBOM nimmt dem Team diese Prüfung nicht ab.
Besonders hilfreich sind die Beziehungen zwischen Komponenten. Wenn ein betroffenes Paket nur indirekt eingebunden wird, zeigt der Abhängigkeitszusammenhang, über welche direkte Abhängigkeit es in das Projekt gelangt. Daraus kann sich ergeben, an welcher Stelle eine Aktualisierung geprüft werden muss.
Die Ausnutzbarkeit im Produktkontext untersuchen
Nach der Zuordnung geht es um die Nutzung im konkreten Produkt. Wird die betroffene Funktion aufgerufen? Kann ein Angreifer die erforderlichen Eingaben beeinflussen? Welche Konfiguration und Schutzmaßnahmen sind relevant? Ein Schweregrad beschreibt die Schwachstelle; für die eigene Priorisierung braucht es zusätzlich diesen Kontext.
Solange entscheidende Informationen fehlen, bleibt die Bewertung offen. Eine Entwarnung sollte auf überprüfbaren Tatsachen beruhen und für den untersuchten Produktstand gelten. Ändert sich die Nutzung oder Konfiguration, kann eine erneute Untersuchung erforderlich werden.
Als ergänzendes Konzept kann VEX, die Vulnerability Exploitability eXchange, Aussagen zur Anwendbarkeit beziehungsweise Ausnutzbarkeit einer Schwachstelle im Produktkontext maschinenlesbar ausdrücken. Die CycloneDX-Dokumentation zu VEX erläutert diese Ergänzung zum Softwareinventar. Dieser Ansatz ergänzt die im Vortrag gezeigte Komponenten- und Schwachstellenanalyse.
Einen technischen Befund reproduzierbar dokumentieren
Für die weitere Bearbeitung empfehlen wir, Produktversion, Build-Kennung und die verwendete SBOM gemeinsam zu referenzieren. Hinzu kommen die Komponentenkennung, die Advisory- oder CVE-Kennung, die verwendete Informationsquelle und das Datum der Bewertung. Dokumentieren Sie außerdem die untersuchten Voraussetzungen und die Begründung der Entscheidung.
Damit kann eine andere Person nachvollziehen, worauf die Bewertung beruht. Auch eine spätere Prüfung wird erleichtert: Hat sich die Komponente geändert, das Advisory neue Informationen erhalten oder die Produktkonfiguration verändert?
Welche Rolle der Patchstatus und die Zuordnung zu Kundeninstallationen spielen, beschreibt unser Beitrag „Cybersicherheit ist nicht nur etwas für Tech-Giganten – KMU müssen jetzt handeln“. Für diese Zuordnung ist neben der Release-SBOM eine Übersicht der tatsächlich eingesetzten Produktversionen erforderlich.
Laufende Analyse und externe Meldungen zusammenführen
Auch bei einem unveränderten Softwarebestand können neue Sicherheitsmeldungen erscheinen. Gespeicherte SBOMs sollten deshalb regelmäßig mit aktuellen Informationen abgeglichen werden. Ein einmaliger Scan beim Release beantwortet keine Fragen zu Schwachstellen, die erst später bekannt werden. Dependency-Track beschreibt diese fortlaufende Analyse in seiner Dokumentation zur CI/CD-Nutzung.
Parallel dazu können Hinweise von außen eingehen. Wie solche Meldungen angenommen, mit der meldenden Person abgestimmt und gegebenenfalls koordiniert veröffentlicht werden, erläutert unser Beitrag „CVD: So gehen Sie professionell mit Sicherheitslücken um“. Die SBOM kann diesen Ablauf bei der Komponenten- und Produktzuordnung unterstützen. Die Abstimmung mit externen Entdeckern bleibt eine zusätzliche Aufgabe.
Für den technischen Einstieg lohnt sich eine einfache Probe: Wählen Sie einen konkreten Befund, prüfen Sie seine Komponenten-Zuordnung und dokumentieren Sie die Voraussetzungen im eigenen Produkt. Danach lässt sich der Ablauf auf weitere Befunde und Produktversionen übertragen.
Quellen und weiterführende Informationen
- Vortrag und Live-Demo, insbesondere 36:00–37:57 und Abschlussfolie um Minute 41.
- Dependency-Track: offizielle Projektseite.
- CycloneDX: Vulnerability Exploitability eXchange.
