Jeder CRA-Hersteller braucht für jedes Produkt einen laufenden Prozess zur Schwachstellenbehandlung: wissen, was im Produkt steckt, Schwachstellen finden und beheben, regelmäßig testen, Advisories veröffentlichen, externe Meldungen annehmen und Sicherheitsupdates sicher und kostenlos ausliefern. Diese Seite erklärt dieses Betriebsmodell und wo es an die dringende regulatorische Meldung übergibt.
Zusammenfassung
- Schwachstellenbehandlung ist ein Engineering-Betriebsmodell, das jeder CRA-Hersteller für jedes Produkt mit digitalen Elementen braucht.
- Acht nummerierte Pflichten: identifizieren (mit SBOM), unverzüglich beheben, regelmäßig testen, behobene Schwachstellen öffentlich offenlegen, eine CVD-Richtlinie betreiben, Schwachstellenmeldungen erleichtern, Updates sicher verteilen, Sicherheitsupdates kostenlos bereitstellen.
- Kostenlosigkeit ist nicht verhandelbar: Sicherheitsupdates sind standardmäßig kostenlos, mit einer engen Ausnahme für maßgeschneiderte Produkte an gewerbliche Nutzer.
- Die CVD-Richtlinie ist verpflichtend, nicht optional: koordinierte Schwachstellenoffenlegung gehört zur CE-Kennzeichnungsreife, nicht zu freiwilliger Best Practice.
- Schwachstellenbehandlung läuft über den gesamten Unterstützungszeitraum; der Mindestzeitraum beträgt fünf Jahre ab Bereitstellung auf dem Markt, sofern die erwartete Produktnutzungsdauer nicht kürzer ist und offengelegt wurde.
- Schwachstellenbehandlung ist keine dringende regulatorische Meldung: Behandlung ist der laufende Engineering-Prozess; Meldung startet nur bei aktiver Ausnutzung oder schwerwiegenden Vorfällen.
Die vier Ankerpunkte der CRA-Schwachstellenbehandlung: Geltungsbereich, Dauer, Update-Kosten und die Grenze zur dringenden Meldung.
Die acht Pflichten der Schwachstellenbehandlung
Der CRA behandelt Schwachstellenbehandlung nicht als einmalige Checkliste. Er erwartet einen kontinuierlichen Lebenszyklus über den gesamten Unterstützungszeitraum, vom Komponentenbestand über Behebung, Offenlegung und sichere Update-Auslieferung. Die Tabelle ordnet die acht Pflichten nach der operativen Phase, in der sie normalerweise laufen.
| Phase | Nummern | Was abgedeckt ist | Operativer Fokus |
|---|---|---|---|
| Erkennen und katalogisierenEingang und Bestand | Nummern 1 und 6 | SBOM-gestützte Identifikation von Komponenten und bekannten Schwachstellen sowie ein öffentlicher Meldekanal. | Komponentendaten aktuell halten und externen Meldern den Zugang zum Produktsicherheitsteam erleichtern. |
| Beheben und testenRemediation und Tests | Nummern 2 und 3 | Unverzügliche Behebung und wirksame regelmäßige Tests des Codes und seiner Abhängigkeiten. | Dringlichkeit nach Schweregrad festlegen und Nachweise sichern, dass Fixes und Tests rechtzeitig liefen. |
| VerteilenSicherer Update-Kanal | Nummern 7 und 8 | Signierte, authentifizierte Sicherheitsupdates, trennbar von Funktionen und kostenlos außer bei maßgeschneiderten B2B-Produkten. | Sicherheitsfixes ausliefern, ohne Nutzer zu Funktions-Upgrades oder kostenpflichtigen Wartungsstufen zu zwingen. |
| Koordinieren und offenlegenCVD und Advisories | Nummern 4 und 5 | Eine durchgesetzte CVD-Richtlinie und öffentliche Advisories, sobald ein Fix verfügbar ist. | Researcher-Eingang, Nutzerhinweise und begründete Offenlegungsverzögerungen aus einem Playbook steuern. |
Was jede Pflicht in der Praxis bedeutet
| # | Pflicht | Was sie tatsächlich verlangt |
|---|---|---|
| 1 | Schwachstellen und Komponenten identifizieren und dokumentieren | Eine SBOM in CycloneDX oder SPDX, die mindestens die obersten Abhängigkeiten abdeckt. Die SBOM ist der Index, der CVE-Abgleich erst möglich macht: Sie können nicht beheben, was Sie nicht katalogisiert haben. |
| 2 | Unverzügliche Behebung, getrennt von Funktionen | Kein fester SLA; das erwartete Tempo skaliert mit dem Schweregrad. Sicherheitszweige müssen von Funktionszweigen trennbar sein, damit Nutzer einen Patch nicht durch Aufschieben eines Releases verzögern können. |
| 3 | Wirksame und regelmäßige Tests | Statische Analyse, dynamische Tests, Abhängigkeits-Scans gegen Schwachstellen-Feeds und Penetrationstests. "Regelmäßig" muss zu Risiko und Änderungsrate des Codes passen. |
| 4 | Öffentliche Offenlegung behobener Schwachstellen | Sobald ein Fix ausgeliefert ist, Beschreibung, betroffenes Produkt, Auswirkung, Schweregrad und Behebung veröffentlichen. Verzögerung nur "in hinreichend begründeten Fällen", bis Nutzer patchen können. CVE plus CSAF ist der De-facto-Träger. |
| 5 | Richtlinie zur koordinierten Schwachstellenoffenlegung | Eine schriftliche, durchgesetzte CVD-Richtlinie mit Eingangskanal, Antwort-SLA und Offenlegungsbedingungen. ISO/IEC 29147 und 30111 bieten einen formalen Rahmen. |
| 6 | Externe Schwachstellenmeldung erleichtern | Eine Kontaktadresse für Meldungen zu Problemen im Produkt und seinen Drittanbieter-Komponenten. security.txt nach RFC 9116 erfüllt die Kanal-Anforderung. |
| 7 | Sichere Update-Verteilung | Signierte, authentifizierte Updates, automatisch wo zutreffend. Produkte ohne Update-Kanal müssen einen aufbauen oder dokumentieren, warum Automatisierung nicht zutrifft. Siehe Sicherheitsupdates. |
| 8 | Kostenlos, mit Hinweistexten | Sicherheitsupdates müssen unverzüglich und kostenlos verteilt werden (einzige Ausnahme: maßgeschneiderte Produkte für gewerbliche Nutzer, sofern die Parteien etwas anderes vereinbart haben). Jedes Update muss einen Hinweistext tragen, der das Problem und die erforderliche Nutzeraktion beschreibt. Eine kostenpflichtige Wartungs-Schranke oder ein stiller Patch ohne Hinweistext verstößt gegen Nummer 8. |
Schwachstellenbehandlung und der Unterstützungszeitraum
Schwachstellenbehandlung läuft über den gesamten Unterstützungszeitraum. Der Standard-Mindestzeitraum beträgt fünf Jahre ab dem Datum, an dem das Produkt auf dem EU-Markt bereitgestellt wurde, sofern die erwartete Produktnutzungsdauer nicht kürzer ist und offengelegt wurde. Das Enddatum des Unterstützungszeitraums muss in den Produktinformationen stehen. Endet dieser Zeitraum, entfallen die aktiven Behandlungspflichten für diese Produktversion, aber technische Dokumentation und Konformitätserklärung müssen weiterhin 10 Jahre ab Bereitstellung auf dem Markt oder für den Unterstützungszeitraum aufbewahrt werden, je nachdem was länger ist. Siehe CRA-Unterstützungszeitraum.
Schwachstellenbehandlung ist keine dringende Meldung
Der CRA unterscheidet zwei Pflichten, die auf unterschiedlichen Oberflächen und mit unterschiedlichen Adressaten arbeiten:
- Schwachstellenbehandlung ist der Engineering-Prozess: SBOM, Behebung, CVD-Richtlinie, öffentliche Offenlegung und sichere Updates. Sie gilt für alle Schwachstellen über den gesamten Unterstützungszeitraum und liegt bei der Produktsicherheitsorganisation des Herstellers.
- Dringende regulatorische Meldung startet nur bei einer aktiv ausgenutzten Schwachstelle oder einem schwerwiegenden Vorfall mit Auswirkung auf die Sicherheit des Produkts. Sie läuft über die ENISA Single Reporting Platform im Takt 24h / 72h an ENISA und das als Koordinator benannte CSIRT, zuzüglich eines Abschlussberichts (14 Tage nach Verfügbarkeit einer Korrektur- oder Abhilfemaßnahme bei einer aktiv ausgenutzten Schwachstelle, oder einen Monat nach der 72-Stunden-Meldung bei einem schwerwiegenden Vorfall). Zur SRP-Onboarding-Mechanik siehe ENISA-SRP-Onboarding.
Ein Produktteam kann einen konformen Schwachstellenbehandlungsprozess betreiben, ohne jemals eine dringende Meldung einzureichen, weil die meisten Schwachstellen behoben werden, bevor sie aktiv ausgenutzt werden. Meldung startet erst, wenn die Behebung mit aktiver Ausnutzung oder einem schwerwiegenden Vorfall noch nicht Schritt gehalten hat. Siehe CRA-Schwachstellenmeldung.
Bußgeldrisiko
Fehler bei der Schwachstellenbehandlung können erhebliche Verwaltungsbußgelder auslösen. Die Details zu Stufen und Auslösern gehören jedoch in den eigenen Enforcement-Leitfaden. Siehe CRA-Bußgelder und Durchsetzung für Bußgeldstufen, Durchsetzungsauslöser und die Einordnung von Schwachstellenbehandlungsfehlern in das Gesamtmodell.
Häufig gestellte Fragen
Muss die SBOM transitive Abhängigkeiten abdecken?
Die rechtliche Untergrenze sind die obersten Abhängigkeiten, aber eine praktikable SBOM sollte meist tiefer gehen. Sie können eine CVE in einer transitiven Komponente nicht unverzüglich beheben, wenn Sie diese Komponente nie katalogisiert haben. Die meisten Aufsichtsbehörden und Kunden erwarten eine tiefe SBOM, die BSI TR-03183 oder vergleichbaren Leitlinien folgt. CycloneDX und SPDX qualifizieren sich beide als weit verbreitete und maschinenlesbare Formate. Siehe CRA-SBOM-Anforderungen.
Was bedeutet "unverzüglich" in der Praxis für die Behebung nach Nummer 2?
Der CRA legt keinen festen Behebungs-SLA fest. "Unverzüglich" skaliert mit dem Cybersicherheitsrisiko: eine kritische Schwachstelle mit aktiver Ausnutzung in freier Wildbahn verlangt einen Fix in Tagen, während ein Problem mit niedrigem Schweregrad bis zum nächsten regulären Zyklus warten kann. Der Schweregrad wird mit CVSS festgestellt, durch EPSS-Ausnutzungswahrscheinlichkeitsdaten geschärft und durch Belege aus dem CISA-KEV-Katalog bestätigt, sofern die Schwachstelle auf der Liste aktiv ausgenutzter Schwachstellen der CISA steht. Siehe Schweregradbewertung für die operative Skala, die Marktbehörden bei der Beurteilung anlegen, ob ein Hersteller "unverzüglich" behoben hat.
Können Sicherheitsupdates unter irgendwelchen Umständen kostenpflichtig sein?
Es existiert nur eine Ausnahme: Für maßgeschneiderte Produkte, die an einen gewerblichen Nutzer geliefert werden, ist eine kostenpflichtige Vereinbarung möglich, wenn Hersteller und gewerblicher Nutzer etwas anderes vereinbart haben. Für jedes andere Produkt, einschließlich aller Verbraucherprodukte und standardmäßiger B2B-SaaS oder Hardware, müssen Sicherheitsupdates über den gesamten Unterstützungszeitraum kostenlos sein. Einen Sicherheitspatch hinter eine kostenpflichtige Wartungsstufe zu stellen, setzt den Hersteller den höchsten Bußgeldern aus.
Bestehen die Pflichten zur Schwachstellenbehandlung nach dem Ende des Unterstützungszeitraums fort?
Nein. Die acht Pflichten zur Schwachstellenbehandlung entfallen für diese Produktversion, sobald der Unterstützungszeitraum endet. Neue Schwachstellen nach End-of-Support müssen für diese Version nicht behoben werden, sofern der Hersteller ein klares End-of-Support-Datum veröffentlicht hat, damit Nutzer migrieren können. Zwei Pflichten bestehen unabhängig davon fort. Die technische Dokumentation und die EU-Konformitätserklärung müssen weiterhin 10 Jahre ab Bereitstellung auf dem Markt oder für den Unterstützungszeitraum aufbewahrt werden, je nachdem was länger ist. Meldung ist von der Behandlung getrennt: Erlangt der Hersteller Kenntnis von einer aktiv ausgenutzten Schwachstelle oder einem schwerwiegenden Sicherheitsvorfall im Produkt, kann die Meldepflicht nach Artikel 14 weiterhin gelten, weil sie nicht an den Unterstützungszeitraum gebunden ist. Siehe Unterstützungszeitraum und End-of-Support-Offenlegung.
Wann muss ein CVD-Eingang dringend gemeldet werden?
Der Auslöser ist aktive Ausnutzung, nicht eine private Meldung oder bloße Ausnutzbarkeit. Ein funktionierender Proof-of-Concept, der einer CVD-Meldung beigefügt ist, ist für sich allein nicht meldepflichtig; meldepflichtig wird er, wenn eine begründete Annahme besteht, dass ein böswilliger Akteur den Fehler gegen ein reales Ziel eingesetzt hat. Sobald diese Schwelle überschritten ist, beginnt die 24-Stunden-Frühwarnung an ENISA und das Koordinator-CSIRT, gefolgt von der 72-Stunden-Meldung und einem Abschlussbericht innerhalb von 14 Tagen nach Verfügbarkeit einer Korrekturmaßnahme. Siehe CRA-Schwachstellenmeldung.