CRA-Umsetzung bei Greenbone: So haben wir die Meldepflicht betriebsfähig gemacht

Welche Anforderungen der Cyber Resilience Act zum 11. September 2026 stellt, haben wir bereits in einem eigenen Beitrag zum Umsetzungsstand der CRA-Meldepflicht erläutert. Dieser Beitrag beantwortet die andere Hälfte der Frage: wie die Umsetzung bei Greenbone selbst erfolgt ist.

Eine Einordnung vorweg, weil sie für die Übertragbarkeit entscheidend ist: Wir haben nicht alle Maßnahmen neu implementiert. Vieles davon war bei uns schon vorher etablierte Praxis und musste für den CRA lediglich dokumentiert, geschärft oder in einen verbindlichen Prozess überführt werden. Wer heute vor derselben Aufgabe steht, findet im eigenen Haus vermutlich mehr Substanz als erwartet.

Anforderung: ein Prozess für Schwachstellen und Vorfälle

Der CRA verlangt keinen Meldeknopf, sondern einen belastbaren Prozess dahinter. Neben dem Prozess zur Behandlung von Incidents haben wir deshalb einen Prozess zur Coordinated Vulnerability Disclosure implementiert. Darin ist das Vorgehen bei Bekanntwerden einer Schwachstelle im Detail geregelt, inklusive der Zuständigkeiten. Dazu gehört eine Checkliste, die man Schritt für Schritt durchgehen kann. Sicherheitsvorfälle bilden wir in einem eigenen Jira-Projekt ab, so dass jeder Fall einen Vorgang mit Historie hat.

Der Prozessgedanke ist an einer Stelle besonders wichtig: Die 24-Stunden-Uhr des Artikels 14 beginnt mit der Kenntniserlangung, und was das genau heißt, hat die Kommission in ihrer im Juli 2026 gebilligten Leitlinie zur Anwendung des CRA (C(2026) 5252) präzisiert. Maßstab ist ein „hinreichender Grad an Gewissheit“ unter Verweis auf Erwägungsgrund 31 der Durchführungsverordnung (EU) 2024/2690 und die EDSA-Leitlinien 9/2022 (Rn. 211–214). Ohne einen definierten Triage-Schritt lässt sich dieser Punkt im Ernstfall nicht datieren, und ohne Datum ist die Frist nicht nachweisbar eingehalten. Zu beachten ist, dass diese Leitlinie ausdrücklich nicht bindend ist (Rn. 8); sie ist Auslegungshilfe, nicht Rechtsgrundlage.

Zwei Fristen sollte man im Prozess getrennt führen, weil sie unterschiedlich laufen: Der Abschlussbericht für eine Schwachstelle ist 14 Tage nach Bereitstellung des Fixes fällig, der für einen schwerwiegenden Sicherheitsvorfall dagegen einen Monat nach der 72-Stunden-Meldung (Rn. 215). Wer beide Uhren in einem Feld abbildet, meldet in einem der beiden Fälle zu spät.

Entlastend, und in der aktuellen Debatte oft übersehen: Für Schwachstellen, die bereits vor dem 11. September 2026 bekannt waren, entsteht keine rückwirkende Meldepflicht (Rn. 217). Der Bestand muss also nicht nachgemeldet werden.

Anforderung: Schwachstellen in Fremdkomponenten weitergeben

Stammt eine Lücke in unseren Produkten aus einem Artefakt Dritter, benachrichtigen wir dessen Anbieter, damit sie dort behoben wird. Implementieren wir selbst einen Fix, machen wir diesen upstream verfügbar.

Das deckt sich mit Abschnitt 9.2.1 der Kommissionsleitlinie zu Artikel 13(6): Wer eine Fremdkomponente integriert, muss Schwachstellen an die pflegende Stelle melden, sofern diese nicht bereits Kenntnis hat, und sollte Korrekturen möglichst maschinenlesbar und lizenzkompatibel teilen. Ebenfalls klargestellt: Die Meldepflicht selbst greift für aktiv ausgenutzte Schwachstellen im eigenen Produkt, nicht für jede nicht ausgenutzte Lücke in einer Fremdkomponente (Rn. 218).

Anforderung: Betroffene erreichbar informieren

Für aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle, die sich auf die Sicherheit unserer Produkte auswirken können, veröffentlichen wir Advisories im CSAF-Format unter dem bekannten Pfad, bis auf eventuelle Ausnahmen unter TLP:WHITE. Bei schwerwiegenden Sicherheitslücken, die aus unserem eigenen Code stammen, beantragen und veröffentlichen wir eine CVE.

Warum maschinenlesbar? Weil ein Advisory, das nur als Webseite existiert, bei den Empfängern Handarbeit auslöst. Wer wissen will, welche Rollen im CSAF-Ökosystem welche Pflichten haben, findet die Einordnung in unserem Beitrag zu den CSAF-2.0-Stakeholdern und -Rollen.

Wichtig für die Erwartungshaltung: Die Pflicht aus Artikel 14(8), Nutzende zu informieren, ist risikobasiert und verhältnismäßig ausgestaltet und keine pauschale Pflicht zur öffentlichen Offenlegung jedes Vorgangs (Rn. 219–221). Was zu veröffentlichen ist, richtet sich nach dem Fall, nicht nach einem Automatismus. Unsere Ausnahmeregelung von TLP:WHITE ist genau dafür vorgesehen.

