16. Feb. 2026
Effektives Schwachstellenmanagement

Dieser Urwald aus Abhängigkeiten in dieser Menge an Projekten führt dazu, dass kein Mensch mehr in der Lage ist selbst zu überblicken, welche Projekte Schwachstellen haben. Typischerweise entstehen hier drei zentrale Probleme:

1. Komplexität: Es werden zu viele Abhängigkeiten, um sie im Kopf zu behalten.
2. Langlebigkeit: Auch alte Produkte bleiben lange produktiv im Einsatz und müssen gepflegt werden.
3. Sicherheitsdruck: Es werden täglich große Mengen an neuen Schwachstellen publik, oft mit einer sehr hohen CVSS-Score, was ein hohes Risiko darstellt.

Hier kommt zum Glück die SBOM, die “Software Bill of Materials” zur Rettung. Die SBOM ist (unter anderem) eine Liste aller Abhängigkeiten eines Produktes, inklusive ihrer Versionsnummern und eindeutiger Identifikationsnummern. Das BSI gibt uns eine gute Definition:

A “Software Bill of Materials” (SBOM) is a machine-processable file containing supply chain relationships and details of the components used in a software product. It supports automated processing of information on these components. This covers both the so-called “primary component” and used (e.g. external/third-party) components.
[BSI TR-03183-2]

Die Schlagwörter, die wir extrahieren sollten, sind:

• Machine-processable: Die erzeugten Dokumente müssen ohne große Schwierigkeiten von Software lesbar sein
• Supply chain relationships: Die erzeugten Dokumente sollen Abhängigkeiten in der Software beinhalten

Zwei industrielle Standards für die SBOM haben sich durchgesetzt und werden von typischen Normen empfohlen: CycloneDx und SPDX.

Wir nutzen in unserer CI Pipeline Trivy um automatisiert bei jeder Änderung in der Codebase eine SBOM im CycloneDx Format zu erzeugen. Dies hat mehrere Vorteile, unter anderem stellt die SBOM so immer den aktuellen Stand der Abhängigkeiten dar, ist versioniert und vor allem funktioniert das alles ohne Mehraufwand für Entwickler*innen. Die erzeugte SBOM wird danach automatisch in DependencyTrack importiert.

DependencyTrack ist ein Tool, das eine Liste an aktuell bekannten Schwachstellen hält und in regelmäßigen Abständen diese Liste mit allen SBOMs vergleicht. Es holt sich Listen an Schwachstellen aus verschiedenen Quellen, unter anderem der NVD (National Vulnerability Database) des NIST und den Google und Github Advisories. Durch die Redundanz in der Verwendung mehrerer Quellen vermeiden wir vendor-lock-in; falls einer der Dienste eine Schwachstelle übersieht oder den Dienst einstellt, erhalten wir auch weiterhin die Updates, die wir benötigen.

Findet Dependency-Track einen Treffer zwischen einer verwendeten Komponente und einer Schwachstelle wird automatisiert eine Warnung an das Team ausgegeben, das daraufhin die Schwachstelle untersuchen und notwendige Schritte durchführen kann um das Problem zu mitigeren.

So müssen wir zwar das ein oder andere False Positive untersuchen, haben aber einen viel besseren Überblick über den derzeitigen Stand der Security in unseren Projekten und sind in der Lage schnell und effizient auf neu auftretenden Schwachstellen zu reagieren.

Trivy und DependencyTrack aufzusetzen, sowie die Teams initial zu schulen, kostet zwar etwas Aufwand am Start des Projektes, führt aber danach fortlaufend ohne Mehraufwand zu vielen Vorteilen:

1. Echtzeitüberblick aller Risiken, die durch Abhängigkeiten in das Produkt kommen.
2. Weniger Blind-Spots: DependencyTrack untersucht auch indirekte Abhängigkeiten und Projekte, die nicht mehr aktiv entwickelt werden.
3. Transparenz für Kunden: Die SBOM kann jederzeit unseren Kunden mit ausgeliefert und in Kundenprozesse integriert werden.
4. Bessere Planbarkeit: Security wird in den normalen Entwicklungsprozess integriert, statt Pi-mal-Daumen durchgeführt zu werden.

Fazit: Durch das Erzeugen einer Software Bill of Materials können wir auch in einem Umfeld mit vielen Projekten in vielen verschiedenen Programmiersprachen die Flut an Abhängigkeiten unter Kontrolle halten und schnell und gezielt auf neue Schwachstellen reagieren.