Software Development Framework Drei Mindestanforderungen einer SBOM

Anbieter zum Thema

OutSystems

Die Software-Bill-of-Materials, kurz SBOM, etabliert sich als fester Bestandteil eines sicheren Software Development Frameworks. Doch Stückliste ist nicht gleich Stückliste. Was es hinsichtlich zu beachten gilt, zeigt der Blick auf die Mindestanforderungen beim Erstellen einer SBOM.

Kommerzielle Anwendungen werden nicht aus einem Code-Block geschlagen, sondern gleichen vielmehr einem Mosaik aus Millionen von Codebasen. Um schneller und gezielter arbeiten zu können, nutzen Entwickler in der Regel eine Vielzahl an OSS-, sprich Open-Source-Software-Komponenten sowie Drittanbieter-Code aus unterschiedlichsten Quellen.

Mehr Transparenz, weniger Risiken

Zwar sind Ökosysteme wie die Apache Software Foundation oder die Eclipse Foundation sowie Artefakt-Repositories wie Maven Central (Java), NuGet (.NET), npm (JS), PyPI (Python) und RubyGems (Ruby) in der Entwicklerszene weithin respektiert. Sie unterliegen jedoch nicht immer denselben Kontrollen wie kommerzielle Standardsoftware. Das Gleiche gilt für Komponenten einzelner Entwickler auf beliebten Quellcode-Repositories wie GitHub oder GitLab.

Entlang der Software Supply Chain finden sich daher oft Wissenslücken, was die Herkunft, Version, Lizenzierung sowie den Inhalt von Komponenten angeht – und damit auch potenzielle Sicherheits- und Compliance-Risiken. Die SBOM soll hier Transparenz schaffen und Nachverfolgbarkeit über interne wie externe Code-Quellen ermöglichen. Idealerweise finden sich in der SBOM nicht nur detaillierte und hierarchisch aufgeschlüsselte Daten über die jeweiligen Komponenten und Subkomponenten, sondern auch deren Abhängigkeiten.

Drei Anforderungen an die SBOM

Noch fehlt es an dem einen Standard, dem alle Entwicklern und Anbietern beim Erstellen einer Software-Stückliste folgen können. Die hier angeführten Mindestanforderungen orientieren sich an den Empfehlungen der US-Regierung, die im Zusammenhang mit der Executive Order zur Cybersecurity 2021 veröffentlicht wurden. Der Leitfaden konzentriert sich auf drei Bereiche: Die in der Stückliste auszufüllenden Datenfelder, den Automatisierungsgrad der Formate sowie die zu beachtenden Praktiken und Prozesse.

1. Datenfelder

SBOM stellen eine Art Inventarliste dar, in der alle in einer Software eingesetzten Code-Komponenten dokumentiert sind. Die Datenfelder der Stückliste enthalten Basisinformationen, die Entwicklern, Softwareanbietern und Anwendern helfen, eine Komponente eindeutig zu identifizieren und so beispielsweise auf bekannte Schwachstellen oder fehlende Lizenzierungen hin zu überprüfen. Zu den Basisinformationen zählen:

• Name des Anbieters: Organisation, Unternehmen oder Gruppe, die die Komponenten erstellt, definiert und identifiziert (z. B. Softwareanbieter)

• Name der Komponente: Die vom ursprünglichen Anbieter zugewiesene Bezeichnung

• Version der Komponente: Die vom Anbieter verwendete Kennung, um Änderungen einer Software gegenüber einer früheren Version anzugeben

• Unique Identifiers (UI): Zusätzliche Identifikatoren, die eine eindeutige Zuordnung ermöglichen (z. B. kryptografischen Hashes)

• Abhängigkeiten: Die direkte oder transitive Abhängigkeit einer Komponenten zu einer anderen (z. B. Child/Parent Component)

• Verfasser/Autor: Der Name der Entität, welche die SBOM-Daten einer bestimmten Komponente erstellt

• Zeitstempel: Datum und Uhrzeit der SBOM-Datenerstellung

Die Datenfelder dienen in erster Linie dazu, die Komponenten zu identifizieren und sie anderen Datenquellen zu zuordnen. Herausforderungen sind dabei vorprogrammiert. Verschiedene Stakeholder entlang der Software Supply Chain nutzen unterschiedliche Dokumentationswege bei der Weitergabe von Software-Komponenten. Und selbst Angaben über den kommerziellen Softwareanbieter sind nicht immer einfach zu treffen (Stichwort: Übernahmen, Open-Source-Forking).

Die Komplexität des Software-Ökosystems setzt daher eine gewisse Flexibilität voraus. Als grundsätzliche Orientierung bei der Datenangabe können weit verbreitete UIs dienen. Dazu gehören u. a. Common Platform Enumeration (CPE), Software Identification (SWID) Tags und Package Uniform Resource Locators (PURL).

Automatisierte SBOM-Lösungen helfen zudem, eine konsolidierte Sicht auf die Bestandteile einer Software zu schaffen. Sie aggregieren Daten ganzheitlich über unterschiedliche Quellen hinweg, um sie anschließend abzugleichen, zu normalisieren und in eine Software-Stücklisten zu überführen. Informationen von vorgelagerten Upstream-Partnern und Drittanbietern werden dabei genauso erfasst wie Daten aus SCA-Scans, OSS-Libraries und anderen Data Services.

2. Automatisierungsgrad

