{Wegen Inventur geschlossen?!?}

Um einen Überblick über die eigene Software und die damit verbundenen Abhängigkeiten zu erhalten, ist es notwendig, den verwendeten Code zu inventieren und aufzulisten, was verwendet wird. Das manuelle Erstellen und Warten von Listen der verwendeten 3rd-Party-Dependencies ist aber mühsam, zeitaufwendig und fehleranfällig. Doch da uns bereits die Verwaltung der Dependencies vor eine ähnliche Aufgabe stellt, ist es bereits branchenstandard, dass nicht-triviale Software-Projekte Package Management Werkzeuge wie Maven, npm oder pip verwenden, um diese Dependencies einfach und automatisiert zu verwalten.

Der nächste Schritt ist daher, aus diesen bereits vorhandenen Informationen strukturierte Übersichten über die Software und die darin verwendeten Bibliotheken zu generieren. Diese Auflistungen werden als Software Bill of Material (SBOM) bezeichnet. 

Bill of Materials sind keine Erfindung der Softwareentwicklung. In klassischen Produktionsbetrieben findet man schon seit jeher Material- oder auch Stücklisten, die Auskunft über Bauteile eines Produkts geben.

Damit diese Informationen aber auch einfach und automatisiert weiterverarbeitet und analysiert werden können, ist es notwendig, plattformübergreifende Standards zu etablieren.

Aktuell gibt es zwei verbreitete SBOM-Standards:

SPDX

Bei SPDX handelt es sich um einen ISO-Standard für SBOMs, welcher von der Linux Foundation entwickelt wird.

CycloneDX

CycloneDX ist eine Standard für Bill of Materials, welcher nicht nur für Software (SBOM), sondern auch für viele andere Bereiche in der Software-Entwicklung wie Software-as-a-Service, Machine Learning oder Kryptographie eingesetzt werden kann. Die CycloneDX Working Group ist verantwortlich für diesen Standard und wird von der OWASP Foundation unterstützt.

Es gibt mittlerweile eine Reihe von Tools und Services, die die Erstellung von SBOMs in unterschiedlichen Formaten unterstützen (wobei SPDX und CycloneDX praktisch immer bei den unterstützten Formaten zu finden sind).

Ein einfaches Kommandozeilen-Werkzeug für die Erstellung von SBOMs ist syft. syft kann SBOMs sowohl ausgehend vom Dateisystem als auch von fertigen Docker-Images erstellen.

Das SBOM für sich alleine ist jedoch noch nicht sehr aussagekräftig. Die dort gesammelten Informationen müssen aufbereitet und analysiert werden, um dadurch Rückschlüsse auf mögliche Probleme und Risiken ziehen zu können. 

grpye ist ein Kommandozeilen-Werkzeug, welches SBOM-Dateien auf bekannte Schwachstellen analysieren kann. Beim Scan zieht grype mehr als 10 unterschiedliche Schwachstellen-Datenbanken heran (u. a. National Vulnerability Database NVD, RedHat RHSAs, GitHub Security Advisories), um ein möglichst breites Spektrum an bekannten Schwachstellen abdecken zu können.

Dependency Track wiederum ist eine Web-Applikation, welche als zentrales SBOM-Repository und Analyse-Hub für alle Anwendungen einer Organisation dienen kann. Es bietet eine grafische Benutzeroberfläche, die die Verwaltung von Applikationen in unterschiedlichen Versionen über die Zeit erlaubt , und so die Nachverfolgung von z.B. Schwachstellen oder Policy Violations nicht nur während des Entwicklungsprozesses, sondern auch darüber hinaus ermöglicht.

Dependency Track bietet ebenso wie grype die Möglichkeit, die Anwendungen im Repository einer Schwachstellen-Analyse zu unterziehen, jedoch stellt es noch weitere Funktionalität bereit:

• Überwachung von Compliance Policies (z. B. Lizenzrichtlinien, Versionsvorgaben)
• Automatisierte Meldung von Events (z. B. Policy-Verstöße, BOM-Uplooads) über unterschiedliche Kanäle (E-Mail, JIRA-Tickets, Slack u. a.)
• Verwaltung von gefundenen Schwachstellen

