Governance: Software Bill of Materials (SBOM)

In jedem Entwicklungsprozess, in dem nicht das Rad neu erfunden werden soll, werden Abhängigkeiten von Drittanbietern eingesetzt, sei es durch Open Source Komponenten oder eingekaufte Komponenten. Doch mit der Nutzung solcher Abhängigkeiten stellt sich die Frage: Woher kommen die Abhängigkeiten, wie sind sie lizenziert und wie werden sie langfristig aktuell gehalten, falls Sicherheitslücken auftreten?

Zum Job eines Softwareentwicklers gehört neben dem Heraussuchen einer Komponente entsprechend ihrer Funktionalität auch das Bewerten der Komponente nach nicht-funktionalen Anforderungen wie Lizenzbedingungen, Vertrauenswürdigkeit, Aktualität sowie Pflege und Wartung. Und das nicht nur beim Aussuchen der Komponente, sondern auch regelmäßig danach, um auf Sicherheitslücken aufmerksam zu werden oder wie kürzlich auch immer wieder hochgekommen, weil sich doch mal die Lizenz einer Komponente verändert und dies nur mit einer neuen Versionsnummer gekennzeichnet wird.

Aber nicht nur für die eigene Absicherung, sondern auch weil immer mehr Gesetze verpflichtend machen, dass man eine Software Bill of Materials mit ausliefert, ist dieses Thema sehr relevant bei der Softwareentwicklung geworden.

Erstellung einer SBOM

Wie kann also eine Software Bill of Materials erstellt werden, um all die Anforderungen wie Lizenzen, Vulnerabilities aber auch das Ausliefern einer SBOM zu erfüllen?

Zuallererst geht es darum, zu klären, welchen Anwendungsfall man abdecken möchte. Viele Paketmanager bringen heute von Haus aus schon Funktionalität mit, um zum Beispiel Lizenzen zu listen oder auch verwendete Pakete auf Vulnerabilities zu prüfen.

Die dotnet CLI zum Beispiel zum Verwalten von NuGet-Paketen kann mit dotnet list package --vulnerable eine Übersicht generieren, welche Pakete Schwachstellen haben und was es zu tun gibt, um diese Schwachstellen zu beheben. Auch npm bietet mit npm audit eine Möglichkeit, die verwendeten Pakete auf Schwachstellen zu untersuchen.

Doch zuallererst geht es darum, zu klären, welche Pakete überhaupt verwendet werden. Hierbei gibt es eine Unterscheidung zwischen direkten Abhängigkeiten und transitiven Abhängigkeiten. Transitive Abhängigkeiten sind dabei Abhängigkeiten von Paketen, die man selbst nutzt, also sozusagen Abhängigkeiten von Abhängigkeiten.

Hierbei ist es als erster Schritt wichtig zu wissen, welche Pakete man insgesamt in welchen Versionen überhaupt in seiner Anwendung einbindet. Genau hier kommt die SBOM wieder ins Spiel. Denn im ersten Schritt ist es genau die Aufgabe dieser, eine komplette Liste zu erstellen mit allen Komponenten und den Versionsnummern, die in einer Anwendung verbaut sind.

Das Format einer SBOM gibt es mittlerweile standardisiert. Hier kann man auf SPDX (Software Package Data Exchange) oder CycloneDX zurückgreifen. SPDX wird von der Linux Foundation verwaltet und ist als ISO-Norm verfügbar. CycloneDX kommt von der OWASP Foundation und gibt es als Ecma-Standard. Beide Formate beschreiben in eigener Art und Weise die verwendeten Abhängigkeiten, deren Version, Autor und noch mehr. Mittlerweile sind diese Standards nicht nur für Software-Abhängigkeiten, sondern z.B. auch für verwendete ML-Modelle und anderes in Verwendung.

Auf Basis der SBOM können nun mit zusätzlichen Tools weitere Informationen abgefragt werden, wenn diese im ersten Lauf nicht verfügbar sind, wie zum Beispiel Lizenzinformationen des Pakets in der genannten Version oder auch aktuelle Schwachstellen.

Hierbei kann sich dann auch eine gesamte Toolchain ergeben, bei der zuerst die Liste der Abhängigkeiten und deren Abhängigkeiten erstellt wird, dann die Lizenzinformationen abgefragt werden und separat noch mal die aktuellen Schwachstellen.

Die Verwendung des Formats oder welche Spezifikation genutzt werden soll, kommt am Ende auf die eigenen Anforderungen an. Wer keine bestimmten Präferenzen hat, ist mit CycloneDX gut bedient, da es eine weite Verbreitung und eine gute Toolanbindung hat. Das Format ist auch nicht zwangsläufig ein Lock-In, da auch zwischen den Formaten konvertiert werden kann (z.B. mit der CycloneDX CLI) oder im Zweifel einfach auf das andere mit dem Tooling umgestellt werden kann.

Nutzung von CycloneDX

Im Folgenden gehen wir weiter auf CycloneDX ein. Mithilfe von CycloneDX CLI und dessen CLI-Tools kann für unterschiedliche Paketmanager eine SBOM erstellt werden. Unterstützung für NuGet, npm, pip (Python) und andere ist bereits integriert. Zum Erstellen der SBOM können je nach Paketmanager eigene Tools genutzt werden. Für .NET gibt es ein CycloneDX .NET CLI-Tool, für npm gibt es ein CycloneDX npm-Paket.

Wer eine Komplettlösung haben möchte, kann auf Syft zurückgreifen. Diese unterstützt über eine einfache CLI die Generierung von SBOMs für viele verschiedene Paketmanager wie npm, NuGet und Co, aber auch z.B. Docker-Images und die dort installierte Software.

Weiterverarbeitung der SBOM

Doch was macht man jetzt mit der SBOM? Nun kommen weitere Tools zum Einsatz, um basierend auf der SBOM entweder Lizenzinformationen, Schwachstellen oder ähnliches abzurufen. Hier gibt es z.B. Grype als Aufbau zu Syft, um auf Vulnerabilities in den Abhängigkeiten zu prüfen.

Am Ende reicht es aber nicht, ein CLI-Tool einmalig auszuführen, um im aktuellen Moment auf Vulnerabilities aufmerksam zu werden. Es bedarf vielmehr einer Plattform, die diese Prüfungen kontinuierlich durchführt. Über solche Plattformen lassen sich dann auch Regelwerke z.B. für zulässige Lizenztypen oder Benachrichtigungen für neu erkannte Vulnerabilitäten etablieren. Und ganz nebenbei ermöglichen sie grafisch aufbereitete und leicht navigierbare Übersicht der Abhängigkeiten einer Software.

Eine solche Plattform ist Dependency-Track, ebenfalls von der OWASP Foundation. Diese ist Open Source und kann selbst gehostet werden. Mit einem minimalen Setup kann man sich so beispielsweise in seiner eigenen Azure-Umgebung diese Plattform selbst betreiben. Vorteil von diesem ist, dass man seine SBOM regelmäßig in der Pipeline generieren kann, diese in Dependency-Track einspielen, um einen kontinuierlichen Check auf Lizenzverstöße oder Vulnerabilities zu haben. Aber auch Dependency Track selbst prüft regelmäßig auf neue Vulnerabilities und benachrichtigt entsprechend.

Wie gehst du mit der Erstellung und Verwaltung von SBOMs in deinen Projekten um? Schau gerne bei uns auf LinkedIn vorbei und diskutiere mit.