Die meisten Teams, mit denen ich spreche, können eine SBOM erzeugen. Weit weniger können sagen, ob sie vollständig ist, wer sie signiert hat, wo die Version vom letzten Jahr liegt oder was passiert, wenn eine neue CVE auf eine ihrer Komponenten passt. Im Oktober 2026 hat ENISA die Technical Advisory for Software Bill of Materials veröffentlicht, und genau um diese zweite Gruppe von Fragen geht es darin. Dieser Artikel fasst die Empfehlung zusammen und ergänzt Anmerkungen aus unserer eigenen SCA-Arbeit.
Was die Empfehlung ist und was nicht
Die Empfehlung ist die endgültige Fassung eines Dokuments, das als Entwurf mit dem Titel “SBOM Landscape Analysis: Towards an implementation guide” begann. ENISA stellte diesen Entwurf zwischen dem 17. Dezember 2025 und dem 23. Januar 2026 zur Konsultation und erhielt 67 Beiträge. Sie stützt sich außerdem auf die Umfrage SBOM Adoption State of Play 2026, veröffentlicht im Juni 2026, und auf eine Prüfung durch den SBOM-Arbeitsstrang der CRA Expert Group zwischen dem 31. Juli und dem 11. September 2026. Die Rückmeldungen überzeugten ENISA, aus dem Entwurf eine technische Empfehlung zu machen, im selben Format wie die Empfehlung zur sicheren Nutzung von Paketmanagern.
Ein paar Dinge sollten Sie vor der Lektüre wissen:
- Sie richtet sich an Organisationen, die gerade mit SBOMs beginnen, vor allem KMU und Verantwortliche für Open-Source-Projekte. Ein Reifegradmodell bietet sie bewusst nicht.
- Sie ist eine Handreichung. Die Empfehlungen sind nicht verpflichtend, ENISA betont, dass das Dokument keine rechtliche Auslegung des CRA ist, und manche Praktiken gehen über die Anforderungen des CRA hinaus.
- Sie behandelt nur Software. Stücklisten für KI, Hardware und Kryptografie sind ausgenommen.
- Sie steht unter der Lizenz CC BY 4.0 und folgt den Prinzipien von ENISAs Secure by Design and Default Playbook.
ENISA übernimmt die CRA-Definition einer SBOM: ein formelles Verzeichnis mit Einzelheiten und Lieferkettenbeziehungen der Komponenten in den Software-Elementen eines Produkts mit digitalen Elementen. Dann macht sie einen Punkt, den man jedem wiederholen sollte, der SBOMs als Compliance-Liefergegenstand behandelt. SBOMs sind laut ENISA eine grundlegende Datenschicht und keine vollständige Sicherheitslösung. Der Wert entsteht durch das, was Sie damit tun: Patchen, dokumentierte Entscheidungen zu Schwachstellen, Lizenzprüfungen und Beschaffung.
Die Lücke zwischen Bedarf und Lieferung
Die Empfehlung zitiert durchgehend die State-of-Play-Umfrage, und die Zahlen erklären, warum sie dem Lebenszyklus mehr Raum gibt als der Erzeugung.
| SBOM-Tiefe | Organisationen, die sie brauchen | Organisationen, die sie erhalten |
|---|---|---|
| Alle Primärkomponenten und direkten Abhängigkeiten, mit deklarierten Known Unknowns | 36% | 29% |
| Vollständige Tiefenanalyse | 24% | 14% |
| Tiefenanalyse einschließlich deklarierter Known Unknowns | 27% | 12% |
Ein “Known Unknown” ist eine Komponente, deren Abhängigkeiten nicht ermittelt werden konnten und die als solche in der SBOM deklariert ist, statt stillschweigend zu fehlen. Abnehmer wollen wissen, wo die blinden Flecken liegen.
Die Automatisierung erzählt dieselbe Geschichte. 41% der Befragten wollen die SBOM-Erzeugung für jeden Build oder jedes Release vollständig automatisieren, aber nur 26% erwarten, SBOM-Aktualisierungen über den gesamten Unterstützungszeitraum vollständig zu automatisieren, und rund 23% erwarten eine teilweise Automatisierung. Eine SBOM zu erzeugen ist weitgehend ein gelöstes Problem. Sie genau zu halten, solange das Produkt unterstützt wird, ist es nicht.
Was in eine SBOM gehört
ENISA definiert keine eigene Feldliste. Sie stellt die beiden Baselines gegenüber, auf die die meisten Organisationen stoßen werden: die TR-03183-2 des BSI (Version 2.1.0) und die 2026 Minimum Elements for a Software Bill of Materials der CISA, im Sommer 2026 als gemeinsame Leitlinie mit NSA, FBI und Partnerbehörden in anderen Ländern veröffentlicht.
Der Kern ist in beiden gleich: wer die SBOM wann erstellt hat und für jede Komponente Ersteller, Name, Version, Bezeichner, Hash, Lizenz und Abhängigkeiten. Die Unterschiede liegen im Detail.
| Nur in BSI TR-03183-2 | Nur in den CISA 2026 Minimum Elements |
|---|---|
| SBOM-URI | SBOM-Version |
| Getrennte URIs für den Quellcode einer Komponente und ihre auslieferbare Form | Name und Version des SBOM-Datenformats |
| Hash des Quellcodes der Komponente (optional) | Signatur des SBOM-Autors |
| Vertriebs-, Original- und effektive Lizenz als getrennte Felder | Name und Version des Werkzeugs, das die SBOM erzeugt hat |
| Eigenschaften für Executables, Archive und strukturierte Daten | Erzeugungskontext: vor, während oder nach dem Build |
| URL der security.txt des Komponentenerstellers (optional) | Hash-Algorithmus |
Das BSI verlangt außerdem eine E-Mail-Adresse für den SBOM-Ersteller und jeden Komponentenersteller, oder eine URL, wenn es keine E-Mail-Adresse gibt. Die CISA fragt nach einem Namen.
Wenn Sie an Kunden in Deutschland und den USA liefern, erzeugen Sie die Vereinigungsmenge beider Listen. Werkzeugname und -version, Format und Zeitstempel liefert jeder ordentliche Generator. Die BSI-spezifischen Eigenschaften, die effektive Lizenz und die Signatur brauchen zusätzliche Schritte in Ihrer Pipeline.
Formate und Typen
73% der Organisationen in der Umfrage nutzen CycloneDX oder SPDX, und die Empfehlung vergleicht die aktuellen Versionen beider.
| SPDX 3.0.1 | CycloneDX 1.7 | |
|---|---|---|
| Normung | SPDX 2.2.1 ist ISO/IEC 5962:2021, SPDX 3.0 ist ein OMG-Standard, und SPDX 3 ist bei der ISO in Arbeit | Als ECMA-424 ratifiziert, über Ecma TC54 gepflegt und im Fast-Track-Verfahren von ISO/IEC JTC 1 |
| Schwerpunkt | Detaillierte Komponentenmetadaten für Lizenzierung, Herkunft und Risikoanalyse über Produktlinien hinweg | Sicherheitsanwendungen: Schwachstellenverfolgung mit nativem VEX, Dienste und APIs, kryptografische Integrität |
Für den CRA funktionieren beide. Wählen Sie das Format, das Ihre Kunden und Ihre Werkzeuge lesen. OWASP Dependency-Track zum Beispiel übernimmt nur CycloneDX. Wenn Sie beides brauchen, konvertiert Protobom von der OpenSSF zwischen ihnen.
Das Format ist die halbe Geschichte. Wann Sie die SBOM erzeugen, entscheidet, was drinsteht. ENISA verwendet die sechs SBOM-Typen der CISA:
| Typ | Erzeugt aus | Typische Nutzung |
|---|---|---|
| Design | Dem geplanten Design, einschließlich Komponenten, die es vielleicht noch nicht gibt | Architekturentscheidungen, Lizenzkäufe, Threat Modeling |
| Source | Der Entwicklungsumgebung, den Quelldateien und deklarierten Abhängigkeiten | Sicht auf Abhängigkeiten, frühe Schwachstellenerkennung |
| Build | Dem Build-Prozess: Quelldateien, aufgelöste Abhängigkeiten, gebaute Komponenten und Build-Daten | Einhaltung von Vorschriften, Schwachstellenbewertung, Transparenz |
| Analyzed | Der Analyse fertiger Artefakte wie Executables, Pakete, Container und VM-Images, meist mit Heuristiken; manchmal Third-Party-SBOM genannt | Lizenz-Compliance, Herkunftsprüfung, Lieferkettenrisiko |
| Deployed | Der auf einem System vorhandenen Software, durch Kombination von SBOMs mit einer Analyse der Konfiguration | Asset-Inventar, Patch-Management, Konfigurationsmanagement |
| Runtime | Der Instrumentierung des laufenden Systems, einschließlich dynamisch geladener Bibliotheken, Plug-ins und injizierter Agenten | Bedrohungserkennung, Bewertung der Angriffsfläche, Laufzeitüberwachung |
Das neue Feld der CISA für den Erzeugungskontext soll Abnehmern zeigen, welchen Typ sie vor sich haben. Für eine minimal funktionsfähige Umsetzung ist ENISA eindeutig: Beginnen Sie mit der Build-SBOM, denn dann sind die Abhängigkeiten am genauesten bekannt.
Der SBOM-Lebenszyklus
Die Empfehlung beschreibt die SBOM als Lebenszyklus in sieben Phasen, aufgebaut auf vier Prinzipien: kontinuierlich, vertrauenswürdig, verwertbar und aktuell.
- Build
- Erzeugung
- Validierung
- Signatur
- Speicherung
- Nutzung
- Pflege und Aktualisierung
Daraus macht sie eine Referenzarchitektur für eine CI/CD-Pipeline. Jede Phase ist ein Gate. Schlägt es fehl, stoppt die Pipeline und löst eine Warnung aus.
- Die Erzeugung erkennt Komponenten und ihre direkten und transitiven Abhängigkeiten, erfasst Metadaten wie Versionen, Lizenzen und PURLs, baut den Abhängigkeitsgraphen, normalisiert Paketnamen und Versionsformate und schreibt SPDX oder CycloneDX.
- Die Validierung prüft das Schema, die Metadaten, die Konsistenz von Bezeichnern und Abhängigkeitsverweisen, optional ein Profil wie die Pflichtfelder des BSI, und ob die SBOM zum Artefakt passt. ENISA hebt die Komponentenbezeichner ausdrücklich als etwas hervor, das Sie validieren müssen.
- Die Signatur kanonisiert die SBOM, berechnet einen SHA-256-Digest, signiert ihn, bindet die Signatur über ein X.509-Zertifikat oder Sigstore an eine Identität und ergänzt einen Zeitstempel.
- Die Speicherung legt die signierte SBOM in einem unveränderlichen, versionierten, zugriffsgeschützten Repository mit Manipulationsnachweis, Backups und Aufbewahrungsrichtlinie ab.
- Die Nutzung speist Schwachstellenmanagement, Lizenz-Compliance, Lieferantenrisikomanagement, Open-Source-Governance, regulatorische Compliance und Software-Asset-Management.
- Die Pflege erzeugt die SBOM bei jeder Änderung neu: ein neuer Build oder ein neues Release, Abhängigkeitsupdates, Sicherheitspatches, Updates von Betriebssystempaketen, hinzugefügte oder entfernte Bibliotheken oder eine geänderte Build-Konfiguration.
Unter den Abnehmern im Lebenszyklusdiagramm stehen neben Security-, Entwicklungs- und Compliance-Teams, Lieferanten und Kunden auch die Marktüberwachungsbehörden. Nach dem CRA kann eine Behörde Ihre SBOM anfordern, und dann wollen Sie diejenige übergeben, die genau zur angefragten Produktversion gehört.
Werkzeuge für jede Phase
Die Empfehlung ordnet Open-Source-Werkzeuge den Phasen des Lebenszyklus zu. Jede dritte Organisation in der Umfrage setzt auf Open-Source-Werkzeuge, und ENISA versteht die Liste als beispielhaft, nicht als abschließend.
| Phase | CycloneDX | SPDX |
|---|---|---|
| Erzeugung | cyclonedx-maven-plugin, @cyclonedx/cyclonedx-npm, cyclonedx-gomod, CycloneDX .NET tool, cdxgen, Syft, SBOMit | spdx-gradle-plugin, spdx-maven-plugin, SPDX-Werkzeuge für Python, Java und Go, Yocto, Linux (make spdx), Zephyr (west spdx), kubernetes-sigs/bom, GitHub SBOM, Microsoft sbom-tool, Syft, Trivy, ORT, SBOMit |
| Schemavalidierung | CycloneDX CLI | SPDX Online-Validator und NTIA-Checker |
| Qualitätsbewertung | sbomqs, sbom-scorecard | |
| Signatur | GitHub CLI Attestations, Cosign mit schlüssellosem Signieren über Sigstore | |
| Speicherung | Workflow-Artefakte von GitHub Actions (actions/upload-artifact) | |
| Nutzung | Grype, Trivy, OWASP Dependency-Check, OWASP Dependency-Track, GitHub Dependency Review, OWASP dep-scan, OSV-Scanner, CVE Binary Tool | Fossology, sbomify, sbom-cve-check, SPDX 3 visualizer, GitHub Dependency Review |
Zwei Einträge brauchen einen Hinweis. OWASP Dependency-Check scannt Projektdateien und Abhängigkeiten direkt und ist nicht dafür gebaut, SBOMs zu übernehmen. Das OWASP-Werkzeug, das SBOMs liest und überwacht, ist Dependency-Track, und unser Leitfaden zur Bereitstellung von Dependency-Track zeigt, wie Sie es auf Ihrer eigenen Infrastruktur betreiben.
Workflow-Artefakte verfallen außerdem nach ihrer Aufbewahrungsfrist, was nicht zum eigenen Rat der Empfehlung zu unveränderlicher Speicherung und Aufbewahrung passt. Der CRA erwartet, dass Sie die technische Dokumentation mindestens zehn Jahre nach dem Inverkehrbringen des Produkts aufbewahren, oder für den Unterstützungszeitraum, wenn dieser länger ist. Speichern Sie SBOMs in einem Artefakt-Repository, das Sie selbst kontrollieren.
Ein Threat Model für die SBOM-Pipeline
Die Empfehlung enthält ein Threat Model nach STRIDE. Es deckt das gesamte SBOM-Ökosystem ab, nicht nur die Datei: die Generatoren, die Dienste für Validierung und Signatur, die Repositories und die Pipelines, die SBOMs nutzen.
| STRIDE | Beispielhafte Bedrohungen | Mögliche Gegenmaßnahmen |
|---|---|---|
| Spoofing | Ein vorgetäuschter SBOM-Autor, ein falscher Abnehmer, der eine geschützte SBOM anfordert, eine gefälschte CI/CD-Pipeline oder ein gefälschtes Erzeugungswerkzeug, gestohlene Signaturzertifikate, ein kompromittierter Repository-Mirror | Digitale Signaturen, Prüfung der Identität von Lieferant und Abnehmer, Build-Attestierungen, authentifizierte Pipelines, Schlüsselmanagement, Zertifikatswiderruf |
| Tampering | Komponenten, Versionen oder Abhängigkeiten nach der Erzeugung geändert; Metadaten vor der Erzeugung geändert; veränderte Hashes, Herkunftsangaben, PURLs oder CPEs | Prüfung von Integrität und Signaturen, signierte Attestierungen, Prüfung externer Verweise |
| Repudiation | Ein Hersteller bestreitet, eine SBOM erzeugt, veröffentlicht oder verteilt zu haben | Signaturen, Zeitstempel, Audit- und Repository-Logs, signierte Releases |
| Information Disclosure | Die SBOM verrät den Technologie-Stack, proprietäre Komponenten, Lieferantenbeziehungen, den Abhängigkeitsgraphen, exakte Versionen oder interne Zertifikate und Release-Prozesse | Kontrollierte Weitergabe, Zugriffskontrolle, Audit-Logging |
| Denial of Service | Ein nicht erreichbares Repository, sehr große oder tief verschachtelte SBOMs, die Parser erschöpfen, ein SBOM-Volumen, das Speicher füllt und Pipelines blockiert | Redundanz und DDoS-Schutz, Größenlimits, gehärtete Parser, eine Aufbewahrungsrichtlinie |
| Elevation of Privilege | Rechteausweitung in der Build-Pipeline, im SBOM-Repository oder in der Signaturinfrastruktur | Zugriffskontrolle, Härtung der Pipeline, Schlüsselmanagement |
Zwei Zeilen verdienen mehr Aufmerksamkeit, als sie meist bekommen. Information Disclosure ist der Grund, warum der CRA Ihnen erlaubt, die SBOM in Ihrer technischen Dokumentation zu behalten, statt sie zu veröffentlichen: Eine Liste exakter Versionen ist eine Liste von CVEs zum Ausprobieren. Entscheiden Sie pro Kunde, was Sie teilen und zu welchen Bedingungen. Und Denial of Service gegen Parser wird relevant, sobald Sie SBOMs von Lieferanten annehmen. Behandeln Sie diese als nicht vertrauenswürdige Eingaben.
Nutzen Sie die Tabelle als Ausgangspunkt, nicht als Ihr Threat Model. Ihre Pipeline hat eigene Vertrauensgrenzen, und die Fragen, die sie aufdecken, sind dieselben wie bei jedem anderen System. Das Secure by Design and Default Playbook bietet einen leichtgewichtigen Weg dafür, wenn Ihr Team sein Build-System noch nie modelliert hat.
Zehn Risiken, die SBOMs weniger nützlich machen
Neben den Bedrohungen nennt die Empfehlung allgemeine Risiken, die Genauigkeit, Integrität oder Nutzung von SBOMs untergraben.
| Risiko | Wie es aussieht | Mögliche Gegenmaßnahme |
|---|---|---|
| Nicht standardisiertes Format | Ein proprietäres oder eigenes Format | SPDX oder CycloneDX nutzen |
| Nicht maschinenlesbar | Ein PDF oder eine Tabelle für Menschen | Ein maschinenlesbares Format, das sich für automatisierte Verarbeitung eignet |
| Unvollständige SBOM | Komponenten oder Abhängigkeiten fehlen | Automatische Erzeugung beim Release, Integration in CI/CD, dokumentierte Known Unknowns und fehlende Metadaten |
| Veraltete SBOM | Die SBOM passt nicht mehr zur Software | Neu erzeugen bei den Pflege-Auslösern |
| Schlechte Komponentenidentifikation | Komponenten lassen sich über Ökosysteme hinweg nicht zuordnen | Die URL des Upstream-Repositorys, oder eine PURL mit Namespace, exakter Version und Hashes, oder eine konsistent angewandte CPE mit exakter Version und Hashes |
| Unzureichende Genauigkeit | Heuristiken fügen Komponenten hinzu, die nicht da sind, übersehen vorhandene oder melden falsche Versionen | Erzeugungstechnik pro Ökosystem und Artefakttyp wählen, SBOMs gegen Artefakte validieren, Vollständigkeit und Bezeichner prüfen |
| Schwache Bindung zwischen SBOM und Artefakt | Es ist unklar, welchen Build, welches Image oder welches Paket die SBOM beschreibt | Die SBOM per Hash oder unveränderlichem Digest an das Artefakt binden und die Zuordnung prüfen |
| Begrenzte Operationalisierung | SBOMs werden erzeugt, aber nie genutzt | Sie für Asset-, Schwachstellen- und Lizenzmanagement nutzen |
| Unzureichende Aufbewahrung | Alte SBOMs, Signaturen und VEX-Dokumente sind weg | Eine Aufbewahrungsrichtlinie, SBOMs pro Release, Versionshistorie, Rückverfolgbarkeit von SBOM zu Artefakt, Löschverfahren |
| Keine Priorisierung von Schwachstellen | Jeder Befund wird als gleich dringend behandelt | SBOM-Daten mit VEX, Kritikalität der Assets und Exposition in einem risikobasierten Prozess kombinieren |
Schlechte Komponentenidentifikation begegnet mir am häufigsten. Bei C und C++ ist sie der Normalzustand: Generatoren fügen bestenfalls eine PURL hinzu, während die NVD Schwachstellen in Bibliotheken wie OpenSSL und zlib unter CPEs erfasst. ENISAs Gegenmaßnahme, eine konsistent angewandte CPE mit exakter Version, ist der Ansatz aus unserem Artikel zur CPE-Anreicherung für C++-Bibliotheken in Conan-Builds.
Die Aufbewahrung ist das Risiko, das Teams zu spät entdecken. Wenn eine CVE für eine Bibliothek erscheint, lautet die Frage nicht nur, ob der heutige Build betroffen ist, sondern welche ausgelieferten Versionen. Beantworten können Sie das nur mit den SBOMs dieser Versionen. Für die Priorisierung zeigt die Mitigationsphase in unserem Artikel zu Paketmanagern, wie EPSS, der KEV-Katalog, VEX und Erreichbarkeit zusammenspielen.
Wo Sie anfangen: Integration im Build
ENISAs Rat für eine minimal funktionsfähige Umsetzung lautet, beim Build anzufangen und die vorhandene CI-Infrastruktur zu nutzen. Sie gliedert das in sechs Schritte:
- Integrationspunkte in der aktuellen Pipeline bestimmen, etwa nach dem Kompilieren, vor dem Paketieren und bei der Release-Vorbereitung.
- Die Erzeugung konfigurieren: Format, Detailgrad, Komponentenumfang, Tiefe der Abhängigkeitsauflösung und Umgebungsvariablen für konsistente Läufe.
- Eine eigene Pipeline-Stufe ergänzen, die nach den Build-Aufgaben läuft, von denen sie abhängt, mit einer Fehlerbehandlung, die verhindert, dass eine unvollständige SBOM-Erzeugung kritische Pfade blockiert.
- Auslöser festlegen, zum Beispiel Merges nach main, getaggte Releases und geplante Baseline-Läufe, und reine Dokumentationsänderungen überspringen.
- SBOMs nah bei den Build-Artefakten speichern, mit einer Versionierung passend zu Ihren Softwareversionen und einer Aufbewahrung passend zum Lebenszyklus der Artefakte.
- Das Format validieren, prüfen, ob Pflichtfelder gefüllt sind, und Signaturen prüfen, wo Sie Attestierungen nutzen.
Schritt 3 passt nicht ganz zur Referenzarchitektur, in der jede fehlgeschlagene Phase die Pipeline stoppt. Beides ist sinnvoll, also legen Sie vorab fest, welche SBOM-Fehler ein Release blockieren und welche nur eine Warnung auslösen. Eine fehlende SBOM für einen Release-Kandidaten sollte blockieren. Eine schwankende Qualitätsbewertung wohl eher nicht.
Die Empfehlung beschreibt zwei Integrationsmuster. Die Integration im Build erzeugt die SBOM direkt nach einer erfolgreichen Kompilierung, solange der Build-Kontext noch verfügbar ist. Build-Systeme wie Yocto, Kubernetes, Linux und Zephyr haben die SBOM-Erzeugung bereits eingebaut, Sie müssen sie nur aktivieren. Die ereignisgesteuerte Erzeugung nutzt Repository-Webhooks bei Commits, Pull Requests und Releases, mit einer Warteschlange für gleichzeitige Anfragen und einer Erzeugungshistorie für Audits.
Die allgemeinen Konfigurationshinweise sind praxisnah: ein eigenes Verzeichnis für SBOMs, Quell-SBOMs getrennt von erzeugten, Namenskonventionen, die jede SBOM mit ihrer Komponente verknüpfen, Ignore-Muster, damit SBOMs nicht in Builds landen, wiederverwendbare Pipeline-Vorlagen und Validierungspunkte vor jeder Veröffentlichung. Über die SBOM gefundene Schwachstellen sollten mit Behebungsfristen, Schweregradschwellen und Eskalationswegen verknüpft sein, wobei sich die Fristen nach Schweregrad, Ausnutzbarkeit, Exposition, Kritikalität des Produkts, Verfügbarkeit von Patches und kompensierenden Maßnahmen richten.
Zwei letzte Empfehlungen stechen hervor. SBOM-Prozesse sollten Nachweise für interne Audits, Konformitätsbewertungen, Vorfallsbehandlung und Anfragen von Aufsichtsbehörden liefern: Erzeugungslogs, Validierungsergebnisse, Signaturen, Zeitstempel, Verknüpfungen mit Releases und Aufbewahrungsnachweise. Und Organisationen sollten die bekannten Lücken, Ausnahmen und Known Unknowns in ihrer SBOM-Abdeckung dokumentieren, vor allem dort, wo Abhängigkeiten nicht identifiziert werden können, Lieferanteninformationen fehlen oder reine Binärkomponenten nicht vollständig analysiert werden können.
Sicherheitsmaßnahmen für die Pipeline
Die Empfehlung schließt mit Sicherheitsmaßnahmen für die gesamte SBOM-Pipeline. Für alle Phasen nennt sie rollenbasierte Zugriffskontrolle, MFA, Least Privilege, TLS 1.3 mit Zertifikatsprüfung, Audit-Logging, Warnungen bei fehlgeschlagenen Validierungen und Signaturen, Code-Review und Branch Protection für Pipeline-Definitionen, versionierte Konfiguration sowie die Prüfung der Integrität von Generatoren und anderen Werkzeugen vor ihrer Ausführung. Die Erzeugung ergänzt vertrauenswürdige Registries und nachprüfbare Build-Herkunft. Signatur und Speicherung ergänzen Geheimnisse in einem Vault, kryptografische Bindung zwischen SBOM und Artefakt, manipulationssichere Speicherung, Integritätsüberwachung, Versionshistorie sowie Backup und Wiederherstellung für Repositories, Signaturmaterial und Audit-Logs.
Nichts davon ist SBOM-spezifisch. Es ist die Härtung, die Ihr Build-System ohnehin braucht. Eine SBOM ist nur so vertrauenswürdig wie die Pipeline, die sie erzeugt hat.
Was das für den CRA bedeutet
Anhang I Teil II des Cyber Resilience Act verpflichtet Hersteller, Schwachstellen und Komponenten in Produkten mit digitalen Elementen zu ermitteln und zu dokumentieren, unter anderem durch eine Software-Stückliste in einem gängigen, maschinenlesbaren Format, die mindestens die obersten Abhängigkeiten der Produkte erfasst. Artikel 13 Absatz 5 ergänzt die Sorgfaltspflicht für Komponenten Dritter, Open Source eingeschlossen. Die SBOM ist Teil der technischen Dokumentation, die eine Marktüberwachungsbehörde anfordern kann (Anhang VII Nummer 8). Artikel 13 Absatz 24 erlaubt der Kommission, Format und Elemente der SBOM in einem Durchführungsrechtsakt festzulegen. Die Pflicht gilt ab dem 11. Dezember 2027, zusammen mit dem Rest von Anhang I.
Die Empfehlung legt diese Pflichten nicht aus, füllt aber vieles vom Wie. Zwei Dinge sollte man mitnehmen. Das gesetzliche Minimum sind die obersten Abhängigkeiten, während die Umfrage zeigt, dass Abnehmer Tiefe verlangen; Ihre Kunden legen die Latte also höher als die Verordnung. Und fast jede Empfehlung erzeugt Nachweise: Logs, Validierungsergebnisse, Signaturen, Aufbewahrungsnachweise. Genau dieses Material wird eine Konformitätsbewertungsstelle oder Behörde verlangen.
Auf der Normenseite deckt EN 40000-1-3 die Anforderungen an die Schwachstellenbehandlung aus Anhang I Teil II ab, wo die SBOM-Pflicht steht. Unsere Übersicht der harmonisierten Normen verfolgt ihren Stand, und unser CRA-Leitfaden für KMU behandelt die übrigen Pflichten.
Unsere Einschätzung
Das ist das praktischste SBOM-Dokument, das eine EU-Stelle bisher veröffentlicht hat. Die Gegenüberstellung von BSI und CISA erspart allen, die beide Märkte bedienen, einen Tag mit einer Tabellenkalkulation, die CI/CD-Referenzarchitektur gibt Teams ein Zielbild, und das STRIDE-Modell behandelt die SBOM-Pipeline als Angriffsfläche, was die meisten Organisationen noch immer nicht tun.
Es gibt Lücken. Das Dokument ist aus Herstellersicht geschrieben: Die Qualitätsprüfung von SBOMs, die Sie von Lieferanten erhalten, und was zu tun ist, wenn sie nicht genügen, bekommt wenig Raum, und genau dort werden viele KMU ihre Zeit verbringen, sobald Lieferanten CRA-SBOMs liefern. VEX taucht in der Risikotabelle auf, aber nicht im Lebenszyklus oder in der Pipeline. Und die Werkzeugtabelle sollten Sie prüfen, bevor Sie sie übernehmen.
Wenn Sie bei null anfangen, folgen Sie der Reihenfolge der Empfehlung. Erzeugen Sie beim Build in der CI eine SBOM in CycloneDX oder SPDX, validieren Sie das Schema und die Komponentenbezeichner, signieren Sie sie, speichern Sie sie an einem Ort, den Sie kontrollieren, und überwachen Sie sie kontinuierlich mit einem Werkzeug wie Dependency-Track. Bringen Sie das für ein Produkt zum Laufen, bevor Sie über Laufzeit-SBOMs nachdenken.
Quellen: ENISA, Technical Advisory for Software Bill of Materials, Oktober 2026; ENISA, SBOM Adoption State of Play 2026; BSI TR-03183-2, Version 2.1.0; CISA, 2026 Minimum Elements for a Software Bill of Materials; Verordnung (EU) 2024/2847, der Cyber Resilience Act.