Cyber Resilience Act Schwachstellenmanagement: Ein Coordinated-Disclosure-Prozess für Anbieter
Die meisten Teams, die den Cyber Resilience Act verfolgen, haben Dezember 2027 im Kalender markiert. Das ist das falsche Datum, um sich zuerst Sorgen zu machen. Die CRA-Pflichten zu Schwachstellenmeldung und -offenlegung gelten ab dem 11. September 2026, was zum Zeitpunkt dieses Textes drei Monate entfernt ist. Ab diesem Tag muss jeder Hersteller eines Produkts mit digitalen Elementen auf dem EU-Markt aktiv ausgenutzte Schwachstellen innerhalb von 24 Stunden nach Kenntnisnahme an ENISA und sein nationales CSIRT melden. Noch ist keine CE-Kennzeichnung erforderlich. Keine Konformitätsbewertung. Nur ein funktionierender Prozess, ein Security-Kontakt und die Fähigkeit, schnell zu handeln, wenn ein Researcher oder ein Angreifer etwas findet.
Dieser Post ist ein praktischer Leitfaden für den Aufbau dieses Prozesses. Wenn du zuerst das große Ganze der Verordnung, den Scope und den CE-Kennzeichnungszeitplan verstehen willst, starte mit unserem Überblick zum Cyber Resilience Act und komm dann zurück.
Die September-2026-Deadline, die die meisten Anbieter ignorieren
Der CRA (Verordnung (EU) 2024/2847) wird über drei Jahre gestaffelt eingeführt. Die materiellen Produktanforderungen aus Anhang I Teil I, die grundlegenden Cybersicherheitsanforderungen, werden zusammen mit der CE-Kennzeichnung am 11. Dezember 2027 durchsetzbar. Aber Artikel 14, die Meldepflicht für aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle, gilt ab dem 11. September 2026.
Diese Reihenfolge ist beabsichtigt. Der Gesetzgeber wollte das Frühwarnsystem auf Ökosystem-Ebene laufen haben, bevor die Anforderungen auf Produktebene greifen. Die praktische Konsequenz für Anbieter: Die erste CRA-Pflicht, an der du tatsächlich scheitern kannst, ist keine fehlende CE-Kennzeichnung. Es ist eine verpasste Meldefrist, die in Stunden gemessen wird - mit Bußgeldern für Verstöße gegen Meldepflichten von bis zu 10 Millionen EUR oder 2 Prozent des weltweiten Jahresumsatzes.
Ein Prozess, den du in Panik nach deiner ersten ausgenutzten Schwachstelle entwirfst, wird eine 24-Stunden-Frist nicht einhalten. Einer, den du dieses Quartal entwirfst, schon.
Was CRA Schwachstellenmeldung tatsächlich verlangt
Anhang I Teil II des CRA listet die Anforderungen an die Schwachstellenbehandlung. Von juristischer Sprache befreit müssen Hersteller:
- Schwachstellen und Komponenten identifizieren und dokumentieren, einschließlich der Erstellung einer Software Bill of Materials (SBOM) in einem gebräuchlichen, maschinenlesbaren Format, die mindestens die Top-Level-Abhängigkeiten des Produkts abdeckt.
- Unverzüglich beheben und Sicherheitsupdates kostenlos ausliefern. Bei Consumer-Produkten müssen Updates, wo technisch machbar, von Feature-Updates trennbar sein, damit Nutzer nicht neue Funktionalität akzeptieren müssen, um einen Fix zu bekommen.
- Regelmäßig testen. Effektive und regelmäßige Tests und Reviews der Produktsicherheit sind eine Daueraufgabe, kein einmaliges Pre-Release-Gate.
- Behobene Schwachstellen öffentlich offenlegen, sobald ein Sicherheitsupdate verfügbar ist, einschließlich einer Beschreibung der Schwachstelle, ihrer Schwere und Hinweisen zur Behebung. Die Offenlegung darf nur verzögert werden, wenn das Sicherheitsrisiko der Veröffentlichung den Nutzen überwiegt.
- Eine Coordinated-Vulnerability-Disclosure-Policy (CVD) betreiben und eine Kontaktadresse bereitstellen, über die jeder, ob Researcher oder Kunde, Schwachstellen in deinem Produkt melden kann.
- Updates sicher verteilen und sicherstellen, dass die Verteilmechanismen die Integrität schützen, damit ein kompromittierter Update-Kanal nicht selbst zur Schwachstelle wird.
Nichts davon ist exotisch. Zusammen beschreiben diese Punkte, was reife Produktsicherheitsteams ohnehin tun. Der Unterschied: Ab 2027 sind es auditierbare gesetzliche Anforderungen, und die Meldeschicht darüber kommt schon 2026.
Die Meldeuhr: 24 Stunden, 72 Stunden, 14 Tage
Artikel 14 etabliert eine dreistufige Meldekaskade für jede aktiv ausgenutzte Schwachstelle in deinem Produkt:
| Stufe | Frist | Inhalt |
|---|---|---|
| Frühwarnung | 24 Stunden ab Kenntnisnahme | Dass eine Ausnutzung stattfindet; welche Mitgliedstaaten betroffen sind, falls bekannt |
| Schwachstellenmeldung | 72 Stunden ab Kenntnisnahme | Allgemeine Details, Schwere, Ausnutzungsstatus, verfügbare oder geplante Korrekturmaßnahmen |
| Abschlussbericht | 14 Tage nach Verfügbarkeit einer Korrekturmaßnahme | Beschreibung, Root Cause soweit verfügbar, Mitigation und Informationen zum Update |
Eine parallele Kaskade gilt für schwerwiegende Vorfälle mit Auswirkungen auf die Sicherheit des Produkts, mit dem Abschlussbericht einen Monat nach der Vorfallsmeldung. Meldungen laufen über die zentrale Meldeplattform von ENISA, die sie an das als Koordinator benannte CSIRT deines Mitgliedstaats weiterleitet. Für einen in Deutschland ansässigen Anbieter ist das das BSI.
Zwei Details bringen Teams ins Stolpern. Erstens: Die Uhr startet, wenn du Kenntnis erlangst, nicht wenn du mit der Untersuchung fertig bist. Die Frühwarnung darf dünn sein; genau das ist der Sinn. Zweitens: "Aktiv ausgenutzt" schließt die Ausnutzung deines Produkts bei einem einzelnen Kunden ein. Du brauchst Telemetrie oder Support-Eskalationspfade, die gut genug sind, dass Ausnutzungsberichte die Personen mit der Meldepflicht schnell erreichen.
Einen Coordinated-Disclosure-Prozess bauen, der standhält
Ein CVD-Prozess, der den CRA erfüllt, hat vier Teile. Die meisten Anbieter können alle vier in einem Quartal aufsetzen.
1. Policy und Kontakt veröffentlichen
Schreibe eine CVD-Policy und platziere sie dort, wo Researcher suchen: eine /.well-known/security.txt-Datei, eine Security-Seite auf deiner Website und eine SECURITY.md in jedem öffentlichen Repository. Die Policy sollte festhalten, was im Scope ist, wie gemeldet wird (eine dedizierte Mailbox wie security@ deiner Domain oder ein Formular), was Melder von dir wann erwarten können, und dass du gegen gutgläubige Forschung nicht rechtlich vorgehst. Verpflichte dich auf eine Bestätigungsfrist, die du tatsächlich einhalten kannst; 48 Stunden sind eine übliche und vertretbare Wahl.
2. Intake und Triage
Jede Meldung braucht innerhalb eines Werktags einen Owner. Definiere eine Triage-Rotation, ein Schweregrad-Schema (CVSS ist der De-facto-Standard und passt sauber auf die Schweregrad-Sprache des CRA) und eine kritische Verzweigungsfrage: Gibt es Hinweise auf aktive Ausnutzung? Wenn ja, läuft die Artikel-14-Uhr, und die Meldung eskaliert sofort an die Person, die ENISA-Meldungen einreicht. Diese Person und ihre Vertretung sollten im Prozessdokument namentlich stehen und nicht während des Vorfalls gesucht werden.
3. Remediation-SLAs
Anhang I sagt "unverzüglich", was Auditoren und benannte Stellen an deinen eigenen dokumentierten Zielen messen werden. Typische vertretbare SLAs sind 14 Tage für Critical, 30 für High, 90 für Medium und Low. Wichtiger als die exakten Zahlen ist, dass du sie trackst und die Historie vorzeigen kannst. Wenn deine Codebasis einen 14-Tage-Turnaround für einen kritischen Fix unrealistisch macht, ist das ein Engineering-Problem im Kostüm eines Compliance-Problems - und einen ehrlichen Blick auf Code-Qualität und Architektur wert, lieber vor September als danach.
4. Advisories und Disclosure-Timing
Sobald der Fix ausgeliefert ist, veröffentliche ein Advisory: betroffene Versionen, Schweregrad, die Fix-Version und Workarounds, falls das Update schwerfällt. Stimme das Timing mit dem Melder ab; 90 Tage von Meldung bis Veröffentlichung sind die Konvention, die Researcher erwarten. Wenn dein Produkt eine Komponente ist, auf der andere Hersteller aufbauen, informiere Downstream-Integratoren vor der öffentlichen Offenlegung, denn unter dem CRA haben sie eigene Pflichten, die durch deine ausgelöst werden.
SBOM: Die Voraussetzung, die alles andere möglich macht
Jeder Schritt oben wird mit einer akkuraten SBOM schneller und ohne sie nahezu unmöglich. Wenn die nächste Offenlegung der Log4Shell-Klasse einschlägt, muss "Sind wir betroffen?" eine Query sein, kein Archäologieprojekt. Generiere SBOMs im CycloneDX- oder SPDX-Format als Teil der CI bei jedem Release, speichere sie pro veröffentlichter Version und verdrahte Dependency-Scanning mit ihnen, sodass neue CVEs in ausgelieferten Versionen automatisch Alerts auslösen. Der CRA verlangt nur die Abdeckung der Top-Level-Abhängigkeiten, aber transitive Abdeckung ist das, was die Frage tatsächlich beantwortet, und die Tooling-Kosten dafür liegen nahe null.
Was das für SaaS-Teams bedeutet
Reines SaaS ist überwiegend NIS2-Territorium, aber CRA-Compliance für SaaS-Anbieter wird in dem Moment real, in dem du etwas Installierbares auslieferst: einen Desktop-Agent, eine Mobile App, ein CLI, ein SDK, eine Self-Hosted-Edition. Diese Artefakte sind Produkte mit digitalen Elementen, und ihre Schwachstellenbehandlung fällt unter den CRA, auch wenn dein Cloud-Backend es nicht tut. Der pragmatische Schritt ist ein einziger CVD-Prozess für alles, was du auslieferst, Cloud und Installierbares gleichermaßen. Ein Intake, ein Schweregrad-Schema, ein Advisory-Format. Prozesse nach Regulierung aufzuteilen multipliziert die Wahrscheinlichkeit, dass die eine Meldung, auf die es ankam, in der falschen Queue landet.
Wenn du gerade neue installierbare Komponenten baust, designe Update-Kanal, SBOM-Generierung und Telemetrie-Hooks von Anfang an ein. Sie nachzurüsten ist genau die Art von Arbeit, die gegen Feature-Druck schlecht konkurriert, und genau dort verdient ein erfahrener Entwicklungspartner sein Geld.
Ein 90-Tage-Plan, um bis September bereit zu sein
- Wochen 1 bis 2: Benenne Prozess-Owner und Vertretung. Registriere dich für den Meldeweg der ENISA-Plattform über dein nationales CSIRT. Richte security@ und
security.txtein. - Wochen 3 bis 6: Schreibe und veröffentliche die CVD-Policy. Definiere Schweregrad-Schema, Triage-Rotation und Remediation-SLAs. Ergänze SBOM-Generierung in der CI.
- Wochen 7 bis 10: Verdrahte Ausnutzungssignale: Support-Eskalations-Keywords, Crash- und Auth-Anomalie-Alerts, Researcher-Intake. Entwirf Advisory- und ENISA-Meldevorlagen, damit in Stunde 20 niemand vor einem leeren Blatt sitzt.
- Wochen 11 bis 13: Führe eine Tabletop-Übung durch: Ein Researcher meldet an einem Freitagabend einen aktiv ausgenutzten Deserialisierungs-Bug. Gehe die komplette Kette von Intake über die 24-Stunden-Frühwarnung bis zum Advisory durch. Repariere, was bricht.
FAQ
Gelten die September-2026-Pflichten für Produkte, die vor diesem Datum ausgeliefert wurden? Ja, für die Meldepflicht. Artikel 14 gilt für aktiv ausgenutzte Schwachstellen in Produkten, die du auf dem Markt hast, unabhängig davon, wann sie dort platziert wurden.
Löst eine Schwachstelle in einer Open-Source-Abhängigkeit eine Meldung aus? Nur wenn sie in deinem Produkt aktiv ausgenutzt wird. Aber deine Anhang-I-Pflichten ab 2027 verlangen trotzdem eine unverzügliche Behebung - genau deshalb ist die SBOM-Pipeline jetzt wichtig.
Können wir den Prozess auslagern? Du kannst Intake und Triage an eine Plattform oder einen Partner auslagern, aber die rechtliche Pflicht und die Meldefristen bleiben beim Hersteller.
Wolf-Tech hilft SaaS-Anbietern und Software-Teams, audit-ready zu werden: Schwachstellenbehandlungsprozesse, SBOM-Pipelines und die Fixes auf Code-Ebene, die 14-Tage-Remediation-SLAs erreichbar machen. Wenn die September-Deadline näher ist als deine Prozessreife, schreib an hello@wolf-tech.io oder besuche wolf-tech.io für ein erstes Gespräch.