Was ist eine SBOM?
Eine Software Bill of Materials (SBOM) ist ein maschinenlesbares Verzeichnis aller Komponenten, Bibliotheken und Abhängigkeiten einer Software – jeweils mit Version, Herkunft und Lizenz.
Die Stückliste für Software
Der Begriff kommt aus der Industrie. Eine Bill of Materials – auf Deutsch Stückliste – listet jedes Bauteil eines Produkts auf, von der Schraube bis zur Platine. Wer weiß, welches Teil wo verbaut ist, kann bei einem Rückruf gezielt reagieren.
Eine SBOM überträgt diese Idee auf Software. Moderne Anwendungen bestehen zum Großteil aus fremdem Code: Frameworks, Bibliotheken und deren transitive Abhängigkeiten. Eine einfache Next.js-Webseite bringt es schnell auf mehrere hundert npm-Pakete. Die SBOM hält fest, welche Pakete in welcher Version enthalten sind, woher sie stammen und unter welcher Lizenz sie stehen – und zwar in einem Format, das Maschinen auswerten können.
Wozu braucht man eine SBOM?
Wer weiß, woraus die eigene Software besteht, kann in drei Situationen schneller und sicherer handeln:
- Schwachstellenmanagement: Als im Dezember 2021 die Lücke Log4Shell (CVE-2021-44228) in der Java-Bibliothek Log4j bekannt wurde, mussten viele Organisationen tagelang suchen, wo Log4j überhaupt im Einsatz war. Mit einer SBOM genügt ein automatisierbarer Abgleich, und die Frage ist in Minuten beantwortet.
- Lizenz-Compliance: Jede Abhängigkeit bringt eine Lizenz mit. Eine SBOM macht sichtbar, ob sich etwa eine GPL-Bibliothek in ein proprietäres Produkt eingeschlichen hat.
- Sichere Lieferkette: Kompromittierte Pakete in öffentlichen Registries sind ein reales Risiko. Die SBOM dokumentiert Herkunft und Prüfsummen und macht Veränderungen zwischen zwei Releases nachvollziehbar.
Seit 2024 kommen konkrete rechtliche Anforderungen an Hersteller vernetzter digitaler Produkte hinzu:
- EU Cyber Resilience Act: Der CRA (Verordnung 2024/2847) ist seit dem 10. Dezember 2024 in Kraft. Seit dem 11. September 2026 gelten die Meldepflichten für aktiv ausgenutzte Schwachstellen, ab dem 11. Dezember 2027 gilt die Verordnung vollständig. Hersteller von Produkten mit digitalen Elementen müssen dann unter anderem eine SBOM erstellen und als Teil der technischen Dokumentation vorhalten.
- BSI TR-03183: Die Technische Richtlinie „Cyber-Resilienz-Anforderungen an Hersteller und Produkte“ des BSI konkretisiert in Teil 2, welche Felder eine SBOM enthalten muss. Die aktuelle Version 2.1.0 setzt CycloneDX ab Version 1.6 oder SPDX ab Version 3.0.1 voraus.
Formate: CycloneDX und SPDX
Zwei offene Standards haben sich durchgesetzt:
- CycloneDX stammt von der OWASP Foundation und ist als ECMA-424 standardisiert. Das Format ist auf Sicherheitsanwendungen ausgerichtet und kann neben Komponenten auch Abhängigkeitsgraphen, Schwachstellen (VEX) und Dienste beschreiben.
- SPDX (Software Package Data Exchange) wird von der Linux Foundation gepflegt und ist als ISO/IEC 5962 standardisiert. Der Ursprung liegt in der Lizenz-Compliance, daher ist SPDX dort besonders ausdrucksstark.
Beide Formate gibt es als JSON. Die meisten Werkzeuge können beide erzeugen; für Schwachstellen-Workflows ist CycloneDX in der Praxis verbreiteter.
So machen wir es bei Netronaut
Bei Netronaut endet die Arbeit nicht mit der SBOM:
- Bei jedem Release wird automatisch eine aktuelle SBOM erzeugt.
- Fortlaufend gleichen wir sie mit Schwachstellendatenbanken ab – auch für Projekte, an denen gerade niemand entwickelt.
- Im Ernstfall prüfen wir, ob die Lücke im jeweiligen Projekt tatsächlich ausnutzbar ist, und informieren Sie.
- Automatisierte Updates halten die Abhängigkeiten aktuell, damit Projekte gar nicht erst veralten.
Sie möchten Sicherheit fest im Lebenszyklus Ihrer Software verankern? Wir beraten Sie gern.
Jetzt unverbindlich beraten lassen