Skip to content

EU Cyber Resilience Act (CRA)

Der EU Cyber Resilience Act (CRA, deutsch: Cyberresilienz-Verordnung) legt horizontale Cybersicherheitsanforderungen für Produkte mit digitalen Elementen fest, also für Hard- und Software mit direkter oder indirekter Datenverbindung. Hersteller müssen Sicherheit über den gesamten Lebenszyklus nachweisen (Konzeption, Schwachstellenbehandlung, Updates, Meldungen) und erhalten dafür die CE-Kennzeichnung.

[!NOTE]

Alle Artikel-, Anhangs- und Erwägungsgrundverweise beziehen sich, sofern nicht anders angegeben, auf die Verordnung (EU) 2024/2847 und führen direkt zur jeweiligen Stelle. Die Quellen der Durchführungsrechtsakte und weiterer Dokumente stehen im Abschnitt Quellen. Die Seite ersetzt keine Rechtsberatung.

Überblick

  • Segment: IT Sicherheit / Produktregulierung (Binnenmarkt)

  • Verabschiedet / Veröffentlicht:

    • Verordnung (EU) 2024/2847 vom 23.10.2024 (Unterzeichnung), veröffentlicht im Amtsblatt der EU (Reihe L) am 20.11.2024
    • Inkrafttreten: 10.12.2024 (20. Tag nach Veröffentlichung, Art. 71 Abs. 1)

  • Gültig ab (Art. 71 Abs. 2):

    • Kapitel IV (Notifizierung von Konformitätsbewertungsstellen, Art. 35–51): 11. Juni 2026
    • Meldepflichten der Hersteller (Art. 14): 11. September 2026. Sie gelten auch für Produkte, die vor dem 11.12.2027 in Verkehr gebracht wurden (Art. 69 Abs. 3).
    • Alle übrigen Bestimmungen (u. a. grundlegende Anforderungen, Schwachstellenbehandlung, Konformitätsbewertung, CE-Kennzeichnung): 11. Dezember 2027
    • Übergang (Art. 69): Produkte, die vor dem 11.12.2027 in Verkehr gebracht wurden, unterliegen den übrigen Anforderungen nur bei einer wesentlichen Änderung nach diesem Datum (Abs. 2; Begriff: Art. 3 Nr. 30). Bestimmte EU-Baumusterprüfbescheinigungen und Zulassungen nach anderen Harmonisierungsrechtsvorschriften bleiben bis 11.06.2028 gültig (Abs. 1).

  • Gültig für (Art. 2 Abs. 1):

    Produkte mit digitalen Elementen, die auf dem Markt bereitgestellt werden und deren bestimmungsgemäßer Zweck oder vernünftigerweise vorhersehbare Verwendung eine direkte oder indirekte logische oder physische Datenverbindung mit einem Gerät oder Netz einschließt. Adressaten sind die Wirtschaftsakteure: Hersteller, Bevollmächtigte, Einführer und Händler (Art. 3 Nr. 12). Einführer und Händler gelten unter bestimmten Umständen selbst als Hersteller (Art. 21), ebenso wer eine wesentliche Änderung vornimmt (Art. 22). Die Bereitstellung auf dem Markt setzt eine Geschäftstätigkeit voraus (Art. 3 Nr. 22), erfasst aber entgeltliche und unentgeltliche Abgabe. Als Hersteller zählt auch, wer Produkte unentgeltlich vermarktet (Art. 3 Nr. 13). Eine Gewinnerzielungsabsicht ist also keine Voraussetzung.

    Eingeschlossen sind Datenfernverarbeitungslösungen, also vom Hersteller (oder unter seiner Verantwortung) entwickelte Backend-Dienste, ohne die das Produkt eine seiner Funktionen nicht erfüllen könnte (Art. 3 Nr. 2, ErwG 11, ErwG 12).

  • Nicht gültig für:

    • Produkte, die unter die Verordnungen (EU) 2017/745 (MDR) und (EU) 2017/746 (IVDR) oder (EU) 2019/2144 (Typgenehmigung Kraftfahrzeuge) fallen (Art. 2 Abs. 2; zu Medizinprodukten siehe MDR)
    • Nach der Verordnung (EU) 2018/1139 zertifizierte Produkte (Zivilluftfahrt, Art. 2 Abs. 3)
    • Geräte im Anwendungsbereich der Richtlinie 2014/90/EU (Schiffsausrüstung, Art. 2 Abs. 4)
    • Identische Ersatzteile (Art. 2 Abs. 6) sowie ausschließlich für nationale Sicherheit, Verteidigung oder den Umgang mit Verschlusssachen entwickelte Produkte (Art. 2 Abs. 7)
    • Reine Cloud-/SaaS-Angebote, die keine Datenfernverarbeitungslösung eines Produkts sind, sowie Websites ohne Bezug zur Produktfunktion (ErwG 12). Für Cloud-Dienste kann die NIS-2-Richtlinie greifen, siehe NIS2.
    • Freie und quelloffene Software, die nicht im Rahmen einer Geschäftstätigkeit bereitgestellt wird (z. B. nicht monetarisiert, ErwG 18); Personen, die lediglich Quellcode zu fremden Open-Source-Produkten beitragen, sind nicht erfasst. Achtung: Für den Begriff Verwalter quelloffener Software (Art. 3 Nr. 14) gelten eigene, leichtere Pflichten (Art. 24).
    • Eine Einschränkung oder ein Ausschluss für weitere Produkte mit gleichwertigen Sektorvorschriften ist über delegierte Rechtsakte möglich (Art. 2 Abs. 5).

  • Grauzone:

    • Abgrenzung "Geschäftstätigkeit" bei Open Source (Monetarisierung, Spenden, Foundations): ErwG 18 nennt Kriterien, Leitlinien der Kommission sind vorgesehen (Art. 26 Abs. 2).
    • SaaS mit IoT-Anteilen: Die Verordnung selbst enthält keine pauschale Regel; maßgeblich ist, ob der Dienst als Datenfernverarbeitungslösung eines Produkts gilt (ErwG 12). Praxisannahme: Dienst ohne Produktbezug => NIS-2, Produkt samt zugehörigem Backend => CRA.
    • Dual-Use-Güter und Logistik-Lösungen: Die Verordnung nennt hierzu nichts; entscheidend sind die allgemeinen Kriterien von Art. 2 Abs. 1 und die Ausnahmen in Abs. 2 bis 4 (Kfz, Luftfahrt, Schiffsausrüstung). Pauschale Aussagen zu Branchen sind nicht belegbar.
    • Individualentwicklungen: Auch maßgeschneiderte Produkte sind erfasst, dürfen aber teils vertraglich abweichend geregelt werden (z. B. sichere Standardkonfiguration und kostenlose Updates, Anhang I Teil I Nr. 2 Buchst. b, Teil II Nr. 8).
    • Nationale Umsetzung (Marktüberwachungsbehörde, Benennung des als Koordinator tätigen CSIRT, Sanktionsregeln nach Art. 52, Art. 64 Abs. 1): In Deutschland ist hierfür ein eigenes Durchführungsgesetz im Verfahren; das BSI ist dabei als zentrale Behörde vorgesehen. Den aktuellen Stand bitte beim Bundestag (DIP) prüfen.

  • Ziel: Ein hohes Cybersicherheitsniveau von Produkten mit digitalen Elementen über deren gesamten Lebenszyklus sowie einheitliche Regeln für den Binnenmarkt (Art. 1).

  • Produktklassen (Art. 7, Art. 8, Art. 32):

    • Standardprodukte: Konformitätsbewertung per interner Kontrolle (Modul A) möglich (Art. 32 Abs. 1).
    • Wichtige Produkte, Klasse I (Anhang III), z. B. Identitäts- und Passwort-Manager, Browser, VPN, Betriebssysteme, Router und Switches, SIEM: Modul A nur bei vollständiger Anwendung harmonisierter Normen, gemeinsamer Spezifikationen oder eines Zertifizierungsschemas (mind. Stufe "mittel"), sonst Modul B+C oder H (Art. 32 Abs. 2).
    • Wichtige Produkte, Klasse II (Anhang III), z. B. Hypervisoren und Container-Runtimes, Firewalls, IDS/IPS, manipulationssichere Mikroprozessoren und -controller: Modul B+C, Modul H oder Zertifizierung (mind. Stufe "mittel"), jeweils unter Beteiligung Dritter (Art. 32 Abs. 3).
    • Kritische Produkte (Anhang IV: Hardwaregeräte mit Sicherheitsboxen, Smart-Meter-Gateways, Chipkarten/Sicherheitselemente): europäisches Cybersicherheitszertifikat, sofern per delegiertem Rechtsakt gefordert (Art. 8 Abs. 1, Art. 32 Abs. 4).
    • Die technische Beschreibung der Kategorien regelt die Durchführungsverordnung (EU) 2025/2392 (nach Art. 7 Abs. 4). Die Kategorien können per delegiertem Rechtsakt geändert werden (Art. 7 Abs. 3, Art. 8 Abs. 2).
    • Die Integration eines Anhang-III-Produkts macht das umgebende Produkt nicht automatisch zum wichtigen Produkt (Art. 7 Abs. 1).

  • Neuerungen / Anforderungen:

    • Verbindliche Risikobewertung (Art. 13 Abs. 2 und 3) und grundlegende Cybersicherheitsanforderungen an das Produkt (Anhang I Teil I)
    • Verpflichtende Prozesse zur Schwachstellenbehandlung inkl. SBOM und koordinierter Offenlegung (Anhang I Teil II)
    • Unterstützungszeitraum von in der Regel mindestens fünf Jahren mit Sicherheitsupdates (Art. 13 Abs. 8); Sicherheitsupdates bleiben nach Bereitstellung mindestens zehn Jahre oder bis zum Ende des Unterstützungszeitraums (je nachdem, was länger ist) verfügbar (Art. 13 Abs. 9); Sicherheitsupdates werden kostenlos verbreitet (Anhang I Teil II Nr. 8)
    • Meldung aktiv ausgenutzter Schwachstellen und schwerwiegender Sicherheitsvorfälle über eine einheitliche Meldeplattform der ENISA (Art. 14, Art. 16)
    • EU-Konformitätserklärung und CE-Kennzeichnung (Art. 28, Art. 30)
    • Sanktionen: Bußgelder bis 15 Mio. EUR bzw. 2,5 % des weltweiten Jahresumsatzes bei Verstößen gegen Anhang I sowie Art. 13 und 14 (Art. 64 Abs. 2); bis 10 Mio. EUR bzw. 2 % bei Verstößen gegen weitere Pflichten, z. B. Art. 18 bis 23, 28, 30, 31, 32 (Abs. 3); bis 5 Mio. EUR bzw. 1 % bei falschen, unvollständigen oder irreführenden Angaben gegenüber Behörden und notifizierten Stellen (Abs. 4). Jeweils gilt der höhere Betrag. Ausnahmen: Verwalter quelloffener Software sind von diesen Geldbußen ausgenommen; Kleinst- und Kleinunternehmen für die 24-Stunden-Frist der Frühwarnung (Abs. 10).
    • Marktüberwachungsbehörden können unter anderem Korrekturmaßnahmen, Rücknahme oder Rückruf durchsetzen (Kapitel V, Art. 52 ff.).

