Eine SBOM im CRA ist Nachweis, keine einmal erzeugte Datei

Im Cyber Resilience Act ist die Software Bill of Materials kein Audit-Souvenir. Anhang I Teil II verlangt vom Hersteller, Schwachstellen zu identifizieren und zu dokumentieren, einschließlich einer SBOM. Artikel 13 bindet diese Dokumentation an eine Risikobewertung über den Lebenszyklus. Bis 11. Dezember 2027 liegt die SBOM in der technischen Akte, die die Marktüberwachung verlangen kann.

Ein CycloneDX- oder SPDX-Export aus der Pipeline des Vorjahres tut das nicht, wenn das Produkt auf dem Unionsmarkt zwei Minor-Versionen weitergezogen ist.

Was der CRA von der SBOM wirklich will

Die Verordnung wählt nicht Ihr Format. Sie wählt Ihre Pflicht. Sie bringen ein Produkt mit digitalen Elementen in Verkehr. Sie schulden Sorgfalt gegenüber Drittkomponenten. Sie müssen sagen können, was in der ausgelieferten Version steckt, und Schwachstellen über den beim Kauf angegebenen Supportzeitraum (Monat und Jahr) behandeln.

Das macht die SBOM zu einem Produktdatensatz, nicht zu einem Repository-Datensatz. Die Einheit ist die PDE-Version: die Firmware in der Schachtel, der Installer im Store, die Bibliothek, die Sie als Komponente verkaufen. Ein Monorepo-Dump, der drei SKUs mischt, ist kein Nachweis. Eine Cloud-Box, die der Betrieb an einem Freitagabend nicht öffnet, auch nicht.

Die SBOM muss außerdem taugen, wenn am 11. September 2026 Artikel 14 startet. Eine aktiv ausgenutzte Schwachstelle in einer transitiven Abhängigkeit ist nur dann ein 24-Stunden-Problem, wenn Sie die Produkte nennen können, die sie enthalten.

Zur ausgelieferten Version passen, sonst ist die Akte schon falsch

Der übliche Fehler ist Drift. Der Store zeigt 3.4.1. Die SBOM auf dem Share entstand im März aus main. Zwei Sprints haben eine TLS-Bibliothek ergänzt und ein Vendor-SDK entfernt. Der Scan läuft weiter. Der Nachweis nicht.

Sperren Sie die SBOM an den Build, der das Lager verlassen hat:

• dieselbe Versionszeichenkette wie im Katalog,
• derselbe Commit / Image-Digest, den Sie signiert haben,
• eigene und fremde Bestandteile, mit Lieferant und Version,
• ein Datum, damit sichtbar ist, wann die Datei nicht mehr zum Produkt passt.

Die Sorgfalt bleibt an der Komponente. Liefert ein Zulieferer einen Fix, muss die Zeile zeigen, dass Sie ihn gesehen, gegen dieses PDE bewertet und entweder das Update genommen oder ein dokumentiertes Risiko gegen Anhang I angenommen haben. Ein grünes Badge in einem SaaS-Scanner ist diese Zeile nicht.

Die SBOM speist die Warteschlange, die Warteschlange ist nicht die SBOM

CRA ist kein Schwachstellenscanner. Die SBOM sagt der Warteschlange, welche Bestandteile existieren. Der Scanner sagt, welche davon bekannte Schwächen haben. Artikel 14 stellt die dritte Frage: wird das aktiv ausgenutzt, oder ist das ein schwerwiegender Vorfall, und können Sie CSIRT und ENISA in 24 Stunden warnen.

Leben diese drei Objekte in drei Werkzeugen unter drei Produktnamen, ist die 24-Stunden-Uhr schon verloren. Die minimale Verbindung ist langweilig und nicht verhandelbar:

1. PDE-Identität im Katalog.
2. SBOM-Zeilen an diese Identität gebunden.
3. Findings an diese Zeilen gebunden.
4. Benannter Eigentümer und 24h-/72h-Status.

Ohne die Verbindung bekommen Sie entweder Stille (niemand weiß, dass das Produkt betroffen ist) oder Rauschen (jedes CVE der Branche landet auf einer Mailingliste).

Was in die technische Akte gehört

Bis 11. Dezember 2027 ist die Akte nicht „latest SBOM.pdf anhängen“. Es ist Produktidentität, Risikobewertung, Nachweise zu Anhang I, die SBOM der in Verkehr gebrachten Version, Supportzeitraum, Anleitungen, EU-Erklärung und CE-Kennzeichnung.

Das hat Folgen für die Ablage:

• die Behörde fragt nach diesem Produkt, nicht nach dem Softwarebestand der Firma,
• die SBOM kann Jahre nach dem Release-Zug gebraucht werden,
• Export darf nicht heißen, den Katalog in eine Vendor-Cloud zu kopieren.

Crado AI hält die SBOM deshalb on-premise, neben Katalog und Artikel-14-Warteschlange. Die Stückliste ist Teil der Akte, die Sie zeigen, bevor das Produkt das Lager verlässt.

Eine SBOM-Praxis, die vor September 2026 trägt

1. Erzeugen Sie die SBOM aus der Pipeline für jede Version, die Sie noch unterstützen, nicht nur für das nächste Release.
2. Liefern Sie nicht, wenn Katalogversion und SBOM-Version auseinanderlaufen.
3. Halten Sie Lieferant und Version auf jeder Drittzeile, damit Sorgfalt einen Griff hat.
4. Hängen Sie Findings an diese Zeilen. Schließen oder akzeptieren Sie sie gegen Anhang I, nicht gegen eine Ticketzahl.
5. Üben Sie einen Artikel-14-Drill: Komponente wählen, PDEs listen, Eigentümer nennen, Frühwarnung stoppen.

Wenn Schritt 5 an einem Werktagnachmittag nicht geht, ist die SBOM noch eine Datei. Noch kein Nachweis.