Was ist ein SBOM (und warum kannst du ohne keinen Release versenden)?

TL;DR

Ein Software Bill of Materials (SBOM) ist ein maschinenlesbares Inventar aller Komponenten eines Softwareartefakts und spielt eine entscheidende Rolle in der Sicherheit der Software-Lieferkette. Trotz der erkannten Vorteile in der Schwachstellenbewältigung haben viele Organisationen Schwierigkeiten bei der Erstellung von SBOMs. Regulierungen machen SBOMs zunehmend zu einer Voraussetzung für den Softwarevertrieb.

Hauptinhalt

Ein SBOM ist eine strukturierte Auflistung aller Komponenten, Bibliotheken und Module, die in einem Softwareartefakt enthalten sind. Bei containerisierten Anwendungen, wie beispielsweise einem auf Alpine Linux basierenden Containerbild, sind zahlreiche Systempakete und deren Abhängigkeiten beteiligt. Ein SBOM beantwortet die grundlegende Frage, welche Software tatsächlich in der Produktion läuft. Es erfasst die gesamte Abhängigkeitsstruktur und enthält wichtige Metadaten zu jeder Komponente, wie Version, Lizenz und Herkunft.

Ein gut strukturiertes SBOM umfasst mehrere Kategorien von Metadaten für jede Komponente:

• Komponentenidentität: Name, Version und Anbieter der Software (z.B. openssl 3.1.4, verwaltet vom OpenSSL-Projekt).
• Lizenzierung: Art der Lizenz, die die Weiterverbreitung und Nutzung regelt (z.B. MIT, Apache 2.0, GPL).
• Abhängigkeitsbeziehungen: Wie Komponenten voneinander abhängen, einschließlich direkter und transformativer Abhängigkeiten.
• Eindeutige Identifikatoren: Paket-URLs oder SWID-Tags, die eine Kreuzreferenzierung mit Schwachdatenbanken ermöglichen.
• Prüfziffern und Hashes: Kryptographische Hashes, die bestätigen, dass die Komponente nicht verändert wurde.

Die Daten werden unter Verwendung offener Standards, hauptsächlich SPDX oder CycloneDX, strukturiert, um maschinenlesbar und interoperabel zu sein.

SBOMs sind besonders wichtig für die Sicherheit der Software-Lieferkette. Bei der Offenlegung von Schwachstellen, wie der Log4Shell-Sicherheitsanfälligkeit, konnten Organisationen mit aktuellen SBOMs schnell identifizieren, welche Images betroffen waren. Ohne SBOMs mussten Teams oft manuell Abhängigkeiten verfolgen, was zeitaufwendig und fehleranfällig ist.

Ein SBOM ermöglicht eine schnellere Reaktion auf Sicherheitsvorfälle. Bei der Entdeckung einer neuen CVE (Common Vulnerability and Exposure) kann sofort ermittelt werden, wo das Unternehmen exponiert ist. Dies geschieht durch den Abgleich des betroffenen Pakets und der Version mit der SBOM-Bibliothek, was die Reaktionszeit erheblich verkürzt. In Kombination mit kontinuierlichem Schwachstellenscanning wird dieser Prozess weiter automatisiert.

Technische Details/Implikationen

Die Implementierung von SBOMs wird durch neue regulatorische Vorgaben vorangetrieben. In den USA hat die Executive Order 14028 Anforderungen für SBOMs für Software, die an Bundesbehörden verkauft wird, festgelegt. Dies zeigt, dass SBOMs nicht nur eine bewährte Praxis, sondern zunehmend auch eine gesetzliche Anforderung werden. Organisationen, die SBOMs in ihrem Entwicklungs- und Bereitstellungsprozess integrieren, können nicht nur ihre Sicherheitslage verbessern, sondern auch Compliance-Anforderungen erfüllen.

Fazit/Ausblick

Die Integration von SBOMs in den Softwareentwicklungsprozess ist entscheidend für die Sicherheit und Transparenz in der Software-Lieferkette. Angesichts der zunehmenden regulatorischen Anforderungen wird die Fähigkeit, SBOMs effektiv zu generieren und zu verwalten, für Unternehmen von zentraler Bedeutung sein.