Was ist ein SBOM und warum ist es wichtig?
Kurzantwort
Ein SBOM ist ein maschinenlesbares Inventar jeder Komponente, Bibliothek und Abhängigkeit in einer Software, mit Versionen und idealerweise Hashes. Es ist wichtig, weil man bei einer neuen Schwachstelle seine SBOMs abfragen kann, um sofort zu beantworten «Sind wir betroffen und wo?», statt in Hektik zu verfallen. Die beiden dominierenden Standards sind SPDX und CycloneDX, und SBOMs werden zunehmend durch Regulierung und Beschaffung gefordert.
Eine Software Bill of Materials (SBOM) ist für Software das, was eine Zutatenliste für Lebensmittel ist: eine vollständige, maschinenlesbare Liste dessen, was darin enthalten ist.
Was darin steht
Ein SBOM zählt jede Komponente auf, aus der eine Anwendung besteht — direkte und transitive Abhängigkeiten, ihre Versionen, Lieferanten und idealerweise kryptografische Hashes und Lizenzdaten. Es erfasst auch Beziehungen, sodass man sehen kann, welche Komponente von welcher abhängt. Da es sich um strukturierte Daten handelt, können Tools es automatisch verarbeiten, statt dass ein Mensch eine Liste liest.
Warum es wichtig ist
Der entscheidende Anwendungsfall ist die Geschwindigkeit der Incident Response. Als Log4Shell bekannt wurde, verbrachten Organisationen Tage oder Wochen allein damit herauszufinden, ob sie das anfällige Log4j verwendeten und wo. Mit hinterlegten SBOMs für jeden Build wird daraus eine Abfrage: «Zeige mir jedes Artefakt, das log4j-core < 2.17 enthält.» Über Vorfälle hinaus unterstützen SBOMs die Lizenz-Compliance, die Bewertung von Lieferantenrisiken und — zunehmend — Beschaffungs- und Regulierungsanforderungen (z. B. trieb die US Executive Order 14028 SBOMs in die föderalen Software-Lieferketten).
Die beiden Standards
- SPDX — ein ISO/IEC-Standard, ursprünglich auf Lizenz-Compliance ausgerichtet, inzwischen breit aufgestellt.
- CycloneDX — ein OWASP-Projekt, das mit Security-First entworfen wurde, mit starker Unterstützung für Schwachstellen (VEX) und Abhängigkeitsbeziehungen.
Die meisten Tools können beide ausgeben. Erzeugen Sie das SBOM während des Builds, nicht danach, damit es genau das widerspiegelt, was ausgeliefert wurde, und speichern Sie es als versioniertes Artefakt neben der Binärdatei.
Worauf Interviewer achten
Sie wollen die Incident-Response-Einordnung, das Bewusstsein für SPDX vs. CycloneDX und die Erkenntnis, dass ein SBOM nur dann nützlich ist, wenn es zur Build-Zeit erzeugt und tatsächlich gespeichert und abfragbar ist.
Wahrscheinliche Anschlussfragen
- Was sind die Unterschiede zwischen SPDX und CycloneDX?
- Zu welchem Zeitpunkt in der Pipeline sollte ein SBOM erzeugt werden?
- Wie hilft ein SBOM bei einem Vorfall wie Log4Shell?