Schwachstellen über den Support-Zeitraum behandeln: vom Finding zum Fix, mit Fristen-Uhr

Problem

Eine Schwachstelle zu finden, ist das eine. Über Jahre belegen zu können, wann Sie davon wussten, wann Sie sie behoben und wann Sie Ihre Nutzer informiert haben, ist das, woran der CRA Sie misst. Der Cyber Resilience Act verlangt mehr als das Finden von Schwachstellen: Hersteller müssen sie über den gesamten Support-Zeitraum (die Zeit, in der ein Produkt mit Updates gepflegt wird) unverzüglich behandeln und die Nutzer informieren. Eine Stückliste (Liste aller verbauten Software-Bausteine) und ein Schwachstellen-Scan zeigen nur den Ist-Zustand - nicht aber: Seit wann ist eine Schwachstelle bekannt? Ist sie behoben, und in welcher Version? Wurden die Nutzer benachrichtigt? Läuft der Support noch? Diese Behebungs-Schleife - vom Fund über den Fix bis zur Nutzerinfo - ist der Nachweis, den eine Aufsichtsbehörde im Zweifel sehen will. Wer sie in verstreuten Tabellen und E-Mails führt, kann "unverzüglich" kaum belegen.

Für wen ist das? Für Hersteller, die Schwachstellen über den Support-Zeitraum behandeln müssen.

Kurze Antwort

Dernium CRA schließt die Schleife vom Schwachstellen-Fund bis zur Nutzerinfo und macht den Nachweis der unverzüglichen Behandlung zum Nebenprodukt der täglichen Arbeit.

• Aus den Funden je Produkt entsteht eine Behebungs-Liste, je Schwachstelle nur einmal gezählt.
• Jede Schwachstelle bekommt einen Lebenslauf: Schweregrad, Erst-Erkennung, Status, behebende Version, Verweis auf das veröffentlichte Advisory (öffentliche Sicherheitsmeldung).
• Eine Fristen-Uhr (Frist-Ampel je Schweregrad) markiert überfällige Fälle.
• Der Support-Zeitraum zeigt auf einen Blick: aktiv, läuft bald aus oder abgelaufen, samt Zähler offener und überfälliger Schwachstellen.
• Wichtig: Die Frist ist ein Richtwert, kein Rechtsmaßstab; "unverzüglich" bleibt die gesetzliche Vorgabe, und die Einstufung liegt bei Ihnen.

Tiefgang

Vom Finding zur Behebung. Die Liste baut live auf den Funden auf - über Versionen, Stücklisten und Komponenten hinweg, je Schwachstellen-Kennung (CVE, die weltweit eindeutige Nummer einer Schwachstelle) nur einmal, mit höchstem Schweregrad und frühester Erkennung. Jede Zeile bekommt einen Lebenslauf: Status (offen, in Bearbeitung, behoben, nicht betroffen, wird nicht behoben), behebende Version, Nutzerinfo-Verweis und eine Begründungsnotiz. Dieser Lebenslauf wird der Evidenz nur überlagert, nie hineingeschrieben - die Funde bleiben unverändert.

Die Fristen-Uhr. Aus Erst-Erkennung und Schweregrad ergibt sich eine Frist - als Richtwert kritisch 7, hoch 30, sonst 90 Tage. Verstreicht sie ohne Abschluss, gilt der Fall als überfällig. Erreicht er einen Abschluss-Status (behoben, nicht betroffen, wird nicht behoben), stoppt die Uhr. Diese Zahlen sind konservative Orientierung, kein gesetzlicher Maßstab: Der CRA fordert "unverzüglich", und was das im Einzelfall heißt, entscheiden Sie.

Nutzerinfo statt loser Behauptung. "Nutzer informiert" ist kein freies Häkchen, sondern verweist auf ein tatsächlich veröffentlichtes Advisory aus demselben System (Coordinated Vulnerability Disclosure, CSAF - der abgestimmte Prozess zur Offenlegung von Schwachstellen). So ist die Information nachprüfbar mit der öffentlichen Offenlegung verknüpft.

Support-Zeitraum als Statusobjekt. Das Enddatum wird nicht nur erfasst, sondern bewertet: aktiv, läuft bald aus (kleiner oder gleich 90 Tage) oder abgelaufen, mit verbleibenden Tagen und Zählern. Wichtig, weil die Behandlungspflicht an genau diesen Zeitraum gebunden ist - endet der Support, endet die Pflicht für diese Version, und beides muss dokumentiert sein.

Abgelehnte Alternativen

• Funde als Behebungsstand zweckentfremden. Ein Scan zeigt "noch da / weg", aber nicht warum (gefixt? nicht betroffen? bewusst nicht behoben?) und nicht seit wann es bekannt war. Ohne diese Schicht fehlt der Nachweis der unverzüglichen Behandlung.
• Den Behebungsstatus in die revisionssichere Evidenz schreiben. Der Lebenslauf ist veränderlich - ein Fall wandert von offen zu behoben; Funde und Stücklisten sind dagegen unveränderbar. Beides zu mischen würde entweder die Evidenz aufweichen oder den Status einfrieren. Deshalb eine getrennte, veränderliche Schicht über der Evidenz.
• Feste gesetzliche Fristen behaupten. Der CRA nennt keine Tagesfrist, sondern "unverzüglich". Eine als Gesetz verkaufte Zahl wäre falsch. Wir zeigen sie als Richtwert und sagen das deutlich.
• "Nutzer informiert" als freies Kontrollkästchen. Wäre nicht überprüfbar. Stattdessen die Bindung an ein konkret veröffentlichtes Advisory.

Was Sie jetzt tun sollten

• Schwachstellen zentral führen: Lösen Sie verstreute Tabellen und E-Mails ab und führen Sie jede Schwachstelle je Produkt an einer Stelle, je Kennung nur einmal mit höchstem Schweregrad und frühester Erkennung.
• Status sauber triagieren: Vergeben Sie für jede Schwachstelle einen klaren Status (offen, in Bearbeitung, behoben, nicht betroffen, wird nicht behoben) samt behebender Version und Begründung.
• Frist im Blick behalten: Nutzen Sie die Fristen-Uhr als Orientierung, aber dokumentieren Sie Ihre eigene Einschätzung, was "unverzüglich" im konkreten Fall bedeutet.
• Nutzerinfo an ein Advisory binden: Verknüpfen Sie "Nutzer informiert" mit einer tatsächlich veröffentlichten Sicherheitsmeldung, statt nur ein Häkchen zu setzen.
• Support-Zeitraum pflegen: Erfassen und überwachen Sie das Support-Enddatum je Version; planen Sie das Abkündigen (End-of-Life) mit Nutzerbenachrichtigung als eigenen Schritt.

Wie Dernium hilft

Pflegen Sie Produkt, Versionen und Stückliste wie gewohnt - die Behebungs-Liste fällt daraus ab. Sie triagieren je Schwachstelle den Status, hängen behebende Version und Advisory an und sehen sofort, was überfällig ist. Der Support-Status zeigt, wie lange die Pflicht noch läuft. Eine Erklärschicht benennt zu jedem Wert, was er bedeutet, und trennt den Richtwert klar vom gesetzlichen "unverzüglich". So entsteht der Nachweis der Schwachstellenbehandlung als Nebenprodukt der täglichen Arbeit - nicht als Fleißaufgabe kurz vor der Prüfung.

Offene Punkte

• Die Einstufung des Schweregrads, die Entscheidung über "unverzüglich" im Einzelfall und die Verantwortung für den Support-Zeitraum bleiben bei Ihnen. Die Fristen-Uhr ist eine Hilfe, keine Rechtsaussage.
• Der Support-Zeitraum lässt sich setzen und verschieben; das vollständige Abkündigen (End-of-Life mit Nutzerbenachrichtigung) ist als eigener Schritt vorgesehen.

Häufige Fragen

Warum reicht ein Schwachstellen-Scan als Nachweis nicht aus?

Ein Scan zeigt nur den Ist-Zustand: welche Schwachstelle noch da ist und welche weg. Er beantwortet nicht, warum etwas weg ist (behoben, nicht betroffen oder bewusst nicht behoben) und seit wann es bekannt war. Genau diese Historie - vom Fund über den Fix bis zur Nutzerinfo - braucht eine Aufsichtsbehörde, um die unverzügliche Behandlung zu beurteilen. Deshalb legt sich über die Funde eine getrennte Behebungs-Schicht.

Sind die 7, 30 und 90 Tage gesetzlich vorgeschrieben?

Nein. Der CRA nennt keine festen Tagesfristen, sondern verlangt "unverzüglich". Die Werte kritisch 7, hoch 30 und sonst 90 Tage sind eine konservative Orientierung, damit Sie überfällige Fälle früh erkennen. Was "unverzüglich" im Einzelfall bedeutet, entscheiden Sie - und sollten es dokumentieren.

Was bedeutet es, dass der Lebenslauf die Evidenz nur überlagert?

Funde und Stücklisten sind unveränderbar und revisionssicher - sie dokumentieren, was wann gemessen wurde. Der Behebungs-Status dagegen ändert sich laufend, etwa von offen zu behoben. Beides zu mischen würde entweder die Evidenz aufweichen oder den Status einfrieren. Deshalb liegt die veränderliche Behebungs-Schicht über der Evidenz, ohne sie zu verändern.

Was passiert, wenn der Support-Zeitraum abläuft?

Die Pflicht zur Schwachstellenbehandlung ist an den Support-Zeitraum gebunden. Endet der Support für eine Version, endet auch die Behandlungspflicht für diese Version - beides muss aber dokumentiert sein. Das System bewertet das Enddatum als aktiv, "läuft bald aus" oder abgelaufen und zeigt verbleibende Tage, damit Sie das Abkündigen rechtzeitig und mit Nutzerbenachrichtigung vorbereiten können.

Warum ist "Nutzer informiert" kein einfaches Häkchen?

Ein freies Häkchen wäre nicht überprüfbar. Stattdessen verweist "Nutzer informiert" auf ein tatsächlich veröffentlichtes Advisory aus demselben System (Coordinated Vulnerability Disclosure im Format CSAF). So ist die Behauptung, die Nutzer seien benachrichtigt worden, mit einer konkreten öffentlichen Offenlegung verknüpft und im Zweifel belegbar.

Verifikation

Die Pflicht zur Schwachstellenbehandlung steht in Anhang I Teil II der CRA-Verordnung, der Support-Zeitraum in Artikel 13 (Absatz 8: im Regelfall mindestens fünf Jahre, kürzer nur bei kürzerer erwarteter Nutzungsdauer); "unverzüglich" ist der dortige Maßstab. Die Behebungs-Status orientieren sich an den VEX-Begründungen (Vulnerability Exploitability eXchange - standardisierte Aussagen wie nicht betroffen / behoben / kein Fix geplant).

Mehr aus unserer CRA-Reihe

• Cyber Resilience Act: Überblick für Softwarehersteller
• SBOM und Sigstore: Herkunftsnachweis für Software-Artefakte
• CRA-Meldepflicht: Schwachstellen und Vorfälle an CSIRT und ENISA (ab 2026)
• CRA-Konformitätsnachweise: Anhang V/VII und CE (ab 2027)
• Coordinated Vulnerability Disclosure: Policy, security.txt und CSAF
• DoC- und Tech-Doc-Generator: Anhang V/VII als PDF
• Konformitätsbewertung nach CRA: welcher Pfad für welches Produkt (Art. 32)
• CRA Anhang II: Nutzerinformationen und Anleitungen als PDF
• Die CRA-Risikobewertung (Art. 13): welche Anforderungen für Ihr Produkt gelten
• Drittkomponenten nach CRA: Sorgfaltspflicht für Fremd- und Open-Source-Bausteine (Art. 13 Abs. 5)
• CRA-Readiness auf einen Blick: das Dashboard über alle Bausteine
• Wesentliche Veränderung nach CRA: wann eine neue Version neu bewertet werden muss (Art. 3 Nr. 30)
• Die notifizierte Stelle nach CRA: wann eine Dritt-Prüfung nötig ist und was sie braucht (Art. 32)
• Dernium CRA: ein Werkzeug für den gesamten Cyber Resilience Act