Salus für Software Bill of Materials (SBOM)

Microsoft baut Open-Source-Tool für sichere Softwareentwicklung

15.07.2022 von Martin Bayer
Mit "Salus" will Microsoft Entwicklern ein quelloffenes Tool zur Verfügung stellen, das ihnen helfen soll, ein Inventar über verwendete Softwarekomponenten zu erstellen.
Den Durchblick im eigenen Quellcode zu behalten wird angesichts der vielen unterschiedlichen in der Entwicklung verwendeten Drittpakete immer schwieriger.
Foto: BEST-BACKGROUNDS - shutterstock.com

Bei einer Software Bill of Materials (SBOM) handelt es sich um ein Verzeichnis der im Rahmen von Entwicklungsprojekten verwendeten Softwarekomponenten. Die Vorteile einer SBOM: Sie bietet Transparenz darüber, welche Pakete verwendet wurden und welche Abhängigkeiten zwischen den einzelnen Komponenten bestehen.

Das soll Unternehmen dabei unterstützen, ihre Softwareentwicklung sicherer zu machen. Mittels einer SBOM lässt sich beispielsweise feststellen, ob Softwarepakete verwendet wurden, die für Schwachstellen bekannt sind. Außerdem können Entwickler sicher gehen, dass sie keine Komponenten verwenden, die von Hackern manipuliert wurden. Unternehmen erhalten zudem einen besseren Überblick darüber, zu welchen Konditionen sie welche Pakete verwenden dürfen. Das hilft, Verstöße gegen Lizenzrechte zu vermeiden.

Salus sei ein universell einsetzbares Tool und arbeite plattformübergreifend, versprechen Denesh Kumar Badlani und Adrian Diglio, beide Manager in Microsofts Entwicklungsabteilung, in einem Blogbeitrag. Unterstützt würden Windows, Linux und MacOS. Das Microsoft-Tool verwendet das Standardformat Software Package Data Exchange (SPDX) für seine Inventare. Salus könne auch auf andere SBOM-Dokumente verweisen, um einen vollständigen Beziehungsbaum zu erfassen, betonen Badlani und Diglio. Dies sei eine wichtige Funktion, um Abhängigkeiten besser erkennen zu können.

Die von Salus generierten SBOMs enthalten Microsoft zufolge vier Hauptabschnitte:

  1. Informationen zur Dokumentenerstellung: Allgemeine Infos über das SBOM-Dokument, wie Softwarename, SPDX-Lizenz, SPDX-Version, wer das Dokument erstellt hat, wann es erstellt wurde usw.

  2. Abschnitt Dateien: Eine Liste der Dateien, aus denen die Software besteht, sowie die dazugehörigen Eigenschaften, wie beispielsweise die Hashes ihres Inhalts (SHA-1, SHA-256).

  3. Abschnitt Pakete: Eine Liste der Pakete, die für die Entwicklung einer Software verwendet wurden. Jedes Paket hat zusätzliche Eigenschaften wie Name, Version, Lieferant, Hashes (SHA-1, SHA-256) und eine Paket-URL (purl) als Software-Identifikator.

  4. Abschnitt Beziehungen: Eine Liste der Beziehungen zwischen den verschiedenen Elementen der SBOM, z. B. Dateien und Pakete.

Salus lasse sich einfach in Entwicklungs-Workflows integrieren, verspricht Microsoft. Mithilfe einer Component Detection erkennt das Tool automatisch verschiedene Komponenten und Pakete wie zum Beispiel NPM, NuGet, PyPI, CocoaPods, Maven, Golang, Rust Crates, RubyGems, Linux-Pakete in Containern, Gradle, Ivy und öffentliche GitHub-Repositories. Diese Component Detection wird Microsoft zufolge laufend mit zusätzlichen Detektoren erweitert. Salus steht Entwicklern als Open-Source Tool auf GitHub zur Verfügung.

Hacker attackieren die Software Supply Chain

Wie wichtig mehr Transparenz im Entwicklungsprozess ist, haben die Entwicklungen der jüngeren Vergangenheit gezeigt. Hacker gehen zunehmend dazu über, Schadecode in Open-Source-Pakete einzuschleusen und so die Software Supply Chain von Unternehmen anzugreifen. Dazu zählen das Typosquatting und das Brandjacking. Beim Typosquatting platzieren die Hacker ihre mit Malware verseuchten Pakete unter ähnlichen Namen wie die regulären Komponenten, und setzen auf Tippfehler beziehungsweise die Unachtsamkeit der Entwickler. Beim Brandjacking verwenden die Angreifer bekannte Firmennamen, um eine seriöse Quelle vorzutäuschen.

Das kann fatale Folgen haben. Eine moderne Applikation besteht heute größtenteils aus Code von Drittanbietern: Laut den Marktforschern von Forrester ist der Open-Source-Anteil an der Codebasis einer Anwendung von 36 Prozent im Jahr 2015 auf 75 Prozent im Jahr 2020 angestiegen. Anwenderunternehmen hoffen, mit Hilfe der vorgefertigten Komponenten ihre Software schneller entwickeln und besser skalieren zu können. Dabei lassen die Betriebe allerdings oft die gebotene Sorgfalt schleifen. Einer Studie der Linux Foundation zufolge verwendet weniger als die Hälfte der befragten Unternehmen eine SBOM, in der genau festgehalten wird, welche Bestandteile der Softwarelieferkette in Anwendungen einfließen.

US-Präsident Joe Biden hat im Mai 2021 per Dekret festgelegt, dass Softwarezulieferer für US-Behörden per SBOM nachweisen müssen, welche Komponenten in ihren Produkten stecken.
Foto: Haditha26 - shutterstock.com

Allerdings wächst Druck, die eigene Softwareentwicklung sicherer zu machen, beispielsweise durch neue Gesetze. Im Mai vergangenen Jahres hat US-Präsident Joe Biden per Verordnung festgelegt, dass Softwarezulieferer für US-Behörden dedizierte SBOMs vorlegen müssen, in denen genau aufgeführt wird, welche kommerziellen und Open-Source-Komponenten ihre Entwicklungen enthalten.