Zentrale Forderungen

  • Software Bill of Materials (SBOM): Hersteller müssen Komponenten und Schwachstellen ermitteln und dokumentieren, u. a. durch eine SBOM in einem gängigen maschinenlesbaren Format, die mindestens die obersten Abhängigkeiten abbildet (Anhang I Teil II Nr. 1). Die SBOM gehört zur technischen Dokumentation (Anhang VII Nr. 2 Buchst. b) und ist der Marktüberwachungsbehörde auf begründetes Verlangen vorzulegen (Anhang VII Nr. 8). Eine Veröffentlichung oder Weitergabe an Nutzer ist nicht vorgeschrieben (Anhang II Nr. 9 regelt nur den Fall, dass der Hersteller sie bereitstellt). Die Kommission kann Format und Elemente per Durchführungsrechtsakt festlegen (Art. 13 Abs. 24); ein solcher Rechtsakt war bei der letzten Prüfung dieser Seite nicht ermittelt.

  • Cybersicherheitsrisikobewertung: Pflicht zur Bewertung, Dokumentation und gegebenenfalls Aktualisierung während des Unterstützungszeitraums, Berücksichtigung in allen Lebenszyklusphasen und Aufnahme in die technische Dokumentation (Art. 13 Abs. 2 bis 4, Anhang VII Nr. 3). Systematische Dokumentation aller relevanten Cybersicherheitsaspekte inkl. bekannter Schwachstellen: Art. 13 Abs. 7.

  • Grundlegende Anforderungen an das Produkt (Anhang I Teil I), u. a. keine bekannten ausnutzbaren Schwachstellen bei Bereitstellung, sichere Standardkonfiguration, Update-Fähigkeit, Zugriffsschutz, Schutz von Vertraulichkeit und Integrität, Datenminimierung, Protokollierung, sicheres Löschen von Daten.

  • Sorgfaltspflicht bei Drittkomponenten inkl. Open Source (Art. 13 Abs. 5). Wird in einer Komponente eine Schwachstelle festgestellt, ist sie deren Hersteller bzw. Betreuer zu melden und gemäß Anhang I Teil II zu beheben; entwickelte Korrekturen sind an diesen zurückzugeben (Art. 13 Abs. 6).

  • Schwachstellenbehandlung (Anhang I Teil II Nr. 2 bis 8): unverzügliche Behebung, regelmäßige Tests, Veröffentlichung behobener Schwachstellen, Strategie für koordinierte Offenlegung (CVD), Kontaktadresse für Schwachstellenmeldungen, sichere Update-Verteilung, kostenlose Verbreitung von Sicherheitsupdates. Dabei sind Sicherheitsupdates soweit technisch machbar getrennt von Funktionsupdates bereitzustellen (Nr. 2).

  • Unterstützungszeitraum: Der Hersteller legt ihn entsprechend der erwarteten Nutzungsdauer fest, mindestens fünf Jahre; bei erwarteter Betriebsdauer unter fünf Jahren entspricht er dieser (Art. 13 Abs. 8). Das Enddatum (mindestens Monat und Jahr) ist beim Kauf anzugeben (Art. 13 Abs. 19). Die Kommission kann per delegiertem Rechtsakt Mindestzeiträume für Produktkategorien festlegen.

  • Aufbewahrung: Technische Dokumentation und EU-Konformitätserklärung mindestens zehn Jahre nach Inverkehrbringen oder für die Dauer des Unterstützungszeitraums, je nachdem, was länger ist (Art. 13 Abs. 13); gleiches gilt für Informationen und Anleitungen für Nutzer (Art. 13 Abs. 18).

  • Informationen und Anleitungen für Nutzer nach Anhang II (Art. 13 Abs. 18), zentrale Anlaufstelle für Nutzer und Schwachstellenmeldungen (Art. 13 Abs. 17), Herstellerangaben und Produktidentifikation (Art. 13 Abs. 15 und 16).

  • Technische Dokumentation (Art. 31, Inhalt mindestens nach Anhang VII), vor dem Inverkehrbringen zu erstellen und mindestens während des Unterstützungszeitraums aktuell zu halten:

    • Allgemeine Beschreibung des Produkts inkl. Zweckbestimmung, relevanter Softwareversionen und Nutzerinformationen nach Anhang II (Nr. 1)
    • Beschreibung von Konzeption, Entwicklung, Herstellung und der Verfahren zur Schwachstellenbehandlung inkl. SBOM, CVD-Konzept, Kontaktadresse und Update-Verteilung (Nr. 2)
    • Cybersicherheitsrisikobewertung (Nr. 3), inkl. Zweckbestimmung und vernünftigerweise vorhersehbarer Verwendung bzw. Fehlanwendung (Art. 13 Abs. 3)
    • Informationen, die bei der Festlegung des Unterstützungszeitraums berücksichtigt wurden (Nr. 4)
    • Angewandte harmonisierte Normen, gemeinsame Spezifikationen oder Zertifizierungsschemata bzw. Beschreibung der gewählten Lösungen (Nr. 5)
    • Testberichte (Nr. 6) und Kopie der EU-Konformitätserklärung (Nr. 7)
    • Kleinst- und Kleinunternehmen dürfen ein vereinfachtes Format verwenden (Art. 33 Abs. 5)

  • Konformitätsbewertung, EU-Konformitätserklärung und CE-Kennzeichnung: Der Hersteller führt das Verfahren nach Art. 32 durch, stellt dann die EU-Konformitätserklärung nach Art. 28 (Muster: Anhang V; vereinfachte Fassung: Anhang VI) aus und bringt die CE-Kennzeichnung nach Art. 30 an (Art. 13 Abs. 12). Bei Software darf die CE-Kennzeichnung auf der Konformitätserklärung oder der begleitenden Website angebracht werden (Art. 30 Abs. 1). Eine Konformitätsvermutung besteht bei Anwendung harmonisierter Normen, gemeinsamer Spezifikationen oder Zertifikaten (Art. 27).

  • Korrekturmaßnahmen bei erkannter Nichtkonformität bis hin zu Rücknahme oder Rückruf (Art. 13 Abs. 21); Zusammenarbeit mit der Marktüberwachung (Art. 13 Abs. 22); Information bei Betriebseinstellung (Art. 13 Abs. 23).

  • Meldepflichten (Art. 14), gültig seit dem 11. September 2026. Meldungen gehen gleichzeitig an das als Koordinator benannte CSIRT des Mitgliedstaats der Hauptniederlassung und an die ENISA, und zwar über die einheitliche Meldeplattform der ENISA (Art. 14 Abs. 1, 3 und 7, Art. 16):

    • Für aktiv ausgenutzte Schwachstellen (Art. 3 Nr. 42), Art. 14 Abs. 2:
      • Frühwarnung unverzüglich, spätestens 24 Stunden nach Kenntnis, inkl. Angabe der betroffenen Mitgliedstaaten (Buchst. a)
      • Meldung der Schwachstelle unverzüglich, spätestens 72 Stunden nach Kenntnis, mit allgemeinen Produktinformationen, Art der Ausnutzung und Schwachstelle sowie ergriffenen Maßnahmen und Nutzer-Abhilfen (Buchst. b)
      • Abschlussbericht spätestens 14 Tage nachdem eine Korrektur- oder Risikominderungsmaßnahme verfügbar ist (Buchst. c)
    • Für schwerwiegende Sicherheitsvorfälle mit Auswirkung auf die Produktsicherheit (Art. 14 Abs. 3 bis 5):
      • Frühwarnung innerhalb von 24 Stunden, Meldung innerhalb von 72 Stunden
      • Abschlussbericht innerhalb eines Monats nach der 72-Stunden-Meldung
      • Schwerwiegend ist ein Vorfall, der die Fähigkeit zum Schutz sensibler oder wichtiger Daten oder Funktionen beeinträchtigt (oder beeinträchtigen kann) oder zur Einschleusung bzw. Ausführung von Schadcode im Produkt oder im Netz bzw. System eines Nutzers geführt hat oder führen kann (Art. 14 Abs. 5). Der Vorfall muss sich auf die Sicherheit des Produkts mit digitalen Elementen auswirken (Art. 3 Nr. 44).
    • Das CSIRT kann Zwischenberichte anfordern (Art. 14 Abs. 6).
    • Nutzerinformation: Nach Kenntnis informiert der Hersteller betroffene Nutzer über die Schwachstelle bzw. den Vorfall und mögliche Gegenmaßnahmen, gegebenenfalls in einem strukturierten, maschinenlesbaren Format (Art. 14 Abs. 8). Das Format CSAF wird in der Verordnung nicht genannt; es ist ein geeigneter Kandidat für die maschinenlesbare Variante.
    • Freiwillige Meldungen (auch Beinahe-Vorfälle und Cyberbedrohungen, auch durch Dritte): Art. 15.
    • Format und Verfahren der Meldungen kann die Kommission per Durchführungsrechtsakt präzisieren (Art. 14 Abs. 10).

  • Koordinierte Offenlegung von Schwachstellen (CVD): Strategie aufstellen und umsetzen (Anhang I Teil II Nr. 5 und Art. 13 Abs. 8); Kontaktadresse für Meldungen bereitstellen (Teil II Nr. 6, Anhang II Nr. 2).

  • Pflichten weiterer Akteure: Bevollmächtigte (Art. 18), Einführer (Art. 19), Händler (Art. 20) und Verwalter quelloffener Software (Art. 24: dokumentierte Cybersicherheitsstrategie, Zusammenarbeit mit Behörden; Meldepflichten nach Art. 14 nur soweit sie an der Entwicklung beteiligt sind).

  • Verhältnis zu anderen Rechtsakten: Hochrisiko-KI-Systeme im Sinne der KI-Verordnung gelten bei Erfüllung der CRA-Anforderungen als konform mit deren Cybersicherheitsanforderungen (Art. 12, siehe AI Act); für Haftungsfragen siehe PLD.

