Blackfort Technology

SBOM & Cyber Resilience Act: Wissen Sie, was in Ihrer Software steckt?

Ohne SBOM keine CRA-Compliance — und keine schnelle Schwachstellenmeldung

Ab dem 11. September 2026 müssen Hersteller von Produkten mit digitalen Elementen aktiv ausgenutzte Schwachstellen innerhalb von 24 Stunden als Frühwarnung melden — gefolgt von einer vollständigen Meldung nach 72 Stunden. Wer in diesem Moment nicht weiß, welche Drittkomponenten in seinem Produkt verbaut sind, für den droht diese Frist in der Praxis zu reißen.

Die Software Bill of Materials (SBOM) ist kein optionales Beiwerk: Der Cyber Resilience Act (Verordnung (EU) 2024/2847) verlangt von Herstellern eine vollständige Übersicht aller Softwarekomponenten als Teil der technischen Dokumentation — einschließlich Open-Source-Abhängigkeiten, Versionsangaben und bekannter Schwachstellen. Diese Dokumentation ist über den gesamten Supportzeitraum vorzuhalten, typischerweise mindestens zehn Jahre.

Das Problem: Die meisten SBOM-Projekte stecken im Pilot-Stadium

Laut ENISA haben zwar 78 % der betroffenen Unternehmen ihre SBOM-Implementierung begonnen — aber 44 % befinden sich noch in der Pilotphase. Eine Pilot-SBOM genügt den CRA-Anforderungen nicht: Sie deckt typischerweise nicht alle Produktlinien ab, entspricht nicht dem erforderlichen Format (CycloneDX ≥ 1.6 oder SPDX ≥ 3.0.1) und ist nicht in einen wiederholbaren Prozess für Schwachstellen-Tracking eingebettet.

Die Lücke zwischen "wir haben etwas angefangen" und "wir sind CRA-bereit" ist in vielen Unternehmen größer als gedacht — und die Zeit bis September 2026 ist knapp.

Was der SBOM→CRA-Gap-Report bringt

Blackfort Technology analysiert Ihre bestehende SBOM-Praxis — oder legt die Basis, wenn noch keine vorhanden ist — und bewertet sie gegen die konkreten CRA-Anforderungen. Das Ergebnis ist ein strukturierter Bericht mit klaren Handlungsempfehlungen:

  • Format-Konformität: Entspricht Ihre SBOM dem Standard CycloneDX ≥ 1.6 oder SPDX ≥ 3.0.1, wie vom BSI in TR-03183-2 referenziert?
  • Vollständigkeit: Sind alle relevanten Komponenten, Abhängigkeiten und transitive Abhängigkeiten erfasst?
  • Prozess-Integration: Wird die SBOM automatisiert im Build-Prozess erzeugt und aktuell gehalten — oder ist sie ein einmaliger Snapshot?
  • Schwachstellen-Tracking: Ist ein Prozess etabliert, mit dem bekannte CVEs gegen Ihre Komponentenliste abgeglichen werden (z. B. via Dependency-Track, Grype oder vergleichbare SCA-Tools)?
  • Archivierung: Wie ist sichergestellt, dass SBOM-Versionen über den gesamten Supportzeitraum abrufbar bleiben?
  • Meldeprozess-Readiness: Können Sie im Ernstfall innerhalb von 24 Stunden belegen, welche Produkte von einer Schwachstelle betroffen sind?

Kompetenz aus der Praxis

Christian Gebhardt, Geschäftsführer von Blackfort Technology, bringt Umsetzungserfahrung aus realen ISMS- und Schwachstellenmanagement-Projekten mit. Er ist Mitglied der ACS-KI-Facharbeitsgruppe und Mitautor des ACS/BSI-Leitfadens zum Pentesting von LLMs. Das bedeutet für Ihre SBOM-Bewertung: keine abstrakte Regulatorik, sondern technisch fundierte Analyse mit klarem Bezug zu den tatsächlichen CRA-Anforderungen.

Blackfort Technology setzt bei der SBOM-Analyse auf etablierte Open-Source-Werkzeuge wie Dependency-Track (OWASP) für kontinuierliches Software Composition Analysis (SCA) sowie auf CycloneDX-native Toolchains — damit Sie nicht von proprietären Plattformen abhängig werden.

SBOM-Tiefe hängt von Ihrer CRA-Produktklasse ab

Welche SBOM-Anforderungen konkret für Ihr Produkt gelten, hängt auch von der CRA-Produktklasse ab. Hersteller von Produkten der Klasse I oder Klasse II (Anhang III, Verordnung (EU) 2024/2847, konkretisiert durch Durchführungsverordnung (EU) 2025/2392) unterliegen strengeren Konformitätsbewertungsanforderungen — und damit auch höheren Erwartungen an Dokumentationstiefe und Prozessreife.

