Mal ehrlich: Wer startet heute noch ein Softwareprojekt komplett bei null? In der Praxis ist es kaum noch vorstellbar, ein modernes Projekt ohne externe Abhängigkeiten umzusetzen. Entwickeln wir eine neue Website, installieren wir oft direkt eine ganze Reihe von Paketen mit npm. Arbeiten wir mit Python, ziehen wir die benötigten Bibliotheken über pip. Und in der Java-Welt ist die pom.xml durch den Einsatz von Spring Boot häufig bereits mit zahlreichen Bibliotheken gefüllt, noch bevor die erste Zeile eigenen Codes geschrieben ist. Wir profitieren massiv vom Einsatz dieser Pakete, bauen aber unsere Projekte somit auf einem Fundament, dessen Einzelteile wir oftmals gar nicht im Detail kennen. Jede dieser Abhängigkeiten kann Schwachstellen direkt in unser System schleusen.

In diesem Artikel zeigen wir, wie sich mit SBOMs, dem Open-Source-Tool Dependency-Track und einer vollständig automatisierten Pipeline die Schwachstellenüberwachung für eine ganze Anwendungslandschaft aufbauen lässt: von der Erzeugung der SBOMs über die kontinuierliche Auswertung bis hin zur Integration in GitLab CI/CD mit OpenTofu und Python.

Das Problem

Mit zunehmender Größe einer Anwendung steigt die Zahl der externen Abhängigkeiten rasant. Was anfangs „nur” zehn Pakete sind, kann schnell auf Hunderte oder gar Tausende transitive Abhängigkeiten – also Bibliotheken, die selbst wiederum weitere Bibliotheken mitbringen – anwachsen. Ab diesem Punkt wird es nahezu unmöglich, den Überblick zu behalten und vor allem die Sicherheit aller Komponenten zuverlässig zu prüfen.

Oftmals kommen Tools wie Renovate zum Einsatz. Diese sind super, um den Versionsstand von Abhängigkeiten aktuell zu halten, da sie Updates in Git-Repositories vollautomatisch durchführen können. Ein solcher Update-Bot fungiert jedoch nicht als Security-Audit, da Renovate zwar schaut, dass alles aktuell ist, aber nicht prüft, was in den Paketen steckt. Somit bleiben folgende Fragen offen:

• Enthält die verwendete Version meines Pakets bekannte Schwachstellen (CVEs)?

• Wie kritisch sind Schwachstellen für mein Projekt?

• Ist die Lizenz der Bibliothek für mich aus organisatorischer Sicht überhaupt zulässig?

Die Grundlage: Software Bill of Materials

Um dieses Problem lösen zu können, entnehmen wir ein Konzept aus der klassischen Fertigungsindustrie: sogenannte Bill of Materials, kurz BOM.

In einer Fabrik, die Platinen herstellt, ist es entscheidend, zu wissen, welche Komponenten verbaut sind und von welchem Zulieferer sie stammen, sei es der Kondensator, der Widerstand oder der Transistor. Nur so lassen sich Materialfehler sofort erkennen und feststellen, welche Geräte davon betroffen sind.

Übertragen wir diesen Ansatz auf Software, entsteht die Software Bill of Materials, kurz SBOM. Sie kann als „Zutatenliste” der Software betrachtet werden, ähnlich wie eine Teileliste in der Fabrik. Ein SBOM dokumentiert genau, welche Komponenten in der Software enthalten sind, welche Versionen verwendet werden, welche Lizenzen relevant sind und welche Unterabhängigkeiten mitgebracht werden.

Warum reicht die SBOM allein nicht aus?

Eine existierende SBOM ist ein wichtiger erster Schritt, löst aber noch keine Probleme. In der Praxis liegt sie häufig als riesige JSON-Datei vor, die für Menschen kaum lesbar und schwer verwertbar ist. Zudem handelt es sich um ein statisches Dokument: Es listet zwar die vorhandenen Komponenten auf, gibt aber keinen Aufschluss über aktuelle Sicherheitsrisiken oder Lizenzprobleme. Ohne ein System zur kontinuierlichen Auswertung bleibt eine SBOM daher meist nur ein ungenutzter „Beipackzettel„ im Speicher. 

Dependency-Track als Gehirn

Um aus der statischen „Zutatenliste” ein nutzbares Werkzeug zu machen, wird eine Plattform benötigt, die die Daten auswertet und kontinuierlich bewertet. Hier kommt das von OWASP entwickelte Tool Dependency-Track ins Spiel.

Es übernimmt zentrale Aufgaben bei der Verarbeitung von SBOMs und schließt die Lücken, die ein statisches Dokument hinterlässt:

Dependency-Track gleicht importierte SBOMs automatisiert mit bekannten Schwachstellendatenbanken wie der GitHub Advisory Database oder der National Vulnerability Database ab, um Sicherheitslücken in Abhängigkeiten zu identifizieren.

Von der Theorie zur Praxis

Dieser Ansatz klingt für ein einzelnes Projekt erstmal sinnvoll und leuchtet schnell ein. Doch was genau bedeutet das für eine größere IT-Landschaft, welche aus mehreren Projekten besteht?

Bei der ORDIX entwickeln und betreuen wir rund 30 eigene Anwendungen, welche von der Zeiterfassung bis zum Urlaubsmanagement gehen. Jede dieser Anwendungen ist mit einer ähnlich komplexen Struktur aufgebaut: Sie besteht aus Frontend und einem Backend, wird regelmäßig aktualisiert und durchläuft eine klassische Pipeline über vier Umgebungen (Development, Testing, Integration und Produktion).

Um diese Umgebung effektiv mit Dependency-Track zu überwachen, reicht es nicht, einfach nur Dateien hochzuladen. Stattdessen ist eine Struktur erforderlich, die die Arbeitsweise und die reale Umgebung der Anwendungen abbildet:

• Logische Gruppierung (Collection-Projekte): Pro Anwendung wird ein übergeordnetes Hauptprojekt benötigt. Dieses dient als logischer Container, der alle zugehörigen Komponenten und Umgebungen bündelt und so die Übersicht im Portfolio behält.

• Differenzierung nach Umgebungen: Wir brauchen dedizierte Unterprojekte für jede Stufe (Dev, Test, Int, Prod). Nur so lässt sich auf einen Blick erkennen, welche Version der Anwendung wo gerade live, da nicht immer sofort in allen Umgebungen die neuste Version vorhanden ist.

• Technische Trennung: Innerhalb jeder Umgebung müssen Frontend und Backend als eigenständige Unterprojekte geführt werden. Dies ist essenziell, um gefundene Schwachstellen sofort dem richtigen Software-Stack zuzuordnen und gezielte Maßnahmen einzuleiten.

Wie wir Dependency-Track automatisiert haben

Um diesen Aufwand nicht händisch erledigen zu müssen, haben wir den gesamten Prozess vollständig automatisiert. Mithilfe von OpenTofu, Python und GitLab CI/CD wurde ein Workflow erstellt, der die komplette Projektstruktur inklusive Policies und Alerts automatisch erzeugt. Für den Aufbau der Projektstruktur wird OpenTofu mit dem Dependency-Track-Provider von Solarfactories verwendet. Hiermit werden die zuvor beschriebenen Projekte angelegt und korrekt miteinander verknüpft. Darüber hinaus werden über OpenTofu auch alle benötigten Policies erstellt.

Da der Provider aktuell keine Notifications unterstützt, übernimmt ein Python-Skript diesen Teil der Automatisierung. Es legt die benötigten Benachrichtigungen über die Dependency-Track-API an und hinterlegt die jeweils verantwortliche Person als Empfänger:in. Auf diese Weise wird gewährleistet, dass bei Policyverletzungen oder neu erkannten Schwachstellen unmittelbar die richtige Person informiert wird.

Sobald die Projektstruktur vollständig aufgebaut ist, können die während des Entwicklungsprozesses erzeugten SBOMs automatisch eingebunden werden. Nach einem erfolgreichen Deployment-Job in einer bestimmten Umgebung wird die entsprechende SBOM-Datei an Dependency-Track übertragen und dort der korrekten Umgebung sowie der Version der Anwendung zugeordnet.  

Fazit

Mit SBOMs, Dependency-Track und einer automatisierten Pipeline lässt sich die Schwachstellenüberwachung über eine komplette Anwendungslandschaft hinweg abbilden. Der initiale Aufwand für die Automatisierung zahlt sich schnell aus, da neue Anwendungen mit minimalem Aufwand eingebunden werden können. Probiert es selbst aus: Erzeugt für ein einzelnes Projekt eine SBOM, importiert sie in Dependency-Track und schaut, was dabei rauskommt. 

Entdecken Sie unser Seminarangebot