Was ist eine SBOM — und warum fordert der CRA sie?
Eine Software Bill of Materials (SBOM) ist nichts anderes als eine maschinenlesbare Inventarliste sämtlicher Software-Komponenten, aus denen ein Produkt besteht. Jede Bibliothek, jedes Framework, jedes NPM-Paket und jede transitive Abhängigkeit wird darin mit Name, Version, Herkunft und Lizenz erfasst — vergleichbar mit der Zutatenliste auf einem Lebensmittel. Und wie bei Lebensmitteln gilt: Was nicht draufsteht, wissen Sie nicht, was drinsteckt.
Mit dem Cyber Resilience Act (CRA) hat die EU diese Transparenz zur gesetzlichen Pflicht gemacht. Ab dem 11. Dezember 2027 müssen alle Produkte mit digitalen Elementen (PDEs), die auf dem europäischen Markt angeboten werden, eine vollständige SBOM vorweisen können. Ohne SBOM keine CE-Kennzeichnung — und ohne CE-Kennzeichnung kein Marktzugang. Die Botschaft aus Brüssel ist unmissverständlich: Software-Transparenz ist kein Nice-to-have mehr, sondern eine Markteintrittsvoraussetzung.
Dabei geht es nicht um Bürokratie um ihrer selbst willen. Die SBOM ist das Fundament, auf dem jede seriöse Sicherheitsstrategie aufbaut. Ohne zu wissen, welche Komponenten in Ihrer Software stecken, können Sie nicht beurteilen, ob eine neu entdeckte Schwachstelle Sie betrifft. Sie fliegen blind — und das ist im Jahr 2026 kein akzeptabler Zustand mehr.
SBOM-Formate: CycloneDX vs. SPDX
Die SBOM-Welt kennt zwei dominierende Standards — und welcher für Sie der richtige ist, hängt von Ihrem primären Einsatzzweck ab:
OWASP CycloneDX wurde von der Sicherheits-Community entwickelt und ist security-fokussiert. Es erfasst nicht nur welche Komponenten verbaut sind, sondern auch deren bekannte Schwachstellen (Vulnerabilities), den Reifegrad der Komponente und ihre Position im Dependency-Graphen. CycloneDX eignet sich besonders für Threat-Modeling, Vulnerability-Management und die Integration in Security-Toolchains. Das Format ist leichtgewichtig, JSON-basiert und wird von Tools wie Dependency-Track, OWASP ZAP und Syft nativ unterstützt.
Linux Foundation SPDX (Software Package Data Exchange) hat seine Wurzeln im Lizenz-Compliance-Management. Es dokumentiert präzise, unter welcher Lizenz jede Komponente steht — ein Thema, das im Enterprise-Umfeld schnell existenzielle Dimensionen annimmt, wenn GPL-Code in proprietäre Software einfließt. SPDX ist ISO-standardisiert (ISO/IEC 5962:2021) und wird von der Linux Foundation, der OpenChain-Initiative und großen Unternehmen wie Google, Microsoft und Intel getragen.
CycloneDX denkt vom Angriff her, SPDX denkt von der Compliance her. Für vollständige Transparenz brauchen Sie eigentlich beide — und genau das liefert nAIce.
nAIce liefert beide Formate standardmäßig aus. Jeder Build erzeugt automatisch eine CycloneDX-SBOM für das Security-Team und eine SPDX-SBOM für die Rechtsabteilung. Beide sind maschinenlesbar, kryptographisch signiert und versioniert. Sie müssen sich nicht für einen Standard entscheiden — Sie bekommen beide, und zwar ohne Mehraufwand.
Warum eine SBOM Ihr Frühwarnsystem ist
Der Dezember 2021 hat der Software-Welt eine Lektion erteilt, die niemand mehr vergessen wird: Log4Shell (CVE-2021-44228) — eine Schwachstelle in der allgegenwärtigen Java-Logging-Bibliothek Log4j, die als „die kritischste Sicherheitslücke des Jahrzehnts" bezeichnet wurde. Der CVSS-Score: 10.0, das Maximum.
Was dann passierte, war ein Lehrstück über den Wert von Transparenz: Unternehmen, die eine aktuelle SBOM ihrer Software-Produkte und internen Systeme hatten, konnten innerhalb von Minuten feststellen, ob und wo sie Log4j einsetzten. Sie suchten nicht manuell — sie fragten ihre SBOM-Datenbank ab. Ein einfacher grep-Befehl auf einer JSON-Datei gab ihnen in Sekunden die Antwort, für die andere Tage brauchten.
Ohne SBOM begann ein Albtraum: Teams durchforsteten manuell Quellcode-Repositories, befragten Entwickler, scannten Server-Dateisysteme und analysierten JAR-Archive. Die Suche dauerte Tage bis Wochen — wertvolle Zeit, in der die Schwachstelle aktiv ausgenutzt wurde. Laut einer BitSight-Analyse waren 30 Tage nach Bekanntwerden von Log4Shell immer noch 38 % der betroffenen Organisationen ungepatcht.
Die SBOM verwandelt eine Schwachstellenmeldung von einem Panik-auslösenden Ereignis in einen strukturierten Workflow: Benachrichtigung erhalten, SBOM abfragen, betroffene Systeme identifizieren, Patches priorisieren — alles in Minuten, nicht in Wochen. Das ist der Unterschied zwischen einem Frühwarnsystem und Blindflug.
So automatisiert nAIce die SBOM
Eine SBOM, die einmal manuell erstellt und dann nie wieder aktualisiert wird, ist nur geringfügig wertvoller als gar keine. Mit jedem Commit, jedem Dependency-Update und jedem neuen Release ändert sich Ihre Software-Lieferkette — und Ihre SBOM muss diesen Änderungen folgen. Deshalb haben wir die SBOM-Erstellung vollständig in unsere CI/CD-Pipeline integriert:
Syft von Anchore analysiert bei jedem Build den gesamten Abhängigkeitsbaum — inklusive transitiver Abhängigkeiten, Betriebssystem-Pakete und Container-Images. Das Ergebnis ist eine lückenlose Bestandsaufnahme, die keine versteckte Abhängigkeit übersieht.
Grype gleicht diese Inventarliste in Echtzeit gegen mehrere Vulnerability-Datenbanken ab — NVD, GitHub Advisory Database, Wolfi SecDB und weitere. Jede gefundene Schwachstelle wird mit CVSS-Score, Ausnutzbarkeit und Patch-Verfügbarkeit annotiert.
Cosign von Sigstore signiert die fertige SBOM kryptographisch. Damit ist nachweisbar, dass diese SBOM genau zu diesem Build gehört und auf dem Weg vom Build-Server zum Kunden nicht manipuliert wurde — ein essenzielles Kriterium für Audits und Zertifizierungen.
Das Ergebnis ist eine signierte SBOM als Build-Artefakt — automatisch erzeugt, versioniert und manipulationssicher. Und auf Wunsch liefern wir zusätzlich das VEX-Format (Vulnerability Exploitability eXchange), das dokumentiert, welche Schwachstellen für Ihre spezifische Konfiguration tatsächlich ausnutzbar sind — und welche nicht. Das spart wertvolle Zeit beim Triage-Prozess.
# nAIce CI/CD Pipeline — SBOM-Generierung sbom: stage: security image: anchore/syft:latest script: # CycloneDX (security-fokussiert) - syft packages dir:./app -o cyclonedx-json > sbom.cyclonedx.json # SPDX (lizenz-fokussiert) - syft packages dir:./app -o spdx-json > sbom.spdx.json # Vulnerability-Scan mit Grype - grype sbom:sbom.cyclonedx.json -o json > vulns.json # Kryptografische Signatur mit Cosign - cosign sign-blob --key cosign.key sbom.cyclonedx.json - cosign sign-blob --key cosign.key sbom.spdx.json artifacts: paths: - sbom.cyclonedx.json - sbom.spdx.json - vulns.json expire_in: 90 days
SBOM und Supply-Chain-Security
Eine SBOM allein macht Ihre Software nicht sicher — aber sie ist die unerlässliche Voraussetzung für jede ernsthafte Supply-Chain-Security-Strategie. Denn die SBOM beantwortet die grundlegende Frage: „Woraus besteht meine Software eigentlich?" — und ohne diese Antwort können Sie keine der weiterführenden Fragen beantworten.
Hier kommt das SLSA-Framework (Supply-chain Levels for Software Artifacts, ausgesprochen „Salsa") ins Spiel. SLSA definiert vier Sicherheitsstufen — von SLSA 0 (keine Garantien) bis SLSA 3 (vollständig reproduzierbare, manipulationssichere Builds). Auf SLSA 3 ist der gesamte Build-Prozess so abgesichert, dass nachweisbar ist: Dieses Artefakt stammt genau aus diesem Source-Code, gebaut in genau dieser Umgebung, ohne dass ein Mensch oder ein kompromittiertes Tool auf dem Build-Pfad etwas verändern konnte.
Eine signierte SBOM ist das Bindeglied zwischen Source-Code und Build-Artefakt. Zusammen mit Build-Provenienz (einer kryptographisch signierten Aussage darüber, wer, wann, wo und wie gebaut hat) und einem vollständigen Dependency-Graphen entsteht ein lückenloses Vertrauensmodell. Sie können für jede einzelne Komponente in Ihrer Software nachvollziehen: Wo kommt sie her? Wer hat sie gebaut? Welche Schwachstellen sind bekannt? Ist sie seit dem Bau verändert worden?
Für nAIce treiben wir diese Transparenz bis zum LLM-Provider. In Ihrer SBOM sehen Sie nicht nur, welche Python-Pakete und Container-Images wir verwenden, sondern auch welche Sprachmodelle in welcher Version zum Einsatz kommen — inklusive Modell-Hash zur Verifikation. Denn in einer Welt, in der KI-Modelle Teil der Software-Lieferkette sind, muss Transparenz auch die Modell-Ebene umfassen.
SBOM-Checkliste: Diese 5 Fragen sollten Sie Ihrem Software-Anbieter stellen
- Liefern Sie mit jedem Release eine aktuelle, maschinenlesbare SBOM? — Wenn die Antwort nicht „Ja, in CycloneDX und SPDX" lautet, ist Vorsicht geboten.
- Wie stellen Sie sicher, dass die SBOM den tatsächlichen Build-Inhalt abbildet? — Verlangen Sie automatisierte Generierung in der CI/CD-Pipeline, keine manuell gepflegten Excel-Listen.
- Sind Ihre SBOMs kryptographisch signiert? — Ohne Signatur ist die SBOM nicht manipulationssicher und für Audits nur eingeschränkt verwertbar.
- Scannen Sie Ihre Abhängigkeiten automatisiert auf bekannte Schwachstellen? — Fragen Sie nach dem konkreten Tool-Stack (Syft/Grype/Trivy) und der Scan-Frequenz.
- Liefern Sie VEX-Dokumente für gefundene Schwachstellen mit? — Ein VEX sagt Ihnen, ob eine Schwachstelle in Ihrer Konfiguration überhaupt ausnutzbar ist — das spart Stunden an manueller Triage.