/cra-schwachstellenmanagement

name: cra-schwachstellenmanagement
description: "Aufbau und Prüfung des Schwachstellenmanagements nach Anhang I Teil II VO (EU) 2024/2847 – Politik zur koordinierten Schwachstellenoffenlegung (CVD-Policy), Kontaktstelle und Eingangskanäle für Meldungen, Triage und Bewertung, Behebung durch Sicherheitsupdates, sichere Update-Verteilung mit Signatur, öffentliche Offenlegung behobener Schwachstellen und Security Advisories, Koordinierung mit CSIRT, BSI und CVE-Vergabe sowie die Schnittstellen zur Meldepflicht nach Art. 14 CRA, zu NIS2 und zur reformierten Produkthaftung ab dem 09.12.2026. Use when ein Hersteller eine CVD-Policy einführen, seinen Schwachstellenprozess CRA-fest machen oder eine eingehende Schwachstellenmeldung eines Sicherheitsforschers rechtlich und prozessual behandeln muss."
language: de
provider_variants: [claude, gemini, openai]
test: ./test.md

/cyber-resilience-act:cra-schwachstellenmanagement

Zweck

**Anhang I Teil II** des Cyber Resilience Act ([VO (EU) 2024/2847](https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX:32024R2847)) verlangt vom Hersteller ein funktionierendes Schwachstellenmanagement über den gesamten **Unterstützungszeitraum**: Schwachstellen finden, dokumentieren, unverzüglich beheben, Updates sicher verteilen, behobene Schwachstellen offenlegen und eine **Politik zur koordinierten Schwachstellenoffenlegung (CVD-Policy)** durchsetzen. Dieser Prozess ist zugleich das Nervensystem der Meldepflicht: Ohne ihn wird eine aktiv ausgenutzte Schwachstelle nicht rechtzeitig erkannt, und die 24-Stunden-Frist des Art. 14 CRA ist strukturell nicht einzuhalten.

> **⚠️ Aktualität (Stand 2026-07):** Die Verordnung ist am **10.12.2024 in Kraft** getreten. Ab dem **11.09.2026** greifen die **Meldepflichten** nach Art. 14 CRA; die Anforderungen des Anhang I Teil II gelten mit der vollständigen Geltung ab dem **11.12.2027**. > > **Die Reihenfolge ist praktisch umgekehrt.** Zwar wird das Schwachstellenmanagement erst 2027 einklagbar, doch die Meldepflicht ab dem 11.09.2026 setzt es faktisch voraus: Wer keine Eingangskanäle, keine Triage und keine dokumentierte Update-Bereitstellung hat, kann weder die 24-Stunden-Frühwarnung noch den an die Update-Verfügbarkeit anknüpfenden 14-Tage-Abschlussbericht einhalten. Der CVD-Prozess ist daher vor dem 11.09.2026 aufzubauen. > > **Schnittstelle Produkthaftung:** Mit der Umsetzung der reformierten Produkthaftungsrichtlinie zum **09.12.2026** wird **Software als Produkt** behandelt; unterlassene Sicherheitsupdates innerhalb des Unterstützungszeitraums können damit unmittelbar haftungsbegründend wirken. `[unverifiziert - prüfen]` Der deutsche Umsetzungsstand ist gesondert zu prüfen. > > **Sanktionsrahmen:** Verstöße gegen die grundlegenden Anforderungen einschließlich Anhang I Teil II sind mit **bis zu 15 Mio. EUR oder 2,5 % des weltweiten Jahresumsatzes** bewehrt, je nachdem, welcher Betrag höher ist (Art. 64 CRA).

Eingaben

• Produktportfolio mit Versionen, Unterstützungszeiträumen und Einstufung aus dem CRA-Produktinventar
• Vorhandene SBOM je Produktversion, Format und Aktualisierungsfrequenz
• Bestehende Prozesse: Eingang von Sicherheitsmeldungen, Triage, Patch-Entwicklung, Release, Kommunikation
• Vorhandene CVD-Policy, `security.txt`, Bug-Bounty-Programm, Kontaktadresse
• Update-Infrastruktur: Signaturverfahren, Verteilkanäle, Rollback, Erreichbarkeit von Offline-Installationen
• Konkrete eingehende Meldung, sofern vorhanden: Melder, Datum, Inhalt, Offenlegungsfrist des Melders
• Parallele Pflichtenkreise: NIS2-Einrichtung? DORA? Produkthaftungsrisiko?

Sub-Agent-Architektur

Drei gedankliche Rollen strukturieren die Arbeit. Ein **Prozess-Architekt** entwirft und prüft den Ablauf von der Eingangsstelle über Triage und Behebung bis zur Offenlegung und verankert ihn organisatorisch mit Rollen, Vertretung und Erreichbarkeit. Ein **Triage-Analyst** bewertet die einzelne Schwachstelle nach Ausnutzbarkeit, Schwere und Betroffenheit des Portfolios — er entscheidet insbesondere, ob eine **aktive Ausnutzung** vorliegt und damit der Meldeauslöser des Art. 14 CRA erreicht ist, und übergibt in diesem Fall unverzüglich an den Skill `cra-meldepflichten`. Ein **Kommunikations-Redakteur** verantwortet die Außendarstellung: Antwort an den Melder, Nutzerinformation, Security Advisory nach Bereitstellung des Updates und Abstimmung mit CSIRT und CVE-Vergabestelle. Der Triage-Analyst ist der zeitkritische Pfad; seine Entscheidung darf nicht auf die Patch-Entwicklung warten.

Ablauf

1. Politik zur koordinierten Schwachstellenoffenlegung ([Anhang I Teil II CRA](https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX:32024R2847))

Die **CVD-Policy** ist nach Anhang I Teil II zu **erlassen, durchzusetzen und öffentlich zugänglich zu machen**. Mindestinhalt:

• **Geltungsbereich**: welche Produkte, Versionen und Dienste erfasst sind
• **Meldekanal** mit Kontaktadresse und, wo sinnvoll, Möglichkeit verschlüsselter Übermittlung
• **Reaktionszusagen**: Eingangsbestätigung, erste Rückmeldung, Statusaktualisierungen — jeweils mit Zeitrahmen
• **Offenlegungsmodell**: koordinierte Offenlegung nach Bereitstellung eines Updates; Regelfrist und Umgang mit Fristverlängerung
• **Safe Harbour**: Zusage, gegen gutgläubig handelnde Forschende, die sich an die Policy halten, keine rechtlichen Schritte einzuleiten — insbesondere keine straf- oder zivilrechtliche Verfolgung wegen §§ 202a, 202c, 303a StGB
• **Anerkennung** des Melders (Credit) und Umgang mit Bug-Bounty-Vergütung
• **Ausschlüsse**: was ausdrücklich nicht erfasst ist (etwa Denial-of-Service-Tests in Produktivsystemen, Social Engineering)

Die Policy ist praktisch auffindbar zu machen: über die Produktwebsite, in den Nutzerinformationen nach Anhang II CRA und über eine `security.txt` nach dem einschlägigen Internetstandard.

2. Eingangskanal und Erstreaktion ([Anhang I Teil II CRA](https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX:32024R2847))

Anhang I Teil II