Monitoring
Kontinuierliches Schwachstellen-Monitoring für ausgelieferte Produkte
Kontinuierliches Schwachstellen-Monitoring heißt, die Komponenten jedes Produkts, das Sie noch unterstützen, immer wieder gegen Schwachstellendaten zu prüfen, wenn sich diese Daten ändern, und nicht nur, wenn sich Ihr Code ändert. Ein Scan, der beim Release sauber war, veraltet, sobald neue Sicherheitshinweise erscheinen; erst das Monitoring macht aus einem einmaligen Scan die fortlaufende Behandlung von Schwachstellen, die der Cyber Resilience Act erwartet.
Free-Tarif, keine Kreditkarte erforderlich.
Warum veraltet ein sauberer Scan?
Ein Schwachstellenscan beantwortet eine Frage zu einem Zeitpunkt: Welche bekannten Schwachstellen betreffen diese Komponentenversionen nach den heutigen Daten der Sicherheitshinweise? Jeden Tag werden neue CVE-Einträge veröffentlicht, und bestehende werden überarbeitet, sobald betroffene Versionen, Fixes und Belege für eine Ausnutzung bekannt werden. Ihr Produkt muss sich nicht ändern, damit sich sein Risiko ändert: Ein Firmware-Image ohne bekannte Probleme im März kann im Juni eine aktiv ausgenutzte Lücke enthalten, mit denselben Bytes auf jedem Gerät im Feld.
Deshalb fasst die Cyberresilienz-Verordnung (CRA) die Behandlung von Schwachstellen als Prozess auf, nicht als Ereignis. Anhang I Teil II verlangt von Herstellern, Schwachstellen und Komponenten zu ermitteln und zu dokumentieren, unverzüglich zu beheben und die Sicherheit wirksam und regelmäßig zu testen und zu überprüfen. Diese Pflichten gelten für den gesamten Unterstützungszeitraum, den Artikel 13 Absatz 8 auf mindestens fünf Jahre festlegt, sofern das Produkt nicht voraussichtlich kürzer genutzt wird.
Ausgelieferte Releases oder Main-Branch: was Sie erneut scannen
Den Main-Branch bei jeder Änderung zu scannen, ist nützlich, sagt Ihnen aber etwas über den Code, den Sie als Nächstes ausliefern, nicht über den Code, den Ihre Kunden betreiben. Auf Geräten im Feld laufen Releases: Version 2.3 auf einigen, 2.4 auf anderen und ein langer Schwanz von Geräten, die nie aktualisiert wurden. Jedes unterstützte Release braucht eine eigene Komponentenliste, die gegen aktuelle Daten der Sicherheitshinweise erneut geprüft wird, denn die Frage „Sind unsere Kunden exponiert?“ beantwortet das Release, nicht der Branch.
Führen Sie eine Software-Stückliste (SBOM) pro ausgelieferter Version, verknüpft mit der Versionsnummer, die Nutzer sehen. Passt ein neuer Sicherheitshinweis, können Sie dann sagen, welche Releases betroffen sind und auf welches behobene Release Sie Kunden verweisen. Bei Software erlaubt Artikel 13 Absatz 10 des CRA, die Behebung auf die zuletzt in Verkehr gebrachte, wesentlich geänderte Version zu beschränken, wenn Nutzer früherer Versionen kostenlos darauf umsteigen können und ihnen keine zusätzlichen Kosten für die Anpassung ihrer Umgebung entstehen.
SBOM-basierter Abgleich: Monitoring ohne Neubau
Statt das Produkt neu zu bauen und erneut zu scannen, bewahren Sie die beim Release erzeugte SBOM auf und vergleichen deren Komponentennamen und -versionen regelmäßig mit Datenbanken für Sicherheitshinweise wie OSV.dev, der NVD und der EU-Schwachstellendatenbank der ENISA (EUVD). Weil die SBOM beschreibt, was ausgeliefert wurde, ist ein Treffer ein Treffer gegen reale Releases. Das Ergebnis ist nur so gut wie die SBOM: Komponenten ohne Versionen oder Paketkennungen lassen sich nicht zuverlässig abgleichen, und mitgelieferter (vendored) oder statisch gelinkter Code, den die SBOM nicht aufführt, bleibt unsichtbar.
Der erneute Abgleich ergänzt einen regelmäßigen vollständigen Scan, statt ihn zu ersetzen. Ein vollständiger Scan profitiert von besserer Komponentenerkennung und neuen Analyseregeln und findet Probleme, die gar keine Komponentenschwachstellen sind, etwa eingecheckte Secrets oder Fehlkonfigurationen; führen Sie ihn daher bei jedem Release und bei jeder Änderung am Build aus.
Wie helfen KEV und EPSS, neue Schwachstellen zu priorisieren?
Monitoring erzeugt einen Strom von Treffern; die Priorisierung entscheidet, welche zuerst Aufmerksamkeit bekommen. Zwei öffentliche Signale helfen. Der Katalog Known Exploited Vulnerabilities (KEV) der CISA listet Schwachstellen mit einer CVE-ID, zuverlässigen Belegen für eine Ausnutzung in freier Wildbahn und klaren Hinweisen zur Behebung. Das Exploit Prediction Scoring System (EPSS) von FIRST veröffentlicht täglich für jede CVE eine geschätzte Wahrscheinlichkeit, dass sie in den nächsten 30 Tagen in freier Wildbahn ausgenutzt wird. CVSS beschreibt, wie schwer eine Ausnutzung wiegen könnte; KEV und EPSS zeigen, ob sie stattgefunden hat oder wie wahrscheinlich sie ist.
Kombinieren Sie sie mit Ihrem eigenen Kontext. Eine im KEV gelistete Schwachstelle in einer Komponente, die Sie ausliefern, sollte noch am selben Tag bewertet werden: Ist der verwundbare Code in Ihrem Build vorhanden und erreichbar, und welche Releases enthalten ihn? Halten Sie die Begründung in jedem Fall fest; eine dokumentierte Entscheidung „nicht betroffen“ ist für ein Audit so nützlich wie ein Fix.
Wie speist das Monitoring die Meldungen nach Artikel 14 CRA?
Seit dem 11. September 2026 verpflichtet Artikel 14 CRA Hersteller, aktiv ausgenutzte Schwachstellen in ihren Produkten dem als Koordinator benannten CSIRT und der ENISA über die einheitliche Meldeplattform der ENISA zu melden. Die Frühwarnung ist innerhalb von 24 Stunden fällig, nachdem der Hersteller Kenntnis erlangt hat, die Meldung der Schwachstelle innerhalb von 72 Stunden und der Abschlussbericht spätestens 14 Tage, nachdem eine Korrektur- oder Risikominderungsmaßnahme verfügbar ist. Nach Artikel 69 Absatz 3 erfasst Artikel 14 auch Produkte im Anwendungsbereich, die vor dem 11. Dezember 2027 in Verkehr gebracht wurden.
Die Uhr beginnt mit der Kenntnis; damit ist das Monitoring das vordere Ende Ihres Meldeprozesses. Ein neuer KEV-Eintrag, der zu einer Komponente in einem ausgelieferten Produkt passt, ist ein Signal, das eine Person schnell bewerten muss: Handelt es sich um eine aktiv ausgenutzte Schwachstelle in Ihrem Produkt, gibt es also zuverlässige Belege dafür, dass ein böswilliger Akteur sie ohne Erlaubnis des Eigentümers in einem System ausgenutzt hat? Wie auch immer die Antwort ausfällt: Artikel 13 Absatz 7 erwartet, dass Sie die Schwachstellen dokumentieren, von denen Sie Kenntnis erlangen, und die Risikobewertung gegebenenfalls aktualisieren.
Wie Sie Rhythmus und Verantwortliche für das Monitoring festlegen
Monitoring scheitert leise, wenn niemand für die Ergebnisse zuständig ist. Halten Sie Rhythmus und Verantwortliche schriftlich fest, als Teil der Richtlinie zur Behandlung von Schwachstellen, die Sie für den CRA ohnehin brauchen, und testen Sie den Ablauf einmal, bevor Sie sich darauf verlassen. Eine Grundlage, die Sie an Ihre Produkte anpassen:
- Pro Produkt eine verantwortliche Person mit Vertretung, die neue Treffer an jedem Arbeitstag prüft und KEV-Treffer noch am selben Tag.
- Ein Register der unterstützten Releases, jedes mit seiner SBOM und seinem Supportende.
- Erneuter Abgleich jedes unterstützten Release mindestens täglich und ein vollständiger Scan bei jedem Release oder jeder Build-Änderung.
- Eine Reihenfolge für die Bewertung: zuerst bekanntermaßen ausgenutzte, dann hoher EPSS-Wert, dann CVSS-Schweregrad, angepasst an die Exposition.
- Eine Person, die eine Meldung nach Artikel 14 innerhalb von 24 Stunden freigeben kann, auch am Wochenende.
- Ein Entscheidungsnachweis für jeden Treffer (betroffen, nicht betroffen, behoben in einer benannten Version) mit seinen Belegen.
Heute in KROMSE verfügbar
In kostenpflichtigen Tarifen prüft KROMSE die jeweils neueste SBOM jedes Produkts erneut gegen aktuelle Daten der Sicherheitshinweise und zeigt neue Treffer im Produkt an.
- Alle 6 Stunden wird die neueste SBOM jedes Produkts erneut gegen OSV.dev geprüft, für bis zu 5 Produkte pro Arbeitsbereich und Durchlauf, im Wechsel.
- Neue Treffer erscheinen als Hinweise in der Anwendung, und eine Schaltfläche „Run monitoring now“ startet eine Prüfung bei Bedarf.
- Befunde mit CVE-IDs werden mit CISA KEV, FIRST EPSS, der NVD und der EU-Schwachstellendatenbank der ENISA (EUVD) angereichert.
- Jeder Scan erzeugt SBOMs in CycloneDX und SPDX, und Sie können vorhandene SBOMs hochladen.
- In kostenpflichtigen Tarifen interne Berichtsentwürfe nach Artikel 14 CRA für die 24-Stunden-, die 72-Stunden- und die Abschlussstufe als PDF, zur Freigabe durch eine Person; KROMSE reicht sie nie ein.
- Heutige Grenzen: Einen eigenen Zeitplan können Sie nicht festlegen, das Monitoring versendet keine E-Mails und startet keine erneuten Scans automatisch.
Als Nächstes geplant
Auf der Roadmap, noch nicht verfügbar. Die Termine sind Zielmarken, keine Zusagen; diese Seite wird an dem Tag aktualisiert, an dem eine Funktion live geht.
- Geplant · Q4 2026 (Dezember)Überwachung nach Ihrem Zeitplan, mit KI-Agenten. Erneute Scans werden nach einem Zeitplan laufen, den Sie festlegen, mit KI-Agenten, die neue Sicherheitshinweise verfolgen, einordnen, was davon zutrifft, Korrekturen vorschlagen und den Bericht zu Ihrer Prüfung entwerfen.
- Geplant · Q4 2026 (November)KI-Korrekturvorschläge, von Menschen freigegeben. KROMSE wird Korrekturen für Befunde vorschlagen, mit KI formuliert und erst angewendet, nachdem eine Person in Ihrem Team sie freigegeben hat.
- Geplant · Q1 2027Übermittlung an die einheitliche Meldeplattform der ENISA. Nachdem eine Person einen Bericht nach Artikel 14 freigegeben hat, wird KROMSE ihn an die einheitliche Meldeplattform der ENISA übermitteln.
Häufige Fragen
Was ist der Unterschied zwischen Schwachstellenscan und kontinuierlichem Schwachstellen-Monitoring?
Ein Scan untersucht ein Produkt einmal und listet die bekannten Schwachstellen in seinen Komponenten zu diesem Zeitpunkt auf. Kontinuierliches Monitoring wiederholt den Abgleich, wenn sich die Daten der Sicherheitshinweise ändern, meist durch erneuten Abgleich der SBOM jedes Release; so erfahren Sie von neuen Schwachstellen in ausgelieferten Produkten, ohne auf die nächste Codeänderung zu warten.
Wie oft sollten ausgelieferte Produkte auf neue Schwachstellen geprüft werden?
Kein EU-Gesetz legt ein festes Intervall fest. Der CRA verlangt regelmäßige Tests und Überprüfungen und eine unverzügliche Behebung, und seine Melde-Uhr läuft ab Kenntnis einer aktiv ausgenutzten Schwachstelle; das Intervall sollte es Ihnen also erlauben, eine solche innerhalb von Stunden zu bemerken, nicht erst nach Wochen. Ein täglicher oder häufigerer SBOM-Abgleich plus ein vollständiger Scan bei jedem Release ist ein vernünftiger Ausgangspunkt.
Muss ich nach Artikel 14 CRA melden, wenn eine Schwachstelle im KEV steht?
Nicht automatisch. Artikel 14 betrifft aktiv ausgenutzte Schwachstellen in Ihrem Produkt: Es muss zuverlässige Belege dafür geben, dass ein böswilliger Akteur die Schwachstelle ohne Erlaubnis des Eigentümers in einem System ausgenutzt hat. Ein KEV-Eintrag ist ein starker Beleg für eine Ausnutzung, aber eine Person muss trotzdem feststellen, ob der verwundbare Code in Ihrem Produkt steckt. Sobald Sie davon Kenntnis haben, läuft die 24-Stunden-Frist.
Ist Monitoring auch für Produkte wichtig, die vor dem Geltungsbeginn des CRA in Verkehr gebracht wurden?
Ja, für die Meldepflicht. Nach Artikel 69 Absatz 3 gilt Artikel 14 auch für Produkte im Anwendungsbereich, die vor dem 11. Dezember 2027 in Verkehr gebracht wurden, und Artikel 14 gilt seit dem 11. September 2026. Die CRA-FAQ der Kommission erläutert, dass Hersteller für diese Produkte melden müssen, aber nicht verpflichtet sind, andere Pflichten wie die Behandlung von Schwachstellen zu erfüllen. Um eine ausgenutzte Schwachstelle darin zu bemerken, müssen Sie trotzdem wissen, was sie enthalten.
Benachrichtigt mich KROMSE per E-Mail, wenn eine neue Schwachstelle zu meinem Produkt passt?
Heute nicht. In kostenpflichtigen Tarifen prüft KROMSE die neueste SBOM jedes Produkts alle 6 Stunden erneut gegen OSV.dev, für bis zu 5 Produkte pro Arbeitsbereich und Durchlauf im Wechsel, und zeigt neue Treffer als Hinweise in der Anwendung an. Monitoring nach einem von Ihnen festgelegten Zeitplan, mit KI-Agenten, steht auf der Roadmap.
Verwandte Leitfäden
Quellen
- Verordnung (EU) 2024/2847 (Cyberresilienz-Verordnung), EUR-Lex
- Europäische Kommission: FAQ zur Umsetzung des Cyber Resilience Act
- ENISA: Single Reporting Platform (einheitliche Meldeplattform)
- ENISA: EU-Schwachstellendatenbank (EUVD)
- CISA: Katalog Known Exploited Vulnerabilities
- FIRST: Exploit Prediction Scoring System (EPSS)
- OSV: Open-Source-Schwachstellendatenbank