Um einen nachhaltigen Nutzen aus SBOMs zu erzielen, ist es notwendig, diese in den Software-Entwicklungs-Workflow zu integrieren und deren Erstellung so weit wie möglich zu automatisieren. Durch diverse Plugins für Build Tools wie Maven oder NPM lassen sich SBOMs schnell und mit wenig Konfigurationsaufwand erstellen. Analysetools wie Dependency-Track erlauben deren direkte Analyse und können beim Überschreiten von Schwellwerten (z.B. der Anzahl an gefundenen “kritischen” Dependencies) ein Abbrechen des Builds triggern.

SBOMs und die Werkzeuge für deren Erstellung und Analyse sind zur Zeit wesentlich durch Compliance-Anforderungen getrieben und haben einen klaren Fokus Richtung sicherheitsrelevante Aufgabenstellungen.

Daher können SBOMs vor allem für die Erhebung des Ist-Zustandes in einem Softwareprojekt herangezogen werden und erlauben eine Bestandsaufnahme der aktuellen Situation hinsichtlich Dependencies, Lizenzen etc.. Durch die zunehmende Zahl an vertraglichen Vorgaben bzw. Compliance-Anforderungen wird auch der Nachweis über deren Erfüllung immer wichtiger. Hier können SBOMs einen Lösungsansatz bieten.

Darüber hinaus können SBOMs über die Zeit bzw. den Entwicklungsprozess einer Applikation in Repositories gesammelt werden und erlauben somit eine spätere Analyse der im Einsatz befindlichen Applikationen. Dadurch können auch Anwendungen, die über einen längeren Zeitraum betrieben werden, laufend auf neue oder kürzlich bekannt gewordene Schwachstellen überprüft werden.

SBOMs stellen in ihrem Wesen nur eine Bestandsaufnahme dar. Ohne weitere Analyse und Bewertung der erhobenen Informationen kann aus diesen jedoch noch kein Mehrwert generiert werden. Erst durch die Auswertung, etwa in Hinblick auf Schwachstellen, die zu den jeweiligen Versionen bekannt sind, kann ein Handlungsbedarf identifiziert werden.

Ob und wie auf diesen Handlungsbedarf reagiert wird, muss jede Organisation bzw. jedes Projekt für sich selbst entscheiden. Das bedeutet, wenn man einen nachhaltigen Mehrwert aus SBOMs generieren möchte, ist es notwendig diese in einen größeren Workflow zu integrieren, der die Informationen als Input für eine weitere Maßnahmenplanung nutzt. Insbesondere ist es notwendig, dass man die Erkenntnisse aus den Auswertungen laufend auf die Relevanz für das eigene Projekt hin bewertet und die Umsetzung der abgeleiteten Maßnahmen überwacht.

Ein weiterer Punkt, den es zu beachten gilt, ist die Tatsache, dass die Werkzeuge im Kontext der SBOM-Erstellung und Analyse stark auf standardisierte Projektstrukturen mit einem automatisierten Dependency-Management setzen. Sollte ein Projekt noch auf andere, weniger standardisierte Build-Mechanismen setzen bzw. das Dependency-Management überhaupt noch manuell umgesetzt werden, wird man die etablierten Werkzeuge kaum nutzen können.

SBOMs stellen einen inzwischen weit verbreiteten standardisierten Ansatz zur Bestandserhebung von Software-Applikationen dar. Sie sind grundsätzlich technologie- und plattform-agnostisch und ermöglichen es somit auch, in heterogenen Systemumgebungen eine einheitliche Analyse der verwendeten Anwendungen zu realisieren.

Aufgrund der Standardisierung lassen sich mittlerweile eine Reihe von kommerziellen als auch Open-Source-Werkzeugen finden, die die Erstellung und Analyse von SBOMs unterstützen. Diese Werkzeuge erleichtern es, die laufende Bestandsaufnahme und Analyse der im Einsatz befindlichen Anwendungen zu automatisieren und damit in bestehende Workflows zu integrieren.