CRA-SBOM-Anforderungen
Format, Umfang und Regeln je Version für eine Software Bill of Materials des Produkts, die den EU Cyber Resilience Act erfüllt.
Der CRA verlangt von Herstellern, eine Software Bill of Materials (SBOM) für das Produkt zu erstellen und zu pflegen, das Sie in Verkehr bringen, als Teil der technischen Dokumentation. Die Regeln sind klar zu Format, Umfang und dazu, wie das SBOM aktuell bleiben muss.
Die sechs SBOM-Regeln unter dem CRA
Maschinenlesbar, Standardformat
Das SBOM muss ein gängiges, maschinenlesbares Format nutzen: SPDX, CycloneDX oder SWID, typischerweise als JSON oder XML serialisiert.
Mindestens Abhängigkeiten der obersten Ebene
Als Minimum jede Komponente der obersten Ebene mit Name, Version und Lieferant auflisten; idealerweise Abhängigkeitsbeziehungen einbeziehen.
Ein SBOM je Softwareversion
Für jede Softwareversion muss ein eigenes SBOM erzeugt werden. Ändert sich eine Komponente, sind eine neue Version und ein neues SBOM erforderlich.
Aktuell gehalten, nicht veraltet
Erhält das Produkt Updates und Patches, muss das SBOM den aktuellen Stand der Software nachverfolgen.
In der technischen Dokumentation
Sie müssen das SBOM nicht veröffentlichen, aber in der technischen Dokumentation halten und Marktüberwachungsbehörden auf Anfrage bereitstellen.
Keine Schwachstellendaten darin
SBOMs dürfen keine Schwachstelleninformationen enthalten. Schwachstellen getrennt über VEX oder CSAF kommunizieren.
Zuerst das Produkt-SBOM: Hersteller und aus Firmware abgeleitet
Beginnen Sie mit dem Hersteller-CycloneDX/SPDX-Dokument je Release. Liegt die Binary vor, erzeugen Sie bei Bedarf ein abgeleitetes Inventar und vergleichen Sie, prüfen, nicht nur übernehmen. Kontinuierliches erneutes Scannen hält Funde über den Unterstützungszeitraum aktuell.
Toolchain- und Build-Umgebungs-SBOMs sind nützliche Tiefe für technische Dokumentation und Neubauten bei langer Supportlaufzeit. Sie sind nicht der Leitfaden für September 2026. Den Spoke zur Build-Umgebung lesen →
CRA-Konformitätshub
CRA-Überblick für Embedded und Firmware
Was der Cyber Resilience Act verlangt, die Fristen und wie Hersteller von Produkten mit digitalen Elementen konform werden.
CRA für Embedded und Firmware
Warum Firmware Hersteller-SBOM plus aus Binary abgeleitetes Inventar braucht, und wie HEX-/verschlüsselte Images abweichen.
CRA-Konformitäts-Checkliste
Eine praktische Checkliste, die jede CRA-Pflicht darauf abbildet, was Ihr Team tun muss.
Schwachstellenbehandlung und Artikel 14
24h-/72h-/14-Tage-Meldung, KEV/EUVD, Kenntnisuhr und was Sep. 2026 tatsächlich verlangt.
Build-Umgebungs-SBOM
Toolchain und Build-Zeit-Abhängigkeiten für technische Dokumentation: nützliche Tiefe, aber nicht das, was die Meldung im Sep. 2026 verlangt.
Diese Seite bietet allgemeine Informationen zum EU Cyber Resilience Act und ist keine Rechtsberatung. Die Verordnung und ihre harmonisierten Normen entwickeln sich weiter: konsultieren Sie die offiziellen Quellen von EU, ENISA und BSI sowie qualifizierten Rechtsbeistand für Ihr konkretes Produkt. alloy-it hilft bei Produktinventar, SBOM-Überwachung, Triage, Nachweisen zu Artikel 14 und dem Neubau-Pfad; es ist keine CE-Kennzeichnungssoftware, keine notifizierte Stelle und reicht keine Berichte bei ENISA oder nationalen CSIRTs ein.
Ein lebendes Produkt-SBOM aufsetzen
Hersteller- und aus Firmware abgeleitete Inventare je Version, kontinuierlicher Scan und Triage, kostenlos starten.