EU Cyber Resilience Act · verbindlich ab Dezember 2027

Wissen, was in Ihrer Software steckt.

Moderne Software wird zusammengesetzt, nicht von Grund auf geschrieben. Ein Software Bill of Materials (SBOM) macht jede einzelne Komponente sichtbar – die Grundlage für Sicherheit, Wartbarkeit und die Compliance-Pflichten, die mit dem EU Cyber Resilience Act auf Software-Hersteller zukommen.

Beratung anfragen Das Problem verstehen
77 %
des durchschnittlichen Codebestands ist Fremd- und Open-Source-Code[1]
11.12.2027
Vollständige Geltung des EU Cyber Resilience Act[2]
bis 15 Mio. €
oder 2,5 % des weltweiten Jahresumsatzes bei Verstößen[2]

Die Ausgangslage

Eine typische Anwendung besteht heute nur zu einem kleinen Teil aus selbst geschriebenem Code. Der weitaus größere Teil stammt aus hunderten von Open-Source-Bibliotheken[1] – und diese bringen wiederum ihre eigenen Abhängigkeiten mit, transitiv oft tausende. Dieser Code ist produktiv und wertvoll, aber meist unsichtbar: Nur wenige Teams verfügen über eine vollständige, aktuelle Übersicht der tatsächlich ausgelieferten Komponenten.

Man kann nicht schützen, was man nicht kennt.

Wird eine kritische Schwachstelle in einer weit verbreiteten Komponente bekannt, lautet die erste – und teuerste – Frage stets: „Sind wir überhaupt betroffen, und wenn ja, wo?“ Ohne ein Komponenten­inventar dauert die Antwort Tage und bindet genau die Fachleute, die man in einer Krise am dringendsten braucht. Die vergangenen Jahre haben gezeigt, wie konkret dieses Risiko ist:

  • Log4Shell (2021) – eine Lücke in der Logging-Bibliothek Log4j versetzte weltweit ganze IT-Abteilungen tagelang in den Krisenmodus, weil niemand sicher wusste, wo die Komponente überall steckte.[3]
  • xz/liblzma-Backdoor (2024) – in ein weit verbreitetes Kompressions-Tool wurde gezielt eine Hintertür eingeschleust; eine zufällige Entdeckung verhinderte einen Angriff auf einen Großteil der Server im Internet.[4]
  • SolarWinds (2020) – manipulierte Software-Updates kompromittierten tausende Organisationen und rückten die Software-Lieferkette in den Fokus der Vorstandsebene.[5]

Was ist ein SBOM?

Ein Software Bill of Materials ist ein formales, maschinenlesbares Verzeichnis aller Komponenten und Abhängigkeiten einer Software[6] – vergleichbar mit der Zutatenliste Ihrer Software. Für jede Komponente hält es fest, was drinsteckt und woher es kommt.

  • Name und exakte Version
  • Hersteller bzw. Herkunft
  • Lizenz der Komponente
  • Abhängigkeitsbeziehungen
  • Prüfsumme / kryptografischer Hash
  • Verknüpfung zu bekannten Schwachstellen

Damit ein SBOM zwischen Werkzeugen, Herstellern und Behörden austauschbar ist, haben sich zwei offene, standardisierte Formate durchgesetzt: SPDX (ISO/IEC 5962)[7] und CycloneDX (OWASP)[8] – beide maschinenlesbar (JSON / XML) und von gängigen Werkzeugen unterstützt.

Der regulatorische Druck steigt

SBOMs entwickeln sich von einer freiwilligen Best Practice zur gesetzlichen Pflicht.[2][9] Der zentrale Treiber in der EU ist der Cyber Resilience Act (CRA) – Verordnung (EU) 2024/2847, in Kraft seit dem 10. Dezember 2024.[2] Er gilt für nahezu alle „Produkte mit digitalen Elementen“, die auf dem EU-Markt bereitgestellt werden, und verlangt von Herstellern unter anderem:[2]

  • ein maschinenlesbares SBOM (mindestens die direkten Abhängigkeiten) als Teil der technischen Dokumentation,
  • Sicherheit „by design und by default" über den gesamten Produktlebenszyklus,
  • zeitnahe Sicherheitsupdates und ein geregeltes Schwachstellen-Management,
  • die Meldung aktiv ausgenutzter Schwachstellen und schwerwiegender Vorfälle.

Die wichtigsten Fristen des CRA[2]

10. Dezember 2024
Inkrafttreten
Der CRA ist in Kraft getreten; die Übergangsfrist für Hersteller beginnt.
11. September 2026
Meldepflichten greifen
Aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle müssen gemeldet werden – ohne Komponentenüberblick praktisch nicht erfüllbar.
11. Dezember 2027
Vollständige Geltung
Alle Herstellerpflichten gelten. Ohne CE-Kennzeichnung dürfen betroffene Produkte nicht mehr auf dem EU-Markt bereitgestellt werden.
Bußgeldrahmen: Verstöße gegen die zentralen Pflichten können mit Geldbußen von bis zu 15 Mio. € oder 2,5 % des weltweiten Jahresumsatzes geahndet werden – je nachdem, welcher Betrag höher ist.[2]

Der CRA steht dabei nicht allein. Die NIS2-Richtlinie verpflichtet wesentliche und wichtige Einrichtungen zu Risikomanagement entlang der Lieferkette,[10] branchenspezifische Regeln kommen hinzu, und international verlangt etwa die US Executive Order 14028 SBOMs von Zulieferern der US-Behörden.[9] Das SBOM wird zum gemeinsamen Nenner all dieser Anforderungen.

Diese Seite bietet einen fachlichen Überblick und ersetzt keine Rechtsberatung.

Was SBOM-Analyse bringt

Ein SBOM ist kein Selbstzweck. Erst die kontinuierliche Analyse des Inventars macht aus der Zutatenliste einen konkreten Nutzen – für Sicherheit, Recht und Geschäft:

Schwachstellen früher erkennen

Neue CVEs werden automatisch gegen Ihren Komponentenbestand abgeglichen. Sie erfahren in Minuten statt in Tagen, ob und wo Sie betroffen sind.

Lizenz-Compliance

Jede Abhängigkeit bringt eine Lizenz mit. Die Analyse deckt riskante oder inkompatible Lizenzen (etwa strenges Copyleft) auf, bevor daraus ein Rechtsproblem wird.

Schnellere Incident-Response

Bei der nächsten kritischen Schwachstelle wie Log4Shell beantworten Sie die Frage „Sind wir betroffen?" per Datenbankabfrage statt in einer tagelangen Krisensitzung.

Nachweisbare Compliance

Ein aktuelles, maschinenlesbares SBOM ist genau der Nachweis, den CRA und zunehmend auch Kunden verlangen – jederzeit vorzeigbar statt mühsam nachträglich erstellt.

Vorteil in Ausschreibungen

Immer mehr Auftraggeber – Behörden wie Konzerne – fordern SBOMs als Teil der Lieferung. Anbieter, die ein SBOM liefern können, qualifizieren sich für die Ausschreibung; ohne SBOM droht der Ausschluss aus dem Verfahren.

Überblick über die Lieferkette

Der Großteil des Risikos steckt in transitiven Abhängigkeiten. Erst das SBOM macht die tieferen Ebenen Ihrer Software-Lieferkette überhaupt sichtbar.

Herangehensweise für Software-Hersteller

Der Weg zu einem tragfähigen SBOM-Prozess ist keine einmalige Maßnahme, sondern lässt sich in überschaubaren Schritten in die bestehende Entwicklung integrieren:

01

Bestand automatisiert aufnehmen

SBOMs bei jedem Build automatisch erzeugen und nicht von Hand pflegen. Ein manuell gepflegtes Inventar veraltet oft schon am Tag nach seiner Erstellung.
02

Kontinuierlich überwachen

SBOMs zentral sammeln und laufend gegen aktuelle Schwachstellendatenbanken abgleichen. So werden auch bereits ausgelieferte Versionen automatisch gegen neu bekannt gewordene Schwachstellen geprüft.
03

Mit Kontext priorisieren (VEX)

Nicht jede gefundene Schwachstelle ist in Ihrem Produkt tatsächlich ausnutzbar. Mit VEX (Vulnerability Exploitability eXchange) dokumentieren Sie nachvollziehbar, was wirklich relevant ist – und ersparen sich und Ihren Kunden Fehlalarme.[11]
04

Im Entwicklungsprozess verankern

SBOM-Erzeugung, Freigabe-Regeln und Signierung fest in die Build-Pipeline einbauen. So wird Compliance zum Nebenprodukt des normalen Entwickelns statt zum jährlichen Sonderprojekt.
05

Bereitstellen & nachweisen

Das SBOM als Teil der technischen Dokumentation vorhalten, es Kunden und Behörden auf Anfrage bereitstellen und über den gesamten Produktlebenszyklus aktuell halten.

Etablierte Werkzeuge in diesem Bereich sind unter anderem Syft, Grype, Trivy, cdxgen, OWASP Dependency-Track und Sigstore.

Foto von Johannes Hertenstein

Unterstützung durch Johannes Hertenstein

Software Developer & DevOps Engineer · j6s.dev

Johannes Hertenstein begleitet Software-Hersteller bei der Einführung tragfähiger SBOM-Prozesse – von der Integration in bestehende Build-Pipelines über die Auswahl der passenden Werkzeuge bis zur nachweisbaren CRA-Konformität. Als Software- und DevOps-Engineer verbindet er die regulatorische mit der praktischen Seite: Lösungen, die sich im Entwicklungsalltag tatsächlich umsetzen lassen.

Gespräch vereinbaren Mehr über Johannes
hello@j6s.dev +49 176 32283600 j6s.dev github.com/j6s

Quellen

Alle Aussagen auf dieser Seite stützen sich auf die folgenden Primärquellen und offiziellen Dokumente. Die Zahlen hinter den Nachweisen (^) führen zurück zur jeweiligen Textstelle.

  1. Synopsys, Inc.: 2024 Open Source Security and Risk Analysis Report (OSSRA) – Pressemitteilung „New Synopsys Report Finds 74% of Codebases Contained High-Risk Open Source Vulnerabilities". 27. Februar 2024. Laut Report enthielten 96 % der untersuchten Codebasen Open-Source-Code, der 77 % des gesamten gescannten Codes ausmachte. — news.synopsys.com ^^
  2. Europäisches Parlament und Rat der Europäischen Union: Verordnung (EU) 2024/2847 vom 23. Oktober 2024 über horizontale Cybersicherheitsanforderungen für Produkte mit digitalen Elementen (Cyber Resilience Act). Amtsblatt der EU, 20. November 2024. Insb. Art. 14 (Meldepflichten), Art. 64 (Sanktionen), Art. 71 (Geltungsbeginn) und Anhang I Teil 2 (SBOM-Pflicht). — eur-lex.europa.eu ^^^^^^^
  3. CISA, FBI, NSA u. a.: Cybersecurity Advisory AA21-356A – Mitigating Log4Shell and Other Log4j-Related Vulnerabilities (CVE-2021-44228). Zuletzt aktualisiert 2022. — cisa.gov ^
  4. Andres Freund: „backdoor in upstream xz/liblzma leading to ssh server compromise". Mailingliste oss-security, 29. März 2024 (Erstveröffentlichung der Entdeckung, CVE-2024-3094). — openwall.com ^
  5. CISA: Emergency Directive 21-01 – Mitigate SolarWinds Orion Code Compromise. 13. Dezember 2020. — cisa.gov ^
  6. National Telecommunications and Information Administration (NTIA): The Minimum Elements For a Software Bill of Materials (SBOM). 12. Juli 2021. Definiert das SBOM als „formal record containing the details and supply chain relationships of the various components used in building software", das Herstellern, Beschaffern und Betreibern Transparenz über die Software-Lieferkette verschafft. — ntia.gov ^
  7. International Organization for Standardization: ISO/IEC 5962:2021 – Information technology — SPDX® Specification V2.2.1. September 2021. — iso.org ^
  8. OWASP Foundation: OWASP CycloneDX – Bill of Materials Standard (veröffentlicht als Ecma-Standard ECMA-424). — owasp.org ^
  9. The White House: Executive Order 14028 – Improving the Nation's Cybersecurity. Veröffentlicht im Federal Register am 17. Mai 2021. — federalregister.gov ^^
  10. Europäisches Parlament und Rat der Europäischen Union: Richtlinie (EU) 2022/2555 vom 14. Dezember 2022 über Maßnahmen für ein hohes gemeinsames Cybersicherheitsniveau in der Union (NIS-2-Richtlinie). Amtsblatt der EU, 27. Dezember 2022. — eur-lex.europa.eu ^
  11. CISA: Minimum Requirements for Vulnerability Exploitability eXchange (VEX). April 2023. — cisa.gov ^