Der EU Cyber Resilience Act (Verordnung (EU) 2024/2847) trat im Dezember 2024 in Kraft, und in den meisten Roadmaps wurde er als „Problem für 2027" abgelegt: Alle Anforderungen — secure-by-design, Konformitätsbewertung, CE-Kennzeichnung, eine verpflichtende SBOM und Sicherheitsupdates über den gesamten Support-Zeitraum — gelten ab dem 11. Dezember 2027. Doch es gibt ein früheres Datum, das leicht übersehen wird, und genau dieses macht aus einer SBOM von einem Roadmap-Punkt eine operative Notwendigkeit.
Der echte Stichtag ist der 11. September 2026
Die Meldepflichten gelten ab dem 11. September 2026. Ein Hersteller eines Produkts mit digitalen Elementen muss aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle melden: eine Frühwarnung an die ENISA innerhalb von 24 Stunden, eine vollständige Meldung innerhalb von 72 Stunden und einen Abschlussbericht spätestens 14 Tage, nachdem eine Korrektur verfügbar ist. Formal ist die SBOM zu diesem Zeitpunkt noch nicht verpflichtend. Doch sehen Sie sich die Mechanik an: Eine Meldung über eine ausgenutzte CVE in einer verbreiteten Bibliothek trifft ein, und Sie haben einen Tag, um festzustellen, ob auch nur eines Ihrer Produkte betroffen ist. Ohne ein maschinenlesbares Inventar der Komponenten ist das keine 24-Stunden-Aufgabe, sondern Panik mit grep über die Repositories. Eine Meldung ohne SBOM ist physisch unmöglich — deshalb liegt der echte Stichtag für ein Inventar nicht im Dezember 2027, sondern im September 2026.
Was der CRA wirklich von einer SBOM verlangt
Um die Anforderung herum sind zwei Mythen gewachsen, und beide sind teuer. Der erste: „Man muss die SBOM veröffentlichen." Nein: Der CRA (Anhang I, Teil II) legt die SBOM in die technische Dokumentation, und offengelegt wird sie nur den Marktüberwachungsbehörden auf begründete Anfrage. Sie ist ein Compliance-Artefakt für die Behörde, kein Marketing-Dokument auf der Website. Der zweite Mythos: „Man muss alles bis zur letzten transitiven Abhängigkeit auflisten." Das Gesetz verlangt das Minimum — die Top-Level-Abhängigkeiten in einem gängigen maschinenlesbaren Format. Die Auflistung verschachtelter Unterkomponenten ist gute Ingenieurspraxis und die Grundlage für echtes Vulnerability-Tracking, aber die Tiefe ist Ihre Entscheidung, nicht der Wortlaut der Verordnung.
Die praktische Konsequenz: das Format ist SPDX (ISO 5962) oder CycloneDX (OWASP), beide maschinenlesbar und in der Branche etabliert. CycloneDX neigt zu Security-Szenarien (es trägt ein Schwachstellenmodell und VEX), SPDX zu Lizenz und Recht. Die Generierung selbst ist der gelöste Teil: syft oder trivy erzeugen eine SBOM aus einem Image mit einem einzigen Befehl.
Eine SBOM zu erzeugen ist 20% der Arbeit
Die Versuchung, die Aufgabe mit einer CI-Zeile abzuschließen, täuscht. syft image:tag -o spdx-json sind die leichten 20%. Die übrigen 80% sind operativ:
- Speicherung und Bindung. Eine SBOM, die ein Artefakt des CI-Jobs bleibt, ist aus dem Deployment heraus nicht auffindbar. Binden Sie sie als signierte Attestation an das Image (
cosign attest --type spdxjson) oder führen Sie sie zentral in Dependency-Track / GUAC. - Kontinuierliches Scannen. Eine SBOM hält die Zusammensetzung zum Build-Zeitpunkt fest; Schwachstellen werden später bekannt. Scannen Sie gespeicherte SBOMs (Grype, Trivy) nach Zeitplan neu, nicht nur beim Build — so finden Sie das betroffene Produkt innerhalb von 24 Stunden.
- VEX gegen das Rauschen. Ohne ein Vulnerability Exploitability eXchange ertrinkt das Security-Backlog in False Positives, und die eine real ausgenutzte CVE geht zwischen Hunderten nicht zutreffender unter. Der Vermerk „nicht betroffen, weil der Code nicht im Ausführungspfad liegt" macht den 24-Stunden-Bericht erst machbar.
Eine SBOM ist „was drin ist", doch der CRA schaut auch auf „wie es gebaut wurde"
Eine SBOM beantwortet die Frage „woraus ist das Artefakt gebaut." Die Anforderungen secure-by-design und Manipulationssicherheit drängen zur zweiten Frage — „wie wurde es gebaut." Hier wirkt Provenance im Sinne von SLSA: eine überprüfbare Kette vom Commit bis zum Image (wer, auf welchem Commit, in welchem Builder, womit signiert). SBOM und Provenance ergänzen einander — zusammen liefern sie die Supply-Chain-Transparenz, für die der CRA gedacht war. Die gute Nachricht: OpenSSF und die Regulierer bewegen sich auf eine Vereinheitlichung der SBOM-Standards zu, sodass die Investition in den CNCF-Stack (Syft/Grype, Cosign, Sigstore) keine Arbeit für die Schublade ist, sondern eine Wette in die gemeinsame Richtung.
Was bis September 2026 zu tun ist
Reduzieren Sie die Aufgabe auf vier heute überprüfbare Punkte. Erstens: SBOM-Generierung bei jedem Build als verpflichtende Pipeline-Stufe, im Format CycloneDX oder SPDX. Zweitens: Speicherung und Attestation, damit die SBOM aus dem Deployment auffindbar ist und nicht in der CI stirbt. Drittens: kontinuierliches Neuscannen gespeicherter SBOMs plus VEX, um das Ausnutzbare vom Rauschen zu trennen. Viertens: der organisatorische Prozess — wer das Signal über eine aktiv ausgenutzte CVE erhält, wer innerhalb von 24 Stunden die Betroffenheit prüft und wer bei der ENISA den Melde-Knopf drückt. Die ersten drei sind Werkzeuge, die sich in einem Sprint aufstellen lassen. Das vierte ist ein Runbook, und es hinkt meist hinterher. Bis September 2026 bleibt weniger Zeit, als es scheint: „Wir haben eine SBOM" und „mit der SBOM antworten wir der Behörde binnen eines Tages" sind unterschiedliche Reifegrade.