Software Bill of Materials (SBOM)

Eine Software Bill of Materials (SBOM) ist ein formales, maschinenlesbares Inventar jeder Komponente in einer Software: Bibliotheken, ihre Versionen, Lizenzen und Lieferanteninformationen.

So wie ein Lebensmitteletikett die Zutaten auflistet, können Sie mit einer SBOM in wenigen Sekunden die Frage beantworten: Enthält dieses Produkt die verwundbare Version von X? Ohne eine SBOM kann die manuelle Suche nach dieser Antwort Tage dauern.

Wenn eine kritische Schwachstelle bekannt wird, lautet die erste operative Frage: Welche unserer Produkte enthalten die betroffene Komponente?

Während des Log4Shell-Vorfalls konnten Organisationen mit SBOMs ihr Inventar abfragen und innerhalb weniger Stunden eine Triage durchführen. Organisationen ohne SBOMs verbrachten Wochen damit, Build-Verzeichnisse mit grep zu durchsuchen. Aufsichtsbehörden und große Abnehmer verlangen SBOMs zunehmend als Bedingung für die Beschaffung.

• Schnelle Analyse der Auswirkungen von Schwachstellen
• Lizenzkonformität und Nachverfolgung von Verpflichtungen
• Transparenz der Lieferkette für Kunden und Prüfer

Zwei offene Standards sind vorherrschend. Tools können in der Regel zwischen ihnen konvertieren.

• SPDX — ein Standard der Linux Foundation, besonders stark bei Lizenzen und von Aufsichtsbehörden weithin akzeptiert
• CycloneDX — ein OWASP-Standard mit Schwerpunkt auf Sicherheit, der Daten zu Schwachstellen und Abhängigkeitsbeziehungen unterstützt

Erfinden Sie kein eigenes Format; Abnehmer und Scanner erwarten diese Standards.

Jeder Komponenteneintrag sollte genügend Identifikationsdaten enthalten, damit er mit Schwachstellen-Feeds abgeglichen werden kann. Die wichtigsten Felder:

• Name und Version — exakt, nicht als Bereich
• PURL (Package-URL) — ein universeller Bezeichner wie pkg:npm/lodash@4.17.21
• Hash — zur Überprüfung der Integrität
• Lizenz — SPDX-Lizenzkennung
• Lieferant — wer die Komponente erstellt hat

Generieren Sie SBOMs automatisch aus dem Quellcode oder aus einem erstellten Artefakt. Syft ist ein verbreiteter Generator für verschiedene Ökosysteme, der beide Standards ausgeben kann.

Eine SBOM, die in verschiedenen Phasen erstellt wird, bildet jeweils andere Gegebenheiten ab.

• Source-SBOM — was das Manifest deklariert; gebündelter oder als Vendor-Code eingebundener Code kann fehlen
• Build-SBOM — was der Build tatsächlich abgerufen hat; für ein Release am genauesten
• Runtime-/Deployed-SBOM — was im laufenden Image tatsächlich vorhanden ist, einschließlich der Betriebssystempakete

Erstellen Sie für die Absicherung der Lieferkette die SBOM zur Build-Zeit aus dem tatsächlichen Artefakt und prüfen Sie den finalen Container zusätzlich auf Pakete der Betriebssystemebene.

Eine SBOM wird besonders nützlich, wenn Sie sie einem Abgleichwerkzeug zuführen, das Komponenten bekannten CVEs zuordnet. Dadurch werden Erzeugung und Analyse entkoppelt: Sie können eine alte SBOM an dem Tag prüfen, an dem eine neue CVE veröffentlicht wird.

Eine SBOM kann eine verwundbare Komponente ausweisen, die in Ihrem Produkt tatsächlich nicht ausnutzbar ist, weil die verwundbare Funktion nie aufgerufen wird. Ein VEX-Dokument (Vulnerability Exploitability eXchange) hält diese Bewertung fest.

VEX reduziert das Rauschen: Statt dass jeder Kunde wegen einer aufgeführten CVE in Panik gerät, veröffentlichen Sie eine begründete Erklärung mit not_affected oder eine Erklärung mit affected und Maßnahmen zur Behebung. So wird aus einem rohen Inventar eine verwertbare Triage.

Eine SBOM ist nur dann vertrauenswürdig, wenn sie authentisch ist und eindeutig mit dem exakten Artefakt verknüpft ist, das sie beschreibt. Signieren Sie sie und hängen Sie sie als Attestation an, statt sie als lose Datei abzulegen.

Manuell erstellte SBOMs veralten sofort. Integrieren Sie die Generierung in die Pipeline, sodass bei jedem Release eine SBOM erstellt und als Build-Artefakt gespeichert wird, idealerweise im selben Job signiert und geprüft.

• Erstellen Sie sie aus dem erstellten Artefakt, nicht nur aus dem Repository
• Speichern Sie SBOMs in einer abfragbaren Registry, die nach Version indiziert ist
• Prüfen Sie gespeicherte SBOMs regelmäßig anhand aktueller CVE-Feeds erneut
• Koppeln Sie die Release-Freigabe an das Ergebnis der Schwachstellenprüfung

SBOMs scheitern unbemerkt, wenn sie nur als Pflichtübung behandelt werden.

• Veraltet — einmal erstellt und nie wieder neu generiert
• Unvollständig — Betriebssystempakete sowie statisch gelinkter oder als Vendor-Code eingebundener Code fehlen
• Nicht verifiziert — kein Hash verknüpft die SBOM mit dem bereitgestellten Artefakt
• Unverwendet — erstellt, aber nie geprüft oder abgefragt

Das Ziel ist eine korrekte, neu generierte, signierte und kontinuierlich geprüfte SBOM, nicht eine einmalige JSON-Datei.

Wenden Sie das Gelernte auf ein Vorfallszenario an.

Sie können nun erfassen, was Ihre Software enthält, und entsprechende Maßnahmen ergreifen.

• Eine SBOM ist eine maschinenlesbare Liste jeder Komponente im SPDX- oder CycloneDX-Format
• Identifizieren Sie Komponenten anhand von PURL, Version, Hash und Lizenz
• Erstellen Sie die SBOM zur Build-Zeit und führen Sie sie anschließend einem Abgleichwerkzeug (grype, osv-scanner) zu, um CVEs zu ermitteln
• Verwenden Sie VEX, um die tatsächliche Ausnutzbarkeit anzugeben und Fehlalarme zu reduzieren
• Signieren und automatisieren Sie die SBOMs in der CI und prüfen Sie gespeicherte SBOMs anhand neuer Feeds erneut

Als Nächstes weisen Sie mit Signaturen die Herkunft von Artefakten nach.