CRA Preparations: Was Software-Hersteller noch tun müssen, bevor der CRA greift

Die Uhr tickt – Warum der CRA kein regulatorisches Hintergrundrauschen ist

Ich erlebe es regelmäßig in Gesprächen mit Sicherheitsverantwortlichen: Der Cyber Resilience Act wird erwähnt, genickt wird pflichtbewusst, und dann kehrt man zur Tagesordnung zurück. Das ist ein Fehler, den sich Softwarehersteller schlicht nicht leisten können.

Der CRA wurde im Oktober 2024 im Amtsblatt der EU veröffentlicht. Die Übergangsfristen sind definiert: Melde- und Überwachungspflichten gelten ab September 2026 – das sind jetzt noch D R E I Monate – die vollständigen Anforderungen ab Dezember 2027. Das klingt nach Spielraum. Ist es aber nicht — denn wer heute noch keine strukturierte Inventarisierung seiner Software-Komponenten betreibt, hat schlicht zu spät angefangen.

Die Bußgeldrahmen sprechen eine klare Sprache: bis zu 15 Millionen Euro oder 2,5 % des weltweiten Jahresumsatzes bei Verstößen gegen die wesentlichen Anforderungen. Bei wiederholtem Verstoß, kann es zum Marktausschluss führen. Zum Vergleich: Die DSGVO-Bußgelder, die Unternehmen jahrelang als abstrakte Bedrohung behandelten, haben sich inzwischen in der Realität materialisiert. Wer glaubt, der CRA verlaufe ähnlich folgenlos, sollte sich die Konsequenzen zweimal überlegen.

Was der CRA konkret fordert – Ein nüchterner Blick auf die Pflichten

Der CRA adressiert Hersteller von Products with Digital Elements, also im Wesentlichen jede Software und jedes hardwarenahe Produkt, das in vernetzten Umgebungen betrieben wird. Die Anforderungen lassen sich auf einige Kernpunkte verdichten:

• Security by Design: Sicherheit muss von Anfang an im Entwicklungsprozess verankert sein, nicht nachträglich aufgesetzt
• Schwachstellenmanagement: Hersteller müssen Schwachstellen über den gesamten Produktlebenszyklus aktiv identifizieren und beheben
• Sichere Standardkonfigurationen: Produkte dürfen nicht mit unsicheren Werkseinstellungen ausgeliefert werden
• Transparenzpflichten: Gegenüber Behörden und Nutzern müssen Sicherheitseigenschaften nachvollziehbar dokumentiert werden

Die SBOM — Software Bill of Materials — ist im CRA-Text nicht explizit vorgeschrieben. In der Praxis ist diese Unterscheidung jedoch akademisch. Ohne maschinenlesbare Komponentenliste lässt sich kein glaubwürdiger Nachweis führen, dass man tatsächlich weiß, was im eigenen Produkt steckt.
Wer sich noch nicht sicher ist, wo das eigene Unternehmen in Bezug auf CRA-Compliance steht, kann sich mit dem kostenlosen Tool unter cra-support.eacg.de durch einen strukturierten Fragebogen führen lassen. Die Firmen EACG und metaeffekt haben dort ihre Best Practices aus der MetaTrust-Methode in eine frei zugängliche Online-Lösung überführt — das Ergebnis ist eine priorisierte Aufgabenliste, die konkrete nächste Schritte liefert.

SBOM als Fundament – Warum ohne Komponententransparenz nichts geht

Eine vollständige, maschinenlesbare SBOM ist nicht Mittel zum Zweck — sie ist die Grundvoraussetzung dafür, überhaupt handlungsfähig zu sein. Wer nicht weiß, welche Open-Source-Bibliotheken, Transitivabhängigkeiten und Lizenzmodelle in seinen Produkten stecken, kann weder Schwachstellen systematisch adressieren noch behördliche Nachweispflichten erfüllen.

Bei der Formatfrage steht die Branche vor einer strategischen Entscheidung: CycloneDX oder SPDX? Beide Formate sind etabliert, beide werden von gängigen Tools unterstützt. Im CRA-Kontext hat CycloneDX jedoch einen pragmatischen Vorteil: Es wurde explizit für Security-Anwendungsfälle entwickelt, unterstützt VEX-Dokumente nativ und bildet Schwachstelleninformationen strukturierter ab. SPDX hingegen dominiert traditionell den Lizenz-Compliance-Bereich und ist als ISO-Standard (ISO 5962) formal breiter anerkannt. Die Entscheidung hängt vom primären Verwendungszweck ab — für Organisationen, die beides brauchen, bieten reife Plattformen heute Konvertierung zwischen den Formaten an.

Entscheidend ist aber ein anderer Punkt: Die SBOM darf kein einmaliges Audit-Artefakt sein. Sie muss kontinuierlich im CI/CD-Prozess generiert werden. Jeder Build, jede Abhängigkeitsänderung, jedes neue Release — der SBOM-Stand muss aktuell sein. Wer das als nachgelagerten Schritt behandelt, produziert Dokumente, die im Ernstfall nicht die Realität abbilden.

Software Composition Analysis – Schwachstellen finden, bevor andere es tun

SCA-Tools scannen Abhängigkeiten gegen bekannte Schwachstellendatenbanken — NVD, OSV, GitHub Advisory Database. Das ist unter dem CRA keine optionale Hygienemaßnahme mehr, sondern regulatorische Pflicht. Die Herausforderung liegt dabei weniger in der Technologie als in der Handhabbarkeit der Ergebnisse.