Ein hoher Automatisierungsgrad beim Erstellen der SBOM ermöglicht einen hohen Automatisierungsgrad beim Auslesen der SBOM – und das über die Grenzen der eigenen Entwicklungsabteilung hinweg. Strukturierte, einheitliche Datenformate und Austauschprotokolle sind grundlegend, um Maschinenlesbarkeit sicherzustellen und die Daten der Software-Stückliste für andere Prozesse (z. B. Software Vulnerability Management) zu nutzen.

In der Praxis haben sich in den vergangenen Jahren Quasi-Standards etabliert, die in Zusammenarbeit mit Initiativen und Organisationen entstanden sind und der SBOM als Bauplan zugrunde liegen. Wichtiges Merkmal: Die Formate gelten hinsichtlich der Basisinformationen als interoperabel und verwenden eine gemeinsame Datensyntax. In Kombination mit automatisierten SBOM-Lösungen lassen sich Daten so trotz unterschiedlicher struktureller Notation zusammenführen und vereinheitlichen.

Software Package Data eXchange (SPDX)

Quelloffenes Standardformat der Linux Foundation mit Fokus auf Open Source Software (OSS) und Lizenzmanagement. SPDX liefert viele der oben angeführten Basisinformationen, darunter Informationen zum Softwarepaket sowie Metadaten.

CycloneDX

Weiterentwicklung des SPDX-Formats durch das Open Web Application Security Project® (OWASP). Im Vordergrund stehen Sicherheitsaspekte wie das Identifizieren von Software Vulnerabilities sowie die die Analyse veralteter Komponenten.

Software-Identifikations-Tags (SWID)

Kennzeichnung nach ISO/IEC 19770-2 mit wichtigen Spezifikationen zum Management und Identifizieren von Softwareprodukten.

3. Praktiken und Prozesse

Eine akribisch geführte Liste an Software-Bestandsteilen ist nur dann zielführend, wenn sie auch praktischen Nutzen für den Software Development Life Cycle (SDLC) bringt. Dazu ist wiederum die Implementierung bestimmte Praktiken und Prozesse beim Erstellen, dem Anpassen und der Weitergabe der SBOM nötig.

Softwareanbieter sollten diese Vorgehensweisen, wenn möglich, genau definieren und in ihre Richtlinien bzw. Verträge mitaufnehmen. Welche Praktiken dabei Priorität haben, hängt von der Software selbst sowie von der Branche und dem Unternehmen ab. Hier sind einige Beispiele für erfolgreiches SBOM-Management:

Häufigkeit: Stücklisten sind wie die Software, die sie beschreiben, nicht in Stein gemeißelt, sondern erfordern eine kontinuierliche Anpassung und Pflege. Wird eine Komponente mit einem neuen Build oder Release aktualisiert, braucht es auch eine neue Version der Stückliste. Erfährt der Anbieter neue Details über eine zugrunde liegende Komponenten oder korrigiert er einen Fehler in den bestehenden Stücklistendaten, ist eine Überarbeitung fällig.

Tiefe: Eine SBOM sollte alle Top-Level-Komponenten so detailliert aufführen, dass die jeweiligen direkten oder transitiven Abhängigkeiten zumindest rekursiv ermittelt werden können. Der ersten Ebene folgen die jeweiligen Subkomponenten in ihrer hierarchischen Verzweigung. Eine solche Informationstiefe ist nicht immer realisierbar. Je mehr sich die SBOM jedoch in der Praxis durchsetzt, desto einfacher sollte die lückenlose Dokumentation gelingen.

Bekannte Unbekannte: Ist eine vollständige Abbildung der Abhängigkeiten in der Stückliste nicht möglich, ist darauf ausdrücklich hinzuweisen. So wird klar, ob eine Komponente tatsächlich in keiner (weiteren) Abhängigkeit zu einer anderen Komponenten steht, oder ob dafür einfach die Informationen fehlen.

Distribution und Bereitstellung: SBOMs sollten Beteiligten in der Software Supply Chain möglichst einfach und zeitnah zur Verfügung stehen. Die SBOM-Daten können z. B. jeder Instanz der Software beigefügt oder direkt der spezifischen Version der betreffenden Software zugeordnet werden (z. B. über eine versionsspezifische URL).

Zugangskontrolle: In welchem Umfang eine SBOM veröffentlicht wird, hängt von unterschiedlichen Faktoren ab. Während viele Entwickler aus dem Open Source-Umfeld für eine komplette Offenlegung plädieren, gehen andere Anbieter weit selektiver vor und beschränken die Zugriffsrechte auf unmittelbare Stakeholder. Ist eine Zugangskontrolle gewünscht, sollten die Rahmenbedingungen einschließlich spezifischer Erlaubnisse und Vorkehrungen für die Integration von SBOM-Daten in Sicherheitstools von Anwendern genau abgesteckt werden.

Der Blick auf die Mindestanforderungen einer SBOM zeigt: Trotz der angeführten Best Practices gibt es für Entwickler, Anbieter und Anwender noch viele offene Fragen zu klären. Das SBOM-Management befindet sich noch in der Entwicklung und erlaubt damit noch einen gewissen Spielraum.

Das sollte jedoch kein Argument sein, um mit der Erstellung von Software-Stücklisten abzuwarten. Dafür ist zum einen die Bedrohung durch Cyberattacken zu groß. Zum anderen pochen schon jetzt viele Unternehmen beim Kauf von Softwareprodukten auf eine Auflistung aller Komponenten.

Oft wird die SBOM sogar als Teil der SLA vertraglich festgesetzt. Das zentrale und automatisierte Management der Software-Bill-of-Materials wird damit über kurz oder lang zum festen Bestandteil eines sicheren Software Development Frameworks.

* Nicole Segerer ist Vice President of Product Management & Marketing bei Revenera.

(ID:48589243)