Was nur ein Scanner-Hersteller tun kann

Bei schwerwiegenden Sicherheitslücken in unseren Produkten erstellen wir zusätzlich einen Schwachstellentest, so dass OPENVAS SCAN die Verwundbarkeit entdeckt und meldet. Dieser Baustein ist ausdrücklich nicht zum Nachmachen gedacht: Er setzt voraus, dass man selbst Hersteller eines Schwachstellenscanners ist. Für unsere Kundschaft heißt er, dass sie die Betroffenheit der eigenen Installation nicht aus einem Advisory ableiten muss, sondern messen kann.

Anforderung: reagieren, nicht nur melden

Je nach Schwere einer Lücke erstellen wir ein Notfallrelease und stellen es der Kundschaft zur Verfügung. Nach Bearbeitung einer Schwachstelle erfolgt eine Post-Mortem-Analyse.

Anforderung: erreichbar sein für Meldungen von außen

Damit Personen, die eine Schwachstelle entdecken, uns erreichen, gibt es auf der Greenbone-Website eine Seite zum Thema Meldung von Schwachstellen in Produkten, außerdem eine security.txt nach RFC 9116.

Ein Tipp aus der Praxis, der nichts kostet und viel spart: Prozesse testen, damit man nicht erst im Ernstfall merkt, wenn etwas nicht funktioniert wie gedacht.

Offen ist bei uns noch das Testen einer Meldung an ENISA. Wie im vorherigen Beitrag beschrieben, gibt es die Plattform noch nicht in finaler Form. Diesen Punkt können wir vorbereiten, aber nicht abschließen.

Anforderung: die eigene Lieferkette kennen

Ein weiterer Bestandteil unserer Vorbereitung auf den 11. September 2026 ist, dass wir im Buildprozess automatisiert SBOMs unserer Produkte erstellen. Hier kommt OPENVAS SECURITY INTELLIGENCE ins Spiel, womit wir die SBOMs auf Schwachstellen scannen. Durch den täglich aktualisierten Metafeed können Schwachstellen in verwendeten Komponenten frühzeitig behandelt werden, so dass es gar nicht erst zu einer Ausnutzung in freier Wildbahn kommt.

Des Weiteren bietet es sich an, die Advisories seiner Zulieferer regelmäßig zu überprüfen, um frühzeitig auf gefixte Versionen updaten zu können. Immer mehr Hersteller stellen ihre Advisories im CSAF-Format bereit; das ist auch die vom BSI präferierte Methode, festgehalten in der Technischen Richtlinie BSI TR-03191 und in der Empfehlung des BSI zum Einsatz von CSAF. Auch hier bietet es sich an, OPENVAS SECURITY INTELLIGENCE zu verwenden, womit CSAF-Advisories, auch solche mit Zugangsbeschränkung, regelmäßig heruntergeladen und analysiert werden können, zum Beispiel jede Nacht oder auch stündlich.

Checkliste: Wo stehen Sie bei der CRA-Meldepflicht?

Selbst-Check: Wo stehen Sie?

• Ein Coordinated-Vulnerability-Disclosure-Prozess mit klaren Zuständigkeiten ist etabliert
• Schwachstellen in Fremdkomponenten werden an die pflegende Stelle weitergegeben
• Betroffene werden über maschinenlesbare Advisories (z. B. CSAF) informiert
• Es gibt einen definierten Prozess für Notfallreleases und Post-Mortem-Analysen
• Externe können Schwachstellen leicht melden (Kontaktseite, security.txt)
• SBOMs werden automatisiert erstellt und auf Schwachstellen überwacht

Was davon für Sie übertragbar ist

Der Aufwand für den 11. September 2026 verteilt sich ungleich. Die Meldewege selbst, security.txt, Kontaktseite, CSAF-Pfad, sind vom Aufwand her überschaubar. Der Prozess dahinter mit Zuständigkeiten, Checkliste und dokumentierter Triage braucht länger und entscheidet darüber, ob eine 24-Stunden-Frist tatsächlich haltbar ist. Und die Lieferkette braucht Automatisierung, weil eine manuell gepflegte Komponentenliste in dem Moment veraltet ist, in dem sie fertig ist.

Für die beiden letzten Punkte laufen bei uns SBOM-Scan und Zulieferer-Advisories in OPENVAS SECURITY INTELLIGENCE zusammen: eine Analyse an einem Ort, statt Feeds, Tabellen und Advisory-Seiten getrennt zu verfolgen.

Wenn Sie Ihre eigene Umsetzung gegen diese Punkte halten wollen, führen von hier zwei Wege weiter. Unsere Übersicht zum Cyber Resilience Act fasst Anforderungen, Fristen und Betroffenheit zusammen, falls Sie sich das Thema zuerst selbst erschließen möchten. Und wenn bei Ihnen ein oder mehrere Punkte aus der Checkliste oben noch offen sind — sei es der CVD-Prozess, maschinenlesbare Advisories oder automatisierte SBOMs — sprechen Sie direkt mit uns darüber.