Orientierungsrahmen: SBOM-Anforderungen nach Produktklasse
Produktklasse Konformitätsbewertung Typische SBOM-Erwartung
Standard Selbstbewertung (Modul A) Vollständige SBOM, maschinenlesbar, im Prozess verankert
Wichtig — Klasse I Selbstbewertung nur bei harmonisierten Normen/Spezifikationen; sonst notifizierte Stelle SBOM inklusive Abhängigkeitstiefe, CVE-Mapping, nachweisbarer Prozess
Wichtig — Klasse II Notifizierte Stelle verpflichtend SBOM als prüfbarer Bestandteil der technischen Dokumentation; Archivierung belegt
Kritisch (Anhang IV) Notifizierte Stelle oder EU-Zertifizierungsschema Höchste Anforderungen; SBOM Teil des Konformitätsnachweises

Wenn Sie noch nicht sicher sind, in welche Klasse Ihr Produkt fällt, hilft der Betroffenheits-Check auf cra-readiness.de als erster Schritt.

Wie der Gap-Report abläuft

  1. Erstgespräch (30 Minuten): Wir erfassen Ihre Produktlandschaft, bestehende SBOM-Praxis und die relevante Toolchain.
  2. Dokumentenanalyse: Sie stellen vorhandene SBOMs, Build-Beschreibungen und Schwachstellenprozesse bereit — vertraulich, keine Weitergabe an Dritte.
  3. Gap-Analyse: Abgleich gegen CRA-Anforderungen, TR-03183-2 und Ihre Produktklasse.
  4. Bericht und Maßnahmenplan: Schriftlicher Report mit priorisierten Handlungsempfehlungen, Tooling-Vorschlägen und realistischem Zeitplan bis September 2026 bzw. Dezember 2027.

Das Tool für einen selbstständigen Online-Check ist in Entwicklung. Wenn Sie nicht warten möchten: Jetzt Gap-Report direkt anfragen.

Häufige Fragen

Ist eine SBOM im Cyber Resilience Act wirklich verpflichtend?
Die Verordnung (EU) 2024/2847 verpflichtet Hersteller zur Sorgfaltspflicht gegenüber Drittkomponenten und zur vollständigen technischen Dokumentation — eine SBOM ist zentrales Mittel, um diese Anforderungen zu erfüllen. Ob im Einzelfall eine bestimmte Form vorgeschrieben ist, hängt von der Produktklasse und den anzuwendenden harmonisierten Normen ab.
Welches SBOM-Format ist für den CRA vorgeschrieben?
Der CRA selbst schreibt kein Format vor, verweist aber auf technische Spezifikationen. Der BSI-Standard TR-03183-2 referenziert CycloneDX ≥ 1.6 und SPDX ≥ 3.0.1 als geeignete Formate. Für die Praxis empfiehlt sich CycloneDX, da es nativ von Dependency-Track und vielen CI/CD-Tools unterstützt wird.
Wie lange muss eine SBOM aufbewahrt werden?
Die technische Dokumentation — einschließlich SBOM — muss über den gesamten Supportzeitraum des Produkts vorgehalten werden, typischerweise mindestens zehn Jahre. Maßgeblich ist der im Produkt ausgewiesene Support-Zeitraum; bei Produkten ohne explizite Angabe dürfte die Anforderung länger gelten.
Was ist der Unterschied zwischen einem SBOM und einem Gap-Report?
Eine SBOM ist das Dokument selbst — die Inventarliste aller Softwarekomponenten. Ein SBOM→CRA-Gap-Report bewertet, ob Ihre bestehende SBOM-Praxis die CRA-Anforderungen erfüllt: Format, Vollständigkeit, Prozessreife, Schwachstellen-Tracking und Archivierung. Er zeigt konkrete Lücken und priorisierten Handlungsbedarf.
Betrifft das auch Unternehmen, die Open-Source-Software nutzen?
Ja. Wer Open-Source-Komponenten in ein kommerzielles Produkt integriert und dieses auf dem EU-Markt bereitstellt, unterliegt als Hersteller dem CRA — unabhängig davon, ob die Komponenten kostenlos sind. Der CRA sieht Erleichterungen für Open-Source-Stewards vor, nicht aber für Hersteller, die FOSS einbetten.

Sprechen wir über Ihre CRA-Readiness

Gap-Report anfragen — wir analysieren Ihre SBOM-Praxis gegen die CRA-Anforderungen und liefern einen priorisierten Maßnahmenplan. Erstgespräch kostenlos und unverbindlich.

Erstgespräch anfragen Betroffenheit prüfen
Die Inhalte dieser Website dienen der allgemeinen technischen und organisatorischen Information zum Cyber Resilience Act (Verordnung (EU) 2024/2847) und stellen keine Rechtsberatung dar. Blackfort Technology erbringt IT-Security- und Compliance-Beratung im technisch-organisatorischen Sinne, keine Rechtsdienstleistungen i.S.d. RDG.