Wer schon einmal einen rohen CVE-Report eines größeren Projekts gesehen hat, weiß: Die Liste ist lang, und viele der gemeldeten Schwachstellen betreffen Code, der im konkreten Produktkontext gar nicht erreichbar ist. Ohne Reachability-Analyse überlasten solche Berichte Sicherheitsteams mit False Positives und lähmen die Priorisierung. Moderne SCA-Werkzeuge, die kontextsensitiv analysieren — also tatsächlich prüfen, ob verwundbare Codesegmente im Aufrufpfad liegen — reduzieren dieses Rauschen erheblich.

Noch wichtiger als die Erkennung ist aber der Prozess dahinter: SCA-Ergebnisse müssen in ein nachvollziehbares Risikomanagement münden. Ein Remediation-Prozess mit klarem Audit-Trail ist nicht nur für interne Steuerung relevant — er ist der Nachweis gegenüber Behörden, dass Schwachstellen systematisch und nicht ad hoc bearbeitet werden.

Vulnerability Disclosure und Meldepflichten – Der CRA schreibt Tempo vor

Hier wird es für viele Organisationen unbequem. Aktiv ausgenutzte Schwachstellen müssen innerhalb von 24 Stunden an ENISA gemeldet werden. Nicht 48 Stunden, nicht "zeitnah" — 24 Stunden. Ein solches Zeitfenster ist ohne automatisierte Monitoring-Infrastruktur schlicht nicht einzuhalten, wenn gleichzeitig noch Einschätzung, Klassifizierung und interne Eskalation stattfinden müssen.

Das bedeutet: Hersteller brauchen heute definierte Coordinated Vulnerability Disclosure (CVD)-Prozesse, die sowohl CRA-Anforderungen als auch bestehenden Standards wie ISO/IEC 29147 genügen. Das ist keine Frage von Werkzeugen allein — es ist eine organisatorische Frage, die Rollen, Eskalationspfade und Kommunikationskanäle klärt. Das Carnegie Mellon CERT hat entsprechende Best Practises im “Vultron”-Protokoll definiert. EACG hat diese in TrustSource implementiert.

VEX-Dokumente (Vulnerability Exploitability eXchange) sollen dabei die Kommunikation gegenüber Kunden und Behörden standardisieren: Ist eine bekannte Schwachstelle im eigenen Produkt tatsächlich ausnutzbar? Unter welchen Bedingungen? Wann ist ein Fix verfügbar? In der Theorie ist das ein elegantes Instrument. In der gelebten Praxis klaffen Anspruch und Realität noch weit auseinander — zu wenige Hersteller erstellen VEX-Dokumente systematisch, zu wenige Abnehmer wissen damit umzugehen. Für die Verteilung ist der Betrieb eines CSAF-Providers, der vom BSI-Lister erfasst wird, eine ideale Voraussetzung.

License Compliance im CRA-Kontext – Der unterschätzte Risikofaktor

Neben den Sicherheitsanforderungen lauert ein zweiter Risikofaktor, den Compliance-Teams häufig unterschätzen: Open-Source-Lizenzen. GPL, LGPL, AGPL — diese Lizenzen können bei kommerziellen Produkten Pflichten auslösen, die über den CRA hinausgehen. Eine AGPL-lizenzierte Komponente in einem SaaS-Produkt kann etwa Copyleft-Pflichten auslösen, die den gesamten Quellcode betreffen. Das ist kein theoretisches Szenario — es ist ein reales Risiko, das bei fehlender Inventarisierung unbemerkt in Produkte einzieht.

Automatisierte Lizenzerkennung und Policy-Enforcement im Build-Prozess sind hier der einzig praktikable Ansatz. Manuelle Audits skalieren nicht, wenn Abhängigkeitsbäume hunderte von Komponenten umfassen.

Der strategische Vorteil: SBOM-Daten dienen gleichzeitig als Basis für License-Audits. Ein Artefakt, zwei regulatorische Zwecke. Wer seine SBOM-Infrastruktur einmal sauber aufgebaut hat, vermeidet Doppelarbeit zwischen Sicherheits- und Rechtsabteilung.

Handlungsempfehlungen – Was Teams jetzt konkret tun können

Die verbleibende Zeit bis September 2026 klingt nach ausreichend Puffer. Sie ist es nicht, wenn man die Vorlaufzeiten für Prozessänderungen, Tool-Implementierungen und organisatorische Anpassungen realistisch einkalkuliert. Meine Empfehlung für Sofortmaßnahmen:

• SBOM-Generierung anstoßen: Für alle aktiven Produkte, automatisiert im CI/CD, heute — nicht nach dem nächsten Planungszyklus
• SCA in bestehende Pipelines integrieren: Mit Priorisierungslogik, nicht als rohe CVE-Dump-Lösung
• Meldeprozesse für Schwachstellen definieren: Klare Rollen, definierte Eskalationspfade, Zeitfenster eingeübt
• Lizenzchecks automatisieren: Policy-Regeln im Build-Prozess verankern, nicht als nachgelagerten Audit

Wer diese Prozesse nicht mit vielen, separaten Werkzeugen koordinieren möchte, findet in Plattformen wie TrustSource einen integrierten Ansatz für SBOM-Management, Software Composition Analysis und License Compliance. Das reduziert nicht nur Werkzeugkomplexität, sondern schafft auch die Datengrundlage für konsistente Nachweise gegenüber Behörden.

Der CRA ist kein Endpunkt regulatorischer Anforderungen — er ist deren Ausgangslage. Organisationen, die jetzt in eine belastbare Supply-Chain-Security-Infrastruktur investieren, bauen etwas auf, das auch künftige Anforderungen trägt. Wer wartet, kauft sich nur Zeit — und zahlt sie teuer.

Zur Person

Freier Tech-Journalist, promovierter Wirtschaftsinformatiker. Recherchiert zu Software Supply Chain Security und SBOM-Adoption.

Gastbeitrag. Dr. Brenner ist freier Journalist. Keine Vergütung für diesen Beitrag.