Lösungsansätze & Hilfestellung

[!NOTE]

Die Spalte "Regulatorische Relevanz" zeigt, welche Anforderung ein Werkzeug unterstützen kann. Kein Werkzeug stellt für sich Konformität her; als Konformitätsnachweis zählen die Verfahren nach Art. 32 bzw. die Konformitätsvermutung nach Art. 27. Harmonisierte Normen werden erarbeitet; ihr Status ist bei CEN, CENELEC und ETSI sowie im Amtsblatt zu prüfen.

BSI TR-03183: Technische Richtlinie des BSI

Das BSI veröffentlicht mit der Technischen Richtlinie TR-03183 seine Auslegung der Cyberresilienz-Anforderungen an Hersteller und Produkte. Sie dient der Vorbereitung auf den CRA, ist nicht verbindlich, begründet keine Konformitätsvermutung und soll durch die entsprechenden harmonisierten Europäischen Normen abgelöst werden, sobald diese vorliegen (siehe BSI-Seite zur TR-03183 und Abschnitt 2 von Teil 1). Sie wird als „Living Document" fortlaufend weiterentwickelt. Die Richtlinie besteht aus vier Teilen (Stand der Versionen laut BSI am 09.10.2026):

Teil Inhalt Aktuelle Version
Teil 1: General Requirements Allgemeine Anforderungen an Hersteller und Produkte auf Basis der Artikel und Anhänge des CRA: Überblick über den CRA, risikobasierter Ansatz (Risikobewertung und -behandlung), Anhang I im Wortlaut, generische Sicherheitsmaßnahmen („Controls") im maschinenlesbaren Format OSCAL (Zugang auf Anfrage an tr03183@bsi.bund.de) 1.0.0
Teil 2: Software Bill of Materials (SBOM) Formale und technische Anforderungen an SBOMs 2.1.0
Teil 3: Vulnerability Reports and Notifications Umgang mit eingehenden Schwachstellenmeldungen (Coordinated Vulnerability Disclosure) 1.0.0
Teil H: Conformity based on full quality assurance (Module H) Konformitätsnachweis auf Basis einer umfassenden Qualitätssicherung (Modul H, Anhang VIII) über ein ISO/IEC-27001-konformes ISMS, als Alternative zu Modul B+C; kein neuer Managementsystemstandard 1.1.0
  • Teil 2 (SBOM) verlangt eine maschinenverarbeitbare SBOM im JSON- oder XML-Format nach CycloneDX ab Version 1.6 oder SPDX ab Version 3.0.1. Pflichtangaben sind für die SBOM selbst der Ersteller und ein Zeitstempel, je Komponente u. a. Ersteller, Name, Version, Dateiname, Abhängigkeiten, Distributionslizenz, Hashwert der auslieferbaren Komponente sowie die Eigenschaften „ausführbar", „Archiv" und „strukturiert". Die Abhängigkeiten sind rekursiv mindestens bis zur ersten Komponente außerhalb des Lieferumfangs aufzulösen; das geht über den in Anhang I Teil II Nr. 1 genannten Mindestumfang (Abhängigkeiten der obersten Ebene) hinaus. Eine SBOM enthält nach der TR keine Aussagen zu Schwachstellen; dafür verweist das BSI auf Sicherheitsadvisories wie CSAF und auf VEX. Die TR enthält ein Mapping der Datenfelder auf SPDX und CycloneDX, das BSI pflegt zudem einen eigenen CycloneDX-Namespace samt Taxonomie. Zur Versionierung gilt: Für neue SBOMs ist die jeweils neueste Fassung der TR zu verwenden; die unmittelbar vorhergehende Fassung darf bis sechs Monate nach Erscheinen einer neuen Fassung weiter angewendet werden.
  • Teil 3 behandelt die Anforderungen an den Empfang von Schwachstellenmeldungen: Herstellerwebseite, security.txt nach RFC 9116, vorbereitende Maßnahmen für einen CVD-Prozess (Rollen, Verschlüsselungsoptionen, Webformular) und eine CVD-Policy. Das entspricht inhaltlich den Vorgaben in Anhang I Teil II Nr. 5 und 6 (CVD-Richtlinie, Kontaktadresse für Schwachstellenmeldungen).
  • Teil 1 wird laut BSI als Selbstbewertung durch den Hersteller oder durch einen Dritten im Auftrag des Herstellers angewendet. Er schafft ausdrücklich keine Pflichten für Hersteller und weist darauf hin, dass er nicht den einzigen Weg zur Erfüllung der Anforderungen beschreibt.

SBOM-Erstellung & Komponenten-Analyse

Tool Lizenz Problem / Zweck Regulatorische Relevanz
Syft Apache-2.0 Generiert SBOMs aus Container-Images, Dateisystemen und Quellcode in CycloneDX- und SPDX-Format; unterstützt 30+ Ökosysteme Anhang I Teil II Nr. 1: Komponentendokumentation / SBOM; Anhang VII Nr. 2 b: SBOM in der technischen Dokumentation
cdxgen Apache-2.0 Erzeugt CycloneDX-SBOMs aus Quellcode und Build-Manifesten für 20+ Sprachen; unterscheidet Build- und Runtime-Dependencies Anhang I Teil II Nr. 1; besonders geeignet für Hersteller, die mit Quellcode-Analysen argumentieren müssen
Trivy Apache-2.0 All-in-One-Scanner: SBOM-Generierung + Schwachstellen + Fehlkonfigurationen + Secrets in einem Lauf; ideal für CI/CD Anhang I Teil II Nr. 1 und 3: SBOM, Ermittlung von Schwachstellen und regelmäßige Tests; Teil I Nr. 2 a: keine bekannten ausnutzbaren Schwachstellen
TrustSource ts-scan Open Source Universeller SCA-Scanner: analysiert Abhängigkeiten aus Build-Systemen und Paketmanagern, erzeugt CycloneDX/SPDX-SBOMs und überträgt Ergebnisse in die TrustSource-Plattform Anhang I Teil II Nr. 1: Komponentenerfassung / SBOM
TrustSource CE AGPL (Community Edition) Vollständige SCA-Plattform: SBOM-Erstellung, -Versionierung und -Management, Vulnerability Management sowie CSAF-Kommunikation für Security Advisories; CLI-Clients für alle gängigen Build-Systeme Anhang I Teil II Nr. 1 und Anhang VII Nr. 2 b: SBOM in der technischen Dokumentation; Art. 14 Abs. 8: maschinenlesbare Nutzerinformation; NIS2 Art. 21 Abs. 2 d und e: Lieferkettensicherheit, Schwachstellenmanagement
TrustSource sbom2notice Open Source Generiert rechtskonforme Open-Source-Hinweisdokumente (License Notice Files) aus SBOMs; erfüllt Lizenz-Attribuierungspflichten der enthaltenen Komponenten Keine CRA-Pflicht; ergänzt die SBOM um die lizenzrechtliche Komponente (Sorgfalt bei Drittkomponenten: Art. 13 Abs. 5)
SPDX Tools Apache-2.0 Referenzimplementierung für SPDX-Format: Validierung, Konvertierung, Generierung SPDX ist als ISO/IEC 5962:2021 genormt und ein gängiges maschinenlesbares SBOM-Format im Sinne von Anhang I Teil II Nr. 1; ein verbindliches Format kann die Kommission per Durchführungsrechtsakt festlegen (Art. 13 Abs. 24)

Für Format und Mindestinhalte einer SBOM ist Teil 2 der BSI TR-03183 die maßgebliche Orientierung. Sie ist keine Norm im Sinne des Art. 27, begründet also keine Konformitätsvermutung.

Schwachstellen-Management

Tool Lizenz Problem / Zweck Regulatorische Relevanz
Grype Apache-2.0 Schwachstellenscanner auf Basis von Syft-SBOMs; gleicht Komponenten gegen NVD, GitHub Advisory DB und OSV ab Anhang I Teil II Nr. 2 und 3: Schwachstellen unverzüglich behandeln, regelmäßig testen; Teil I Nr. 2 a: keine bekannten ausnutzbaren Schwachstellen bei Bereitstellung
OSV-Scanner Apache-2.0 Scannt Dependency-Manifeste und SBOMs gegen die OSV-Datenbank (Google); hohe Abdeckung für Open-Source-Ökosysteme Anhang I Teil II Nr. 1 und 3; Art. 13 Abs. 5 und 6: Sorgfalt bei Drittkomponenten, Meldung von Komponenten-Schwachstellen
Dependency-Track Apache-2.0 Kontinuierliche SBOM-Analyse-Plattform (OWASP): nimmt SBOMs entgegen, überwacht fortlaufend gegen mehrere Vuln-Quellen, erzeugt VEX-Dokumente Anhang I Teil II Nr. 1 und 2 sowie Art. 13 Abs. 7: laufende Komponenten- und Schwachstellenüberwachung samt Dokumentation. Die Meldungen nach Art. 14 erfolgen über die ENISA-Plattform, nicht über das Tool
DefectDojo BSD-3-Clause AppSec-Vulnerability-Management: aggregiert Scanner-Ergebnisse, dedupliziert, verfolgt Remediation und SLAs Anhang I Teil II Nr. 2 und Art. 13 Abs. 7: nachvollziehbarer Behebungsprozess mit Audit-Trail
TrustSource CE AGPL (Community Edition) Kontinuierliches Vulnerability Management auf SBOM-Basis: verfolgt Schwachstellen über den gesamten Produktlebenszyklus, priorisiert nach EPSS/CVSS und kommuniziert Ergebnisse via CSAF Anhang I Teil II Nr. 2 und 4: laufende Behebung, Information über behobene Schwachstellen; Art. 14 Abs. 8: Nutzerinformation (maschinenlesbar). Die Meldung an CSIRT und ENISA erfolgt über die einheitliche Meldeplattform

Coordinated Vulnerability Disclosure (CVD) & Sicherheits-Advisories

Anforderungen an den Empfang von Schwachstellenmeldungen (security.txt, CVD-Policy, Kontaktwege) beschreibt Teil 3 der BSI TR-03183.

Tool Lizenz Problem / Zweck Regulatorische Relevanz
CSAF-Tooling (gocsaf/csaf) Apache-2.0 / MIT CSAF-Referenz-Server (csaf_provider), Validator (csaf_checker); der Web-Editor Secvisogram erstellt maschinenlesbare Sicherheitsadvisories Anhang I Teil II Nr. 4: Veröffentlichung von Informationen zu behobenen Schwachstellen; Art. 14 Abs. 8: maschinenlesbare Nutzerinformation. Das CRA schreibt CSAF nicht vor
OpenVEX Apache-2.0 Maschinenlesbares Format zur Kommunikation des Ausnutzbarkeitsstatus von Schwachstellen (affected / not-affected / fixed); vexctl CLI Anhang I Teil II Nr. 4: Informationen zu Schwachstellen und deren Auswirkungen teilen; VEX ist im CRA nicht vorgeschrieben, reduziert aber False-Positive-Aufwand
Vince MIT Open-Source-CVD-Case-Management-Plattform von CERT/CC: Intake, Triage, Koordination, Publikation Anhang I Teil II Nr. 5 und 6 und Art. 13 Abs. 17: CVD-Prozess, Kontaktadresse, zentrale Anlaufstelle
disclose.io Templates CC0 Standardisierte CVD-Policy-Vorlagen mit rechtlicher Safe-Harbor-Sprache Anhang I Teil II Nr. 5: Einstiegspunkt für eine CVD-Policy
TrustSource CE AGPL (Community Edition) Integrierte CSAF-Kommunikation: erzeugt und verteilt Security Advisories direkt aus dem Vulnerability-Management-Workflow heraus Anhang I Teil II Nr. 4 und Art. 14 Abs. 8: Advisories an Nutzer; die Meldungen an CSIRT und ENISA sind davon getrennt (einheitliche Meldeplattform, Art. 16)

Software Supply Chain Security

Tool Lizenz Problem / Zweck Regulatorische Relevanz
Sigstore / cosign Apache-2.0 Schlüsselloses Signieren und Verifizieren von Container-Images, SBOMs und anderen Artefakten; cosign kann signierte SBOMs direkt an Images anheften Anhang I Teil I Nr. 2 f und Teil II Nr. 7: Integrität, sichere Verbreitung von Updates; NIS2 Art. 21 Abs. 2 d: Lieferkettensicherheit
SLSA Framework Open Framework (OpenSSF) Gestufte Anforderungen für Build-Integrität mit verifizierbarer Provenance; slsa-github-generator für GitHub Actions Kein CRA-Pflichtstandard; kann sichere Herstellungs- und Verteilprozesse belegen (Anhang VII Nr. 2 c, Anhang I Teil II Nr. 7)
in-toto Apache-2.0 Kryptografisch verifizierbarer Nachweis jedes Build-Pipeline-Schritts (wer hat was ausgeführt, mit welchen Inputs) Anhang VII Nr. 2 c: Beschreibung und Validierung der Herstellungs- und Überwachungsprozesse
GUAC Apache-2.0 Verknüpft SBOM-, SLSA- und Schwachstellendaten in einem Graphen; ermöglicht Queries wie „welche unserer Produkte sind von CVE-X betroffen?" Art. 13 Abs. 5 bis 7: Drittkomponenten, Schwachstellenmeldung und -dokumentation; NIS2 Art. 21 Abs. 2 d
TrustSource CE AGPL (Community Edition) Zentrales SBOM-Repository mit Versionierung: verfolgt die Zusammensetzung jeder Produktversion über die Zeit und macht Lieferketten-Risiken transparent Anhang VII Nr. 2 b und Art. 13 Abs. 7: SBOM und Dokumentation über den Produktlebenszyklus; Anhang I Teil II Nr. 1

Quellen