Seite 2: Lehren aus Log4j und was zu tun ist

Die Herausforderung für viele Unternehmen besteht darin, einen Weg zu finden, wie sie im Fall einer neu bekannt gewordenen Schwachstelle rasch klarstellen können, ob die in ihrer IT-Landschaft eingesetzte Software betroffen ist. Um dieser Herausforderung zu begegnen, müssen sich folgende Fragen zügig beantworten lassen:

1. Welche Anwendung verwendet eine von Schwachstellen betroffene Komponente?
2. Und falls ja, in welcher Version?
3. Gibt es einen Überblick über die gesamte Anwendungslandschaft?

Wertvolle Hilfe zum Beantworten dieser Fragen leisten Software Bills of Materials (SBOMs). Dabei handelt es sich um die einer Zutatenliste vergleichbare Auflistung aller in einer Software verwendeten Bibliotheken und Komponenten. SBOMs haben ein standardisiertes Format (CycloneDX oder Software Package Data Exchange: kurz SPDX), sind maschinenlesbar und beinhalten alle direkten und transitiven Abhängigkeiten sowie deren hierarchische Beziehung. SBOMs können darüber hinaus noch weitere Informationen etwa zu Lizenzen enthalten.

In den USA verpflichtet bereits eine Executive Order aus dem Mai 2021 Hersteller, die Software an die Regierung verkaufen wollen, dazu, ihren Produkten SBOMs beizulegen. In Europa verbreitet sich diese Vorgehensweise erst langsam.

SBOM erzeugen

Eine SBOM ist eine JSON- oder XML-Datei in einem definierten Format. Die Website des OWASP-Projekts CycloneDX listet eine Vielzahl von Tools auf, mit denen sich SBOMs für Software in diversen Programmiersprachen erzeugen lassen. Für Java existiert ein Maven-Plug-in, das sich einfach in den Build-Prozess integrieren lässt:

mvn org.cyclonedx:cyclonedx- mven-plugin:makeAggregateBom

Besteht eine Anwendungslandschaft aus 60 eigenentwickelten Produkten und bestehen diese im Schnitt aus drei Komponenten oder Modulen, dann ergeben sich daraus 180 JSON-Dateien. Sie alle manuell zu analysieren wäre ein zu hoher Aufwand und würde zudem nur eine Momentaufnahme abbilden, da bei jeder Änderung am Code weitere neue Dateien und Abhängigkeiten hinzukommen. Stattdessen empfiehlt es sich, sämtliche SBOMs zentral zusammenzuführen, um sie analysieren zu können.

Dafür existieren Tools wie die Open-Source-Software Dependency-Track von OWASP. Das Werkzeug lässt sich als Docker-Container leicht in Betrieb nehmen und durch LDAP oder OpenID an firmeninterne Verzeichnisdienste anbinden. Jede importierte SBOM erzeugt eine Version innerhalb eines Projektes. Im Falle von Java sind diese Angaben identisch mit den Inhalten der POM-Datei. In Dependency-Track stehen somit alle Informationen zu verwendeten Third-Party-Libraries zur Verfügung und das Tool kann sie gegen diverse verfügbare Kataloge von bekannten Verwundbarkeiten wie etwa NIST prüfen. Es ermittelt zu jedem Treffer einen Risiko-Score und in Summe auch für die gesamte Version des Projektes. Anhand des Scores lässt sich rasch entscheiden, welchem Produkt die größte Aufmerksamkeit gelten sollte.

Ab jetzt sind Zahlen sichtbar, die eine eventuell harte Realität offenlegen. Jetzt ist transparent, was vorher niemand so genau wusste. Das kann bei den Verantwortlichen zu schlaflosen Nächten führen, denn die schiere Masse an zu behebenden Schwachstellen ist nahezu unmöglich abzuarbeiten – zumal fast täglich neue hinzukommen. Der psychische Faktor einer solchen Analyse ist daher nicht zu unterschätzen.

Dependency-Track ermöglicht die Suche nach Komponenten. Das ist exakt die Funktion, mit der sich die erste der oben formulierten Herausforderungen meistern lässt. Alle Produkte, die ihre SBOM in diversen Versionen bereitstellen, lassen sich nach den exakten Versionen einer Komponente durchsuchen. Je nach Größe der Anwendungslandschaft und Zahl der zu untersuchenden Verwundbarkeiten erspart das unter Umständen viele Stunden an manuellem Aufwand.

Darüber hinaus ist eine Suche nach konkreten Verwundbarkeiten anhand ihrer CVE-Nummer möglich. So lässt sich eine Übersicht erstellen, in welchen Produkten diese auftreten.

Dependency-Track bietet auch die Möglichkeit, Policies zu konfigurieren (allerdings nur sehr einfache) und Alerts einzurichten, sodass bei deren Nichteinhaltung alarmiert wird – beispielsweise per Webhook an bestimmte Chatsysteme. Mittlerweile gibt es neben Dependency-Track eine große Menge weiterer Tools und Frameworks zur Software Components Analysis, zum Erstellen von SBOMs und für die Automatisierung dieser Vorgänge.

Sofern sich im Rahmen von Audits ergibt, dass bestimmte CVEs für einzelne Produkte oder die gesamte Anwendungslandschaft nicht relevant sind, lassen sich diese auf eine Ausschlussliste setzen. Dadurch bleiben sie bei der Risiko-Score-Ermittlung unberücksichtigt und der gesamte Prozess bleibt damit schlanker. Für die Integration in den Build-Prozess stehen eine API sowie diverse Plug-ins bereit, etwa für Jenkins. Durch die Jenkins-Integration ist es möglich, Quality Gates zu definieren, vergleichbar zu statischen Codeanalysen, die wiederum den Build-Prozess abbrechen lassen. Zu empfehlen ist deren Einsatz im Nightly Build. Damit lassen sich auch die Produkte regelmäßig untersuchen, an denen aktuell nicht entwickelt wird.

Was ist mit der Ausführungsschicht?

Leider deckt die Analyse auf Anwendungsebene (Inhalt der POM) in den meisten Fällen nur einen Teil der gesamten Wahrheit auf. Jede Anwendung benötigt weitere Zusatzsoftware, um lauffähig zu sein. Im Fall einer Java-Webanwendung könnte dies etwa ein Wildfly-Application-Server sein, der in einem Container läuft.

Sowohl der App-Server als auch das Basis-Image des Containers bringen weitere Abhängigkeiten mit, die wiederum bekannte Verwundbarkeiten enthalten können. Um diese zu analysieren, existieren ebenfalls verschiedene Open-Source-Tools wie Syft. Es ist in der Lage, Images oder auch Inhalte eines Filesystems zu analysieren und daraus eine SBOM zu generieren. Syft ist lediglich ein Go-Binary – der Befehl lässt sich per CLI ausführen.

In einem dem Autor bekannten realen Beispiel hatte die Anwendung selbst nur 12 Komponenten, die gesamte Ausführungsschicht aber über 1200. Angesichts dieser Menge ist es schier aussichtslos, prüfen zu wollen, ob eine anfällige Funktion einer Bibliothek wirklich verwendet wird. Hier lautet die Devise: patchen, patchen, patchen. Darüber hinaus sollten Entwicklerinnen und Entwickler ihre Basis-Images so klein wie möglich halten, um die Angriffsfläche insgesamt zu verkleinern. Dabei kann docker-slim helfen oder das Verwenden schlanker Images wie Alpine oder debian-slim.

Wer Docker-Desktop einsetzt, kann seit April 2022 mit dem Befehl docker sbom SBOMs seiner lokalen Container-Images erzeugen.