Einleitung: Risikobasiertes Schwachstellenmanagement gemäß dem Cyber Resilience Act
Moderne Teams wissen längst, dass es unmöglich ist, alle Schwachstellen zu beheben. Entscheidend ist, die richtigen zu identifizieren. Deshalb hat sich risikobasiertes Schwachstellenmanagement zum bevorzugten Ansatz für DevSecOps-Teams entwickelt. In der Europäischen Union ist dies jedoch nicht mehr nur eine bewährte Methode. Der Cyber Resilience Act führt konkrete rechtliche Verpflichtungen ein, insbesondere wenn Software Schwachstellen aufweist, die in der Liste der Schwachstellen aufgeführt sind. CISEin Katalog bekannter ausgenutzter Sicherheitslücken.
In diesem neuen Kontext wandelt sich die Priorisierung von Schwachstellen von einer Sicherheitsentscheidung zu einer Compliance-Anforderung. Teams müssen nachweisen, dass sie verstehen, welche Schwachstellen aktiv ausgenutzt werden und wie sie entscheiden, welche zuerst behoben werden sollen. Und die Zeitvorgabe ist nicht länger abstrakt: Die Meldepflichten gegenüber der CRA für aktiv ausgenutzte Sicherheitslücken und schwerwiegende Vorfälle gelten ab dem 11. September 2026.Die vollständigen Hauptverpflichtungen folgen im Dezember 2027. Das Priorisierungsmodell, das eine Organisation heute anwendet, muss innerhalb weniger Wochen, nicht Quartale, den Anforderungen dieser Berichtspflicht standhalten.
Risikobasiertes Schwachstellenmanagement und bekannte ausgenutzte Schwachstellen
Risikobasiertes Schwachstellenmanagement konzentriert sich auf die tatsächliche Gefährdung anstatt auf den Schweregrad. Anstatt alle CVEs gleich zu behandeln, priorisieren Teams anhand von Ausnutzbarkeit, Erreichbarkeit und Auswirkungen.
Hier spielen bekannte, ausgenutzte Sicherheitslücken eine zentrale Rolle. Wenn eine CVE (Crisis Veto Exposure) auftritt, … CISEin Katalog bekannter ausgenutzter Schwachstellen bestätigt, dass Angreifer diese bereits in realen Umgebungen verwenden. Dieses Signal hat deutlich mehr Gewicht als ein theoretischer Wert.
Eine detailliertere Erklärung, was KEVs sind und wie man sie erkennt, können Sie in unserem früheren Beitrag lesen. Bekannte ausgenutzte Sicherheitslücken: Was zuerst behoben werden sollteIn diesem Artikel konzentrieren wir uns darauf, wie KEVs in die Compliance- und Priorisierungsmodelle des Cyber Resilience Act passen.
Was der Cyber Resilience Act wirklich erfordert
Der Cyber Resilience Act ist eine EU-Verordnung, die verbindliche Cybersicherheitsmaßnahmen für Produkte mit digitalen Elementen festlegt, die in der EU verkauft werden. Sie verpflichtet Anbieter, Schwachstellen während des gesamten Produktlebenszyklus zu beheben und die Veröffentlichung von Software mit bekannten, ausgenutzten Sicherheitslücken zu vermeiden. offizielle EU-DokumentationHersteller müssen:
- Identifizieren und beheben Sie Schwachstellen während des gesamten Produktlebenszyklus.
- Verhindern Sie die Auslieferung von Software mit bekannten, ausgenutzten Sicherheitslücken.
- Aktiv ausgenutzte Sicherheitslücken und schwerwiegende Vorfälle müssen innerhalb von 24 Stunden nach Bekanntwerden gemeldet werden; diese Meldepflicht tritt am 11. September 2026 in Kraft.
- Nachweise über den Umgang mit Schwachstellen aufbewahrencisIonen
Mit anderen Worten: Sobald eine Schwachstelle auftritt, CISEin Katalog bekannter ausgenutzter Schwachstellen – dessen Ignorieren birgt sowohl Sicherheits- als auch Regulierungsrisiken, und ab September 2026 ist dieses Risiko mit einer Meldefrist verbunden.
Was ist der Cyber Resilience Act (CRA)?
Das Cyber-Resilienz-Gesetz ist eine EU-Verordnung, die verbindliche Cybersicherheitsanforderungen für in Europa verkaufte Software und digitale Produkte festlegt. Sie verpflichtet Anbieter, Schwachstellen während des gesamten Produktlebenszyklus zu beheben und die Veröffentlichung von Software mit Sicherheitslücken zu vermeiden. bekannte ausgenutzte Schwachstellen.
Checkliste für risikobasiertes Schwachstellenmanagement (CRA Ready)
Warum KEVs für die Einhaltung der CRA-Vorschriften von zentraler Bedeutung sind
Das CISEin Katalog bekannter ausgenutzter Sicherheitslücken (Known Exploited Vulnerabilities Catalog) listet CVEs auf, die Angreifer bereits aktiv ausnutzen. Anders ausgedrückt: Er beseitigt Unklarheiten bei der Priorisierung.
Statt zu fragen „Könnte dies ausgenutzt werden?“, müssen sich die Teams nun eine viel direktere Frage stellen: „Wird dies bereits ausgenutzt, und liefern wir es trotzdem aus?“
Gemäß dem Cyber Resilience Act ist diese Unterscheidung rechtlich relevant. Daher sind KEVs der wichtigste Auslöser für SLAs zur Behebung von Sicherheitslücken und die Sperrung von Releases. In diesem Kontext entspricht risikobasiertes Schwachstellenmanagement den regulatorischen Anforderungen.
Den Aspekt der Vorfallsmeldung haben wir in einer gemeinsamen Sitzung mit Nariman Aga-Tagiyev, Cybersecurity Architect bei SecureHabits.nl, ausführlicher behandelt: 24 Stunden Zeit zum Melden: Die Benachrichtigungsfrist der kanadischen Steuerbehörde (CRA) überstehenEs erläutert den dreistufigen Vorfalllebenszyklus, den die CRA von Organisationen erwartet, von einer gemeldeten Sorge über eine Untersuchung bis hin zu einem bestätigten Vorfall, der das 24-Stunden-Meldefenster auslöst.
CVSS, EPSS und KEVs dienen unterschiedlichen Zwecken.
Um die richtigen Prioritäten zu setzen, müssen die Teams zunächst verstehen, was jedes Signal tatsächlich repräsentiert.
- CVSS zeigt potenziellen Einfluss
- EPSS schätzt die Wahrscheinlichkeit der Ausbeutung ein
- CISEin Katalog bekannter ausgenutzter Sicherheitslücken bestätigt, dass Ausbeutung bereits stattfindet
Für sich genommen kann jede Kennzahl irreführend sein. Nutzen Teams sie jedoch gemeinsam, erhalten sie ein deutlicheres Bild. Daher bildet die Kombination dieser Signale die Grundlage für ein effektives risikobasiertes Schwachstellenmanagement.
Risikobasiertes Schwachstellenmanagement in der Praxis
In der Praxis folgt ein risikobasiertes Priorisierungsmodell einem klaren und wiederholbaren Ablauf.
- Erkennung von Schwachstellen im gesamten Code und seinen Abhängigkeiten
- Überprüfen Sie die Übereinstimmungen mit den CISEin Katalog bekannter ausgenutzter Sicherheitslücken
- Bewerten Sie die Wahrscheinlichkeit einer Ausnutzung mithilfe von EPSS.
- Überprüfen Sie die Erreichbarkeit Ihrer Anwendung oder pipeline
- Wenden Sie Sanierungsregeln basierend auf der Exposition und der Produktrolle an.
Infolgedessen behandeln Teams Schwachstellenlisten nicht mehr als statische Aufgaben, sondern als konkrete Sicherheitsanforderungen.cisIonen.
Verschiedene Priorisierungsmodelle, die Teams heute verwenden
Nicht alle Teams priorisieren Risiken auf die gleiche Weise. Im AllgemeinenIn realen Umgebungen sehen wir drei gängige Modelle.
1. Schweregradorientiertes Modell
Teams beheben Probleme ausschließlich auf Basis von CVSS.
Dieses Modell ist leicht umzusetzen. Es erzeugt jedoch Störungen und erfüllt nicht die Anforderungen des Cyber Resilience Act.
2. Wahrscheinlichkeitsbasiertes Modell
Teams verlassen sich auf EPSS, um vorherzusagen, welche Schwächen Angreifer als Nächstes ausnutzen könnten.
Dieser Ansatz verbessert die Konzentration. Dennoch werden dabei Schwachstellen übersehen, die Angreifer bereits ausnutzen.
3. Ausbeutungsbewusstes Modell
Teams kombinieren EPSS mit dem CISEin Katalog bekannter ausgenutzter Sicherheitslücken und der dazugehörige technische Kontext.
Im Gegensatz dazu unterstützt dieses Modell am besten ein risikobasiertes Schwachstellenmanagement und lässt sich direkt auf die Verpflichtungen des CRA abbilden.
Wie Xygeni die CRA-Ready-Priorisierung operationalisiert
Xygeni hilft Teams, regulatorische Vorgaben in den täglichen Arbeitsablauf zu integrieren. Anstatt sich nur auf Folgendes zu verlassen: dashboards, Xygeni erzwingt decisDie Priorisierung erfolgt genau dort, wo Codeänderungen vorgenommen werden. Dadurch wird sie automatisch und konsistent.
Zu den wichtigsten Funktionen gehören:
- Automatische Korrelation mit der CISEin Katalog bekannter ausgenutzter Sicherheitslücken
- EPSS-basierte Bewertung der Exploit-Wahrscheinlichkeit
- Erreichbarkeitsanalyse zur Bestätigung der tatsächlichen Exposition
- Guardrails Dieser Block führt Zusammenführungen oder Freigaben durch, wenn KEVs erreichbaren Code betreffen.
- Automatisierte Fehlerbehebung durch sichere pull requests
- Vollständige Prüfprotokolle zum Nachweis der Einhaltung des Cyber Resilience Act
Kurz gesagt, die Teams erkennen Risiken nicht nur, sondern handeln auch auf wiederholbare und nachvollziehbare Weise.
Beispiel für Entwickler: KEV blockiert eine Veröffentlichung
Stellen Sie sich vor, ein Abhängigkeitsupdate führt zu einer CVE (Crisis Viable Environment).
- Die Schwachstelle tritt in der CISEin Katalog bekannter ausgenutzter Sicherheitslücken
- Xygeni erkennt es während der pull request
- Die Erreichbarkeitsanalyse bestätigt, dass der Codepfad ausgeführt wird.
- Guardrails Zusammenführung automatisch blockieren
- Der Bot schlägt ein sicheres Upgrade vor und führt Tests durch.
Der Entwickler behebt das Problem im selben Workflow. Die Veröffentlichung bleibt konform. Es sind keine Besprechungen erforderlich.
Mit anderen Worten: Hierbei handelt es sich um risikobasiertes Schwachstellenmanagement, das genau dort angewendet wird, wo Entwickler bereits arbeiten.
Warum dies über die reine Einhaltung von Vorschriften hinaus wichtig ist
Obwohl der Cyber Resilience Act diesen Wandel angestoßen hat, reichen die Vorteile noch weiter. Teams, die der Nutzung von KEVs, EPSS und Kontext Priorität einräumen:
- Reduzieren Sie die Aufmerksamkeitsmüdigkeit
- Verkürzung der Sanierungszeit
- Vermeiden Sie Notfallreparaturen.
- Sicherere Software versenden – mit Zuversicht
Im Großen und Ganzen ist die Einhaltung der Vorschriften eine natürliche Folge davon, wenn man Sicherheit richtig angeht.
Schlussbetrachtung: Die CRA macht risikobasiertes Management verpflichtend
Der Cyber Resilience Act formalisiert, was Sicherheitsteams bereits schmerzlich erfahren mussten: Nicht alle Schwachstellen sind gleich schwerwiegend.
Das CISEin Katalog bekannter ausgenutzter Schwachstellen beschreibt, welche Schwachstellen Angreifer aktuell verwenden. EPSS prognostiziert, welche Schwachstellen sie als Nächstes einsetzen werden. Der Kontext zeigt an, ob Sie betroffen sind.
Zusammen bilden sie das moderne risikobasierte Schwachstellenmanagement, und ab dem 11. September 2026 ist es verpflichtend. Teams, die die Frage „Wird diese Schwachstelle ausgenutzt, und liefern wir sie trotzdem aus?“ bereits beantworten können, werden die Meldefrist der CRA problemlos einhalten können. Teams, die dies nicht können, merken gerade, wie kurz 24 Stunden tatsächlich sind.
Xygeni hilft Teams dabei, dieses Modell kontinuierlich, automatisch und auf eine Weise anzuwenden, die von Entwicklern tatsächlich akzeptiert wird.
Über den Autor
Geschrieben von Fatima SaidContent-Marketing-Manager mit Spezialisierung auf Anwendungssicherheit bei Xygeni-Sicherheit.
Fátima erstellt entwicklerfreundliche, forschungsbasierte Inhalte zum Thema AppSec. ASPMund DevSecOps. Sie übersetzt komplexe technische Konzepte in klare, umsetzbare Erkenntnisse, die Innovationen im Bereich Cybersicherheit mit geschäftlichen Auswirkungen verbinden.
