Open-Source-Tool von Microsoft erstellt "Software Bill of Materials"

Inhaltsverzeichnis

Microsoft hat mit Salus ein Open-Source-Werkzeug veröffentlicht, das für Softwareentwicklungsprojekte eine Software Bill Of Materials (SBOM) erstellt. Sie dient als Inventar aller Komponenten eines Projekts und insbesondere dazu, frühzeitig zu erkennen, ob Pakete mit bekannten Schwachstellen verwendet werden.

Zutatenliste für Softwareprojekte

SBOMs listen alle Zutaten eines Softwareprojekts auf. Dazu gehören neben dem direkten Sourcecode interne und externe Dependencies, beispielsweise zu Open-Source-Paketen auf npm oder PyPI. Da die Packages ihrerseits häufig Abhängigkeiten zu anderen Projekten aufweisen, muss in der Software Bill Of Materials die komplette Liste inklusive der transitiven Dependencies enthalten sein. Vergleicht man die SBOM mit einer Zutatenliste für ein Kochrezept, so enthält sie nicht nur die "Gewürzmischung", sondern auch deren einzelnen Inhalte vom Salz bis zum Estragon.

Angesichts der wachsenden Zahl von Angriffen auf die Software Supply Chain hatte das Weiße Haus im Mai 2021 eine Executive Order zum Verbessern der Cybersecurity der USA veröffentlicht, die explizit SBOMs als Methode zur Absicherung der Supply Chain aufführt. Daneben hilft die Software Bill Of Materials dabei, potenzielle Lizenzverletzungen zu vermeiden, indem sie alle Lizenzen der in einem Projekt verwendeten externen Software aufführt.

Abhängigkeiten aufspüren

Salus ist für Windows, Linux und macOS verfügbar. Das Tool wertet den Projektpfad mit dem Sourcecode aus und sucht Projektdateien wie package.json *.csproj. Für die beim Build ausgegebenen Dateien erstellt das Tool einen Hash.

Bei den externen Dependencies kennt Salus Pakete und Inhalte von npm, NuGet, PyPI, CocoaPods, Maven, Gradle, Ivy, Go, Cargo (Rust Crates), RubyGems und öffentlichen GitHub-Repositories. Externe Linux-Pakete untersucht es über das SBOM-Tool syft. Zum Erkennen der Komponenten dient das separate Microsoft-Tool Component Detection, das wie Salus als Open-Source-Projekt auf GitHub verfügbar ist.

Struktur des Inventars

Für die Inventarliste setzt Salus auf das Standardformat SPDX (Software Package Data Exchange), das eine Arbeitsgruppe der Linux Foundation entwickelt hat. Salus erstellt vier Hauptbereiche für die Ausgabe: allgemeine Informationen zur SBOM, eine Liste aller Dateien des Projekts inklusive ihrer Hashes, eine Liste aller Pakete mit dem jeweiligen Namen, der Version, der Quelle und einem Hash sowie eine Liste der Abhängigkeiten und Bezüge zwischen den einzelnen Dateien und Paketen.

Sofern bereits eine SBOM-Datei aus dem Build eines Teilprojekts existiert, nimmt Salus eine Referenz in die erstellte Liste auf und fügt schließlich die einzelnen Listen zu einer endgültigen SBOM zusammen.

Verwundbare Software Supply Chain

Schadcode in Open-Source-Paketen gehört zu den verbreiteten Angriffen auf die Software Supply Chain. Angreiferinnen und Angreifer veröffentlichen auf Paketmanagern vermeintlich nützliche Pakete, die Developer in ihren Anwendungen verwenden. Häufige Methoden sind das Typosquatting und das Brandjacking. Letzteres verwendet Firmennamen wie Twilio, um eine legitime Quelle vorzutäuschen.

Beim Typosquatting tragen die Pakete mit Schadcode Namen, die den Bezeichnungen beliebter Pakete ähneln. Die Methode setzt zum einen auf Tippfehler und verwendet zum anderen Trennzeichen wie Unter- und Bindestriche. Aus my-packet wird my-paket, mypacket oder my_packet. Irgendwer wird sich schon vertippen, so die berechtigte Hoffnung der Angreifenden.

Ein weiterer Angriffsvektor sind zunächst nützliche und harmlose Pakete, die den Schadcode erst dann mitbringen, wenn sie eine gewisse Verbreitung erreicht haben. Das npm-Team hatte 2019 mit electron-native-notify ein solches Package entdeckt. Schließlich versucht Dependency Confusion intern gehostete Dependencies durch gleichnamige externe Pakete mit Schadcode zu ersetzen. Letztere bekommen dazu eine hohe Versionsnummer, da die Paketinstallationswerkzeuge wie pip je nach Einstellung das Paket mit der höchsten Nummer verwenden, das vermeintlich das aktuellste ist.

Gerade gegen die letzten beiden Szenarien helfen SBOMs. Bei der Dependency Confusion lässt sich in der Liste erkennen, dass das verwendete Paket nicht das erwartete interne ist. Gegen im Nachhinein zugefügten Schadcode ist es hilfreich, die Liste regelmäßig nach Einträgen in der CVE-Datenbank (Common Vulnerabilities and Exposures) abzugleichen. SBOMs helfen zudem beim Aufspüren transitiver Dependencies, die nicht auf den ersten Blick erkennbar sind. So hatten viele Teams Log4j beim Erkennen der Schwachstelle nicht direkt in ihre Projekt eingebunden, aber ein externes Paket genutzt, das auf Log4j setzt.

Weitere Details zu Salus lassen sich dem Developer-Blog bei Microsoft entnehmen. Das Tool ist auf GitHub verfügbar. Auf der Releases-Unterseite finden sich Binaries für Linux, macOS und Windows.

(rme)