EU CRA: Rückverfolgbarkeit von Codes und Schwachstellenmanagement als gesetzliche Vorschrift
EU-Gesetz zur Cyber-Resilienz: Softwaresicherheit ist nun eine gesetzliche Verpflichtung mit CE-Kennzeichnung
Die Verordnung (EU) 2024/2847 macht Cybersicherheit zu einer Marktzulassungsvoraussetzung für alle Produkte mit digitalen Komponenten in der EU. Die Rückverfolgbarkeit des Codes, das Schwachstellenmanagement und eine überprüfbare SBOM sind nun nicht mehr nur bewährte Praktiken, sondern werden zu gesetzlichen Verpflichtungen.
Kernpunkte
- Die am 23. Oktober 2024 veröffentlichte EU-CRA (Verordnung (EU) 2024/2847) legt verbindliche Cybersicherheitsanforderungen für alle in der EU in Verkehr gebrachten Produkte mit digitalen Komponenten fest.
- Die Meldepflichten für aktiv ausgenutzte Sicherheitslücken (Art. 14) gelten ab dem 11. September 2026 – dem ersten Stichtag für Softwarehersteller.
- Die vollständige Umsetzung der Verordnung, einschließlich der CE-Kennzeichnung für Cybersicherheit, tritt am 11. Dezember 2027 in Kraft.
- Gemäß § 13 sind die Hersteller verpflichtet, ihren Secure Development Lifecycle (SDL) zu dokumentieren und nachzuweisen – vom Entwurf bis zum Ende der Lebensdauer des Produkts.
- Artikel 16 führt die Software-Stückliste (SBOM) als Verpflichtung ein: eine überprüfbare Liste aller Softwarekomponenten des Produkts.
- V-PROOF erstellt die kryptografische Nachverfolgungskette von Commit zu Commit – die technische Grundlage für die gleichzeitige Erfüllung der §§ 13, 14 und 16.
EU CRA: Wenn „Secure by Design“ kein Slogan mehr ist, sondern Gesetz wird
Seit Jahrzehnten arbeitet die Softwarebranche nach einem stillschweigenden Grundsatz: Cybersicherheit ist ein optionales Merkmal, das nur dann hinzugefügt wird, wenn der Markt dies verlangt. Der EU-Cyber-Resilience-Act macht diesem Modell ein Ende. Ab Dezember 2027 darf kein Produkt mit digitalen Komponenten in der EU in Verkehr gebracht werden, ohne dass nachgewiesen wird, dass es die Sicherheitsanforderungen gemäß Anhang I der Verordnung erfüllt.
Die am 23. Oktober 2024 im Amtsblatt der EU veröffentlichte Verordnung (EU) 2024/2847 betrifft alle Hardware- und Softwareprodukte, die „digitale Elemente“ enthalten – eine bewusst weit gefasste Definition, die von industriellen IoT-Geräten bis hin zu mobilen Anwendungen, von Zugangskontrollsystemen bis hin zu Unternehmensverwaltungssoftware reicht. Ausdrücklich ausgenommen sind lediglich Produkte, die bereits unter spezifische sektorale Vorschriften fallen (Medizinprodukte, Fahrzeuge, Luftfahrt), sowie reine Software-as-a-Service-Lösungen, bei denen keine Komponenten auf das Gerät des Nutzers heruntergeladen werden.
Der Paradigmenwechsel bei der EU-CRA
Die EU-CRA verlagert die Verantwortung für die Cybersicherheit vom Endnutzer auf den Hersteller. Bislang „akzeptierte“ der Nutzer bei der Installation eines Produkts das Risiko, falls die Software Schwachstellen aufwies. Mit der CRA ist der Hersteller für die Sicherheit des Produkts während seines gesamten Lebenszyklus verantwortlich, einschließlich des Managements von Schwachstellen nach der Markteinführung für mindestens fünf Jahre oder für die Dauer der vorgesehenen Nutzung, falls diese länger ist.
Die Sanktionen bei Verstößen sind erheblich: bis zu 15 Millionen Euro oder 2,5 % des weltweiten Jahresumsatzes bei Verstößen gegen die wesentlichen Cybersicherheitsanforderungen gemäß Anhang I sowie bis zu 10 Millionen Euro oder 2 % bei Verstößen gegen andere Verpflichtungen wie die Meldung von Sicherheitslücken. Die nationalen Marktüberwachungsbehörden sind in den einzelnen Mitgliedstaaten für die Überwachung zuständig.
Drei Kategorien, drei Schwierigkeitsgrade
Die EU-CRA stuft Produkte je nach ihrem Cybersicherheitsrisiko in drei Kategorien ein. Die Kategorie bestimmt das Konformitätsbewertungsverfahren, das für die Erlangung der CE-Kennzeichnung erforderlich ist:
Die Termine, die die Produktteams in ihrer Roadmap berücksichtigen müssen
Warum jetzt anfangen und nicht erst 2027?
Die EU-CRA verlangt von den Herstellern den Nachweis eines „Secure Development Lifecycle“ – eines sicheren Entwicklungsprozesses – und nicht nur, dass das Endprodukt bestimmte Anforderungen erfüllt. Ein Prozess hat eine Historie. Bei Konformitätsprüfungen wird rückblickend vorgegangen: Ein Hersteller, der im Zeitraum 2024–2026 damit beginnt, seinen Entwicklungsprozess kryptografisch zu sichern, verfügt zum Zeitpunkt der Bewertung über zwei oder drei Jahre nachweisbare Historie. Ein Hersteller, der erst im Dezember 2027 damit beginnt, hat keine nachweisbare Historie.
Artikel, für die technische Nachweise erforderlich sind – und welche Nachweise V-PROOF jeden einzelnen davon erstellt
V-PROOF -Abdeckung V-PROOF EU-CRA-Vorschrift
| EU-CRA-Verpflichtung | Voraussetzung | Reichweite | V-PROOF-Modul |
|---|---|---|---|
| § 13 – Sicherer Entwicklungslebenszyklus | |||
| Art. 13 Abs. 1SDL, dokumentiert | Nachweisbare Dokumentation des sicheren Entwicklungsprozesses vom Entwurf bis zur Bereitstellung | ✓ Abgeschlossen | Git-Integration |
| § 13 Abs. 3Patch-Management | Nachverfolgbarkeit der Installation von Sicherheitspatches: wann, welche Version, wer hat sie genehmigt | ✓ Abgeschlossen | Git-Integration |
| § 13 Abs. 6Technische Unterlagen | Aktuelle und überprüfbare technische Unterlagen zur Konformitätsbewertung | ✓ Abgeschlossen | V-Seal Git-Integration |
| § 14 – Meldung von Sicherheitslücken und Vorfällen | |||
| § 14 Abs. 1 Nr.24h – ENISA-Warnung | Protokoll mit timestamp genauen Zeitpunkt der Entdeckung der ausgenutzten Sicherheitslücke timestamp | ✓ Abgeschlossen | V-Seal |
| § 14 Abs. 2 Nr.72h – Mitteilung | Protokoll der Maßnahmen von der Entdeckung bis zur formellen Benachrichtigung | ✓ Abgeschlossen | V-Seal |
| § 14 Abs. 7:Mitteilung an die ENISA | Die formelle Meldung an die ENISA obliegt dem Hersteller | — Haftung des Herstellers | Regulierungsverfahren |
| § 16 – Software-Stückliste (SBOM) | |||
| Art.16SBOM – überprüfbar | Vollständige und überprüfbare Liste der Softwarekomponenten, einschließlich Abhängigkeiten von Drittanbietern und Open-Source-Komponenten | ✓ Abgeschlossen | Git-Integration |
| Anhang I – Grundlegende Anforderungen an die Cybersicherheit | |||
| Anhang I – TeilI: Produktanforderungen | Nachweis über die Umsetzung jeder im Produktdesign geforderten Sicherheitsmaßnahme | ✓ Abgeschlossen | V-Seal |
| Anhang I – TeilII: Schwachstellenmanagement | Nachvollziehbarer Prozess zur Erkennung, Analyse und Behebung von Schwachstellen während des Lebenszyklus | ✓ Abgeschlossen | Git-Integration V-Seal |
| Konvergenz von EU-CRA und EU AI Act Für Software mit KI-Komponenten | |||
| EU-CRA Art. 13+ EU AI Act . 12 | Rückverfolgbarkeit des Lebenszyklus von in Softwareprodukte integrierten KI-Modellen: Versionen, Training, Bereitstellung | ✓ Abgeschlossen | AI Orchestrator Git-Integration |
EU-CRA + EU AI Act: Die doppelte Verpflichtung für Software mit integrierter KI
Jedes Softwareprodukt, das KI-Komponenten enthält, unterliegt gleichzeitig dem EU-CRA und dem EU AI Act. Aus dieser Überschneidung ergeben sich zusätzliche Verpflichtungen, die keiner der beiden Rechtsrahmen für sich allein abdeckt.
Ein auf maschinellem Lernen basierendes System zur Erkennung von Anomalien, das in eine Cybersicherheitssoftware integriert ist, ein KI-gestützter Code-Assistent, ein Sicherheitsempfehlungssystem auf einer SaaS-Plattform – all dies sind KI-Systeme im Sinne des EU AI Act Produkte mit digitalen Elementen im Sinne des EU-CRA. Der Hersteller muss mit ein und demselben Produkt sowohl die Anforderungen an die Rückverfolgbarkeit des Software-Lebenszyklus (EU-CRA Art. 13) als auch die Anforderungen an die Protokollierung von Ereignissen und die menschliche Überwachung des KI-Systems (EU AI Act . 12 und 14) erfüllen.
V-PROOF die Schnittstelle mit einer einzigen Integration V-PROOF
Das Modul „AI Orchestrator“ von V-PROOF kryptografisch den gesamten Lebenszyklus der in das Produkt integrierten KI-Modelle: Trainingsdatensätze, Modellversionen, Bewertungskennzahlen und jede einzelne Entscheidung im Produktivbetrieb. Das Modul „Git Integration“ protokolliert den Code, mit dem diese Modelle implementiert werden. Zusammen erfüllen sie die Nachverfolgbarkeitsanforderungen der EU-CRA (Art. 13) und des EU AI Act Art. 12, 16), ohne dass es zu einer doppelten Integration kommt.
Die EU-CRA und die Sicherheit der Software-Lieferkette
Das EU CRA führt ein Konzept ein, das die Art und Weise verändert, wie Entwicklungsteams über ihre Abhängigkeiten nachdenken müssen: die Verantwortung in der Software-Lieferkette. Hersteller sind für die Sicherheitslücken in den Komponenten von Drittanbietern verantwortlich, die sie in ihre Produkte integrieren – einschließlich Open-Source-Bibliotheken.
Diese Verantwortung erstreckt sich auch auf die Anbieter von Entwicklungstools, die der Hersteller in seinem SDL-Prozess einsetzt. Ein Hersteller, der eine in den USA ansässige CI/CD- oder Code-Management-Plattform zur Verwaltung seines sicheren Entwicklungsprozesses nutzt, führt damit eine Komponente in seine Lieferkette ein, die dem CLOUD Act unterliegt. Wenn die US-Behörden Zugriff auf die Entwicklungshistorie des Produkts verlangen – einschließlich der Aufzeichnungen über entdeckte Sicherheitslücken und deren Behebungszeiträume –, kann dieser Anbieter die Vertraulichkeit nicht gewährleisten.
V-PROOF Integration gewährleistet die Rückverfolgbarkeit des Codes mit rechtlichem Sitz in Spanien. Die SDL-Protokolle sind souverän: Die kryptografische Nachverfolgungskette des Entwicklungsprozesses unterliegt weiterhin der Gerichtsbarkeit der EU.
V-PROOF der EU-CRA
Stärken, Anwendungsfälle im regulatorischen Bereich und Grenzen des Anwendungsbereichs
- Kryptografische Nachverfolgungskette von Commit zu Commit – die in Art. 13 geforderte dokumentierte und überprüfbare SDL, die im Rahmen der normalen Entwicklung aufgebaut wird Art. 13 – Überprüfbarer SDL
- Timestamp zum genauen Zeitpunkt der Entdeckung jeder Schwachstelle – unerlässlich zum Nachweis der Einhaltung der 24-Stunden-Frist gemäß Art. 14 Art. 14 – Meldung von Sicherheitslücken
- Rückverfolgbarkeit von Abhängigkeiten und Komponenten von Drittanbietern von Commit zu Commit – die technische Grundlage für die Erstellung und Überprüfung der SBOM gemäß Art. 16 Art. 16 – SBOM
- Nachweisbare Umsetzung der Kontrollmaßnahmen gemäß Anhang I – Nachweise für die technische Dokumentation zur Konformitätsbewertung und zur CE-Kennzeichnung Anhang I – Grundlegende Anforderungen
- Doppelte Abdeckung durch die EU-CRA und EU AI Act Software mit integrierten KI-Komponenten – eine einzige Integration für zwei Rechtsrahmen Regulatorische Konvergenz 2026–2027
- Anbieter mit satzungsmäßigem Sitz in Spanien: Der bei V-PROOF registrierte SDL-Prozess unterliegt V-PROOF dem US-amerikanischen CLOUD Act Souveränität der Lieferkette
- ISVs (Independent Software Vendors), die Software in der EU vertreiben und ihren SDL bis Dezember 2027 dokumentieren müssen Art. 13 – Softwarehersteller
- Hersteller von industriellen und Verbraucher-IoT-Geräten mit integrierter Software – insbesondere der Klassen I und II, für die strengere Prüfungsanforderungen gelten Klasse I–II – kritische Produkte
- DevSecOps-Teams, die ihre CI/CD-Pipeline kryptografisch versiegeln müssen, um den sicheren Entwicklungsprozess nachzuweisen § 13 – CI/CD-Pipeline
- CISOs, die die technischen Unterlagen für Konformitätsbewertungen der Klassen I und II so früh wie möglich vorbereiten §§ 24–32 — Konformitätsbewertung
- Softwarehersteller mit integrierter KI, die den doppelten Verpflichtungen gemäß EU CRA und EU AI Act unterliegen EU AI Act eine einheitliche Infrastruktur zur Rückverfolgbarkeit anstreben Konvergenz von EU-CRA und EU AI Act
- Die Gestaltung der Sicherheitsarchitektur des Produkts: V-PROOF , dass der Implementierungsprozess ordnungsgemäß durchgeführt wurde, gestaltet jedoch nicht die Sicherheitsarchitektur. Produktdesign
- Penetrationstests und Sicherheitstests (Anhang I): V-PROOF die Testergebnisse, führt die Tests jedoch nicht selbst durch. Die Tests werden vom Sicherheitsteam oder einem spezialisierten Drittanbieter durchgeführt. Anhang I – Sicherheitstests
- Die formelle Meldung von Sicherheitslücken an die ENISA (Art. 14): V-PROOF eine unveränderliche Aufzeichnung der Entdeckung; die formelle Meldung an die Aufsichtsbehörde obliegt dem Hersteller. Art. 14 – Meldung an die ENISA
- Die CE-Kennzeichnung (Art. 47): Erfordert eine Konformitätsbewertung durch eine benannte Stelle für die Klassen I und II. V-PROOF die technischen Nachweise, die diese Bewertung erleichtern, erteilt sie jedoch nicht. Art. 47 – CE-Kennzeichnung
Verfügt Ihr Entwicklungsteam über die dokumentierte SDL, die die CRA-Konformitätsprüfer verlangen werden?
V-PROOF eine strategische 48-Stunden-Analyse, die die für Ihre Produkte geltenden EU-CRA-Anforderungen aufzeigt, bestehende Lücken bei der Code-Rückverfolgbarkeit identifiziert und die erforderliche Git-Integration definiert.
Strategische Diagnose bei EU CRA anfordernQuellen und rechtliche Verweise
- Verordnung (EU) 2024/2847 des Europäischen Parlaments und des Rates vom 23. Oktober 2024 – EUR-Lex CELEX:32024R2847
- ENISA – Leitfaden zur Umsetzung der EU-CRA, 2025 – enisa.europa.eu
- Europäische Kommission – Häufig gestellte Fragen zum EU CRA – digital-strategy.ec.europa.eu
- CEN/CENELEC – Normungsauftrag für die EU-CRA (harmonisierte technische Normen) – cencenelec.eu
- BSI (Bundesamt für Sicherheit in der Informationstechnik) – EU-CRA-Leitfaden für Hersteller, 2025 – bsi.bund.de
- Verordnung (EU) 2024/1689 (EU AI Act) – Konvergenzhinweis zur EU-CRA für KI-Software – EUR-Lex
