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

4 Min Lesezeit Serie: compliance #compliance#cra#schwachstellenbehandlung#remediation#support-zeitraum#sla#vex

Der Cyber Resilience Act verlangt, Schwachstellen über den gesamten Support-Zeitraum unverzüglich zu behandeln und die Nutzer zu informieren. Dernium CRA-Nachweis schließt diese Schleife: Aus den Funden je Produkt entsteht eine Behebungs-Liste mit dem Lebenslauf jeder Schwachstelle - Schweregrad, Erst-Erkennung, SLA-Uhr, Status, behebende Version und das Advisory als Nutzerinfo - samt verwaltetem Support-Zeitraum. Dieser Beitrag zeigt die Bausteine und wo bewusst die Verantwortung beim Hersteller bleibt.

Problem

Der Cyber Resilience Act verlangt mehr als das Finden von Schwachstellen: Hersteller müssen sie über den gesamten Support-Zeitraum unverzüglich behandeln und die Nutzer informieren. Eine Stückliste und ein Schwachstellen-Scan zeigen nur den Ist-Zustand. Was sie nicht zeigen: Seit wann ist eine Schwachstelle bekannt? Ist sie schon behoben - und in welcher ausgelieferten Version? Wurden die Nutzer benachrichtigt? Und läuft der Support für dieses Produkt überhaupt noch? Genau 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, verliert den roten Faden und kann „unverzüglich" nicht belegen.

Kurze Antwort

Dernium CRA-Nachweis schließt die Schleife: Aus den Funden je Produkt - über alle Versionen, dedupliziert je Schwachstelle - entsteht eine Behebungs-Liste mit dem vollständigen Lebenslauf jeder Schwachstelle: Schweregrad, Erst-Erkennung, eine SLA-Frist als Orientierung, Bearbeitungsstatus, die behebende Version und der Verweis auf das veröffentlichte Advisory als Nutzerinfo. Eine SLA-Uhr je Schweregrad markiert überfällige Fälle. Parallel verwalten Sie den Support-Zeitraum des Produkts und sehen auf einen Blick, ob er aktiv ist, bald ausläuft oder abgelaufen ist - samt Zähler offener und überfälliger Schwachstellen. Die SLA-Frist ist ein Richtwert, kein Rechtsmaßstab; „unverzüglich" bleibt die gesetzliche Vorgabe, und die Einstufung liegt beim Hersteller.

Tiefgang

Vom Finding zur Behebung. Die Liste baut live auf den Funden auf - aggregiert über Versionen, Stücklisten und Komponenten, dedupliziert je Schwachstellen-Kennung mit dem höchsten Schweregrad und der frühesten Erkennung. Jede Zeile bekommt einen Lebenslauf: Status (offen, in Bearbeitung, behoben, nicht betroffen, wird nicht behoben), die behebende Version, einen Nutzerinfo-Verweis und eine Notiz für die Begründung. Dieser Lebenslauf wird der Evidenz nur überlagert, nie hineingeschrieben - die Funde selbst bleiben unverändert.

Die SLA-Uhr. Aus Erst-Erkennung und Schweregrad ergibt sich eine Frist - als Richtwert kritisch 7, hoch 30, sonst 90 Tage. Ist sie verstrichen und der Fall nicht abgeschlossen, gilt er als überfällig. Sobald eine Schwachstelle einen terminalen Status erreicht (behoben, nicht betroffen, wird nicht behoben), stoppt die Uhr. Diese Zahlen sind bewusst konservative Orientierung, kein gesetzlicher Maßstab: Der CRA fordert „unverzüglich", und was das im Einzelfall heißt, entscheidet der Hersteller.

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). So ist die Information nachprüfbar mit der öffentlichen Offenlegung verknüpft, statt nur behauptet zu sein.

Support-Zeitraum als Statusobjekt. Das Enddatum wird nicht nur erfasst, sondern bewertet: aktiv, läuft bald aus (≤ 90 Tage) oder abgelaufen, mit verbleibenden Tagen und Zählern. Das ist wichtig, weil die Behandlungspflicht genau an 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; die Funde und Stücklisten sind append-only. Beides zu mischen würde entweder die Evidenz aufweichen oder den Status einfrieren. Deshalb eine getrennte, veränderliche Schicht, die der Evidenz überlagert wird.
  • Feste gesetzliche SLA-Tage behaupten. Der CRA nennt keine Tagesfrist, sondern „unverzüglich". Eine als Gesetz verkaufte Zahl wäre schlicht 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.

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 die behebende Version und das Advisory an und sehen sofort, was überfällig ist. Der Support-Status zeigt, wie lange die Pflicht für ein Produkt noch läuft. Eine Erklärschicht benennt zu jedem Wert, was er bedeutet, und trennt den Richtwert klar vom gesetzlichen „unverzüglich". So führen Sie den Nachweis der Schwachstellenbehandlung als Nebenprodukt der täglichen Arbeit - nicht als separate 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 beim Hersteller. Die SLA-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.

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 (nicht betroffen / behoben / kein Fix geplant).

Mehr aus unserer CRA-Reihe