Steigende CVE-Zahlen im kleinen Team bewältigen

Was sich geändert hat: die CVE-Zahlen

Die folgenden Zahlen stammen aus den eigenen Einträgen des CVE Program und werden täglich auf unserer Seite CVE-Veröffentlichungstrends neu berechnet. Stand des Snapshots: 12.11.2026 UTC.

• 47.801 Einträge wurden 2025 veröffentlicht, 20 % mehr als im Vorjahr.
• 95.494 Einträge wurden 2026 bisher veröffentlicht, 303 pro Tag, +131 % gegenüber der Tagesrate von 2025.
• 155 pro Tag sind als hoch oder kritisch eingestuft.
• 17 % aller Einträge seit 2020 haben keinen CVSS-Wert, weder vom Assigner noch aus der Anreicherung durch CISA. Die Abdeckung hat sich verbessert: 2026 liegt der Anteil bei 6 %.
• 505 Organisationen haben diese Einträge vergeben, und die 20 größten davon stehen für 75 %.

• Hoch oder kritisch
• Andere Schweregrade und ohne Bewertung

1. 39 2020
2. 54 2021
3. 68 2022
4. 78 2023
5. 109 2024
6. 131 2025
7. 303 2026*

Tagesdurchschnitt der in jedem Jahr veröffentlichten Einträge; * kennzeichnet das laufende Jahr bis heute. Quelle: die cvelistV5-Einträge des CVE Program, Snapshot 12.11.2026 UTC. Filter nach Monat, Schweregrad und Assigner: CVE-Veröffentlichungstrends.

Das ist kein schlechtes Quartal. Die Zahl ist seit 2020 jedes Jahr gestiegen, und mehrere strukturelle Veränderungen lassen sie weiter steigen:

• Mehr Assigner, die breiter vergeben. Das Linux-Kernel-Projekt wurde im Februar 2024 zur CVE Numbering Authority. Seine dokumentierte Richtlinie: Jeder Bugfix, der eine Schwachstelle sein könnte, bekommt eine CVE, sobald der Fix einen stabilen Kernel erreicht, weil die Ausnutzbarkeit beim Einspielen eines Fixes oft unklar ist. Allein die Kernel-CNA hat seitdem 18.221 Einträge veröffentlicht.
• KI-gestützte Entdeckung. Im November 2024 meldeten Googles Project Zero und DeepMind, dass ihr Agent Big Sleep einen ausnutzbaren Speichersicherheitsfehler in SQLite gefunden hatte, bevor er in ein Release gelangte. Nach ihrer Einschätzung war das das erste öffentliche Beispiel eines KI-Agenten, der so etwas in weit verbreiteter Software schafft. Solche Tools erhöhen, wie viel ein einzelner Forscher finden kann.
• Die NVD kann nicht mehr alles anreichern. Laut NIST hat die National Vulnerability Database ab Anfang 2024 einen Rückstau nicht angereicherter CVEs aufgebaut und konnte ihn nicht abbauen, weil die Einreichungen weiter stiegen. Im April 2026 stellte sie auf ein risikobasiertes Modell um: CVEs im Known-Exploited-Vulnerabilities-Katalog von CISA und CVEs in Bundes- oder kritischer Software werden zuerst angereichert, der Rest wird als nicht für die sofortige Anreicherung vorgesehen geführt. Ein Prozess, der sich auf die Produktdaten einer einzigen Datenbank verlässt, wartet jetzt oder übersieht etwas.
• Weniger Zeit zum Reagieren. Mandiant maß 2018 und 2019 eine durchschnittliche Time to Exploit von 63 Tagen. Der Bericht M-Trends 2026 schätzt für 2025 minus sieben Tage: Die Ausnutzung beginnt inzwischen regelmäßig, bevor ein Patch veröffentlicht ist.
• Regulatorische Fristen. Nach dem EU Cyber Resilience Act melden Hersteller eine aktiv ausgenutzte Schwachstelle mit einer Frühwarnung innerhalb von 24 Stunden, einer Meldung innerhalb von 72 Stunden und einem Abschlussbericht innerhalb von 14 Tagen, nachdem ein Fix verfügbar ist (was der CRA verlangt). Die Frist ist für ein Team aus drei Personen dieselbe wie für eines aus dreihundert.

Nichts davon bedeutet, dass Software unsicherer wird. Es bedeutet, dass die Zahl der Dinge, die sich ein Team ansehen muss, jedes Jahr wächst, das Team aber nicht.

Wo der Prozess eines kleinen Teams bricht

Steigende Zahlen bringen das Schwachstellenmanagement nicht deshalb ins Wanken, weil mehr Schwachstellen zu beheben sind. Sondern weil sich jeder manuelle Schritt für jede CVE wiederholt.

Manueller Schritt	Warum er beim heutigen Volumen scheitert
Das Inventar von Hand pflegen	Eine Tabelle oder eine SBOM, die vor einem Audit erstellt wurde, ist am Tag nach dem nächsten Release veraltet.
Den Feed lesen	Bei 155 hohen oder kritischen Einträgen pro Tag kommt niemand hinterher.
Die Entwicklung fragen: „Nutzen wir X?“	Dieselbe Frage bei jeder CVE, an dieselben ausgelasteten Leute. Die Frage selbst ist der Engpass.
Ein Ticket pro CVE und Repository	Aus der CVE einer gemeinsam genutzten Bibliothek werden Dutzende doppelte Tickets, die das Backlog fluten.
Jedem Kunden einzeln antworten	Anfragen wachsen mit dem Kundenstamm, nicht mit der Zahl der Schwachstellen.
Dokumente als PDF oder im Wiki	Die Tools der Kunden können ein PDF nicht mit ihrem Inventar abgleichen, also fragt jeder Leser erneut.
Fristen, die sich nicht verschieben	Die Time to Exploit schrumpft, während ein manueller Prozess mit wachsendem Volumen langsamer wird.

Das Inventar. Die meisten Teams, die eine Komponentenliste von Hand führen, aktualisieren sie vor einem Audit oder einem Kundenfragebogen. Dazwischen beschreibt sie Software, die nicht mehr ausgeliefert wird. Jede CVE-Frage beginnt dann damit, zu rekonstruieren, was das Release enthielt.

Der Feed. Advisories zu lesen ist der Schritt, mit dem Teams anfangen, und der erste, der zusammenbricht. Wir hören von Teams, die das noch von Hand tun, darunter eines, bei dem Schwachstellenscans bedeuten, dass Menschen CVE-Foren lesen. Das funktioniert bis zu dem Tag, an dem es nicht mehr funktioniert, und für diesen Tag gibt es kein Signal.

Die Frage an die Entwicklung. „Nutzen wir diese Bibliothek, und in welcher Version?“ unterbricht bei jeder CVE, die zutreffen könnte, einen Entwickler. Ein Product-Security-Team aus zwei Personen erzählte uns, seine Arbeit bestehe nur noch aus Knöpfedrücken, um hinterherzukommen, ohne Zeit, den Prozess zu verbessern.

Die Tickets. Wenn eine gemeinsam genutzte Bibliothek eine CVE hat und jedes Repository ein eigenes Ticket öffnet, zählt das Backlog dieselbe Entscheidung viele Male. Teams lernen, das Backlog zu ignorieren, und übersehen dann das Ticket, auf das es ankam.

Die Antworten an Kunden. Nach einer breit berichteten Schwachstelle oder einem Supply-Chain-Angriff fragen Kunden: „Sind wir betroffen?“ Jedem einzeln zu antworten kostet am meisten Zeit an dem Tag, an dem es am wenigsten davon gibt.

Die Dokumente. Eine PDF-Erklärung oder eine Wiki-Seite muss auf Kundenseite von einem Menschen gelesen werden. Die Scanner der Kunden, und zunehmend Regulierungsbehörden, erwarten SBOMs, VEX und Advisories in Formaten, die eine Maschine abgleichen kann.

Die Fristen. Eine Frühwarnung, die innerhalb von 24 Stunden fällig ist, oder ein Exploit, der vor dem Patch erscheint, wartet nicht, bis die Warteschlange abgearbeitet ist.

Was Sie automatisieren sollten, in dieser Reihenfolge

Jeder Schritt nimmt dem nächsten Arbeit ab, daher zählt die Reihenfolge mehr als die Wahl der Tools.

1. Wissen, was Sie ausliefern. Eine SBOM aus jedem Build macht aus „Sind wir betroffen?“ ein Nachschlagen.
2. Kontinuierlich abgleichen, mit mehr als einer Quelle. Neue CVEs werden mit jeder gespeicherten SBOM abgeglichen, sodass niemand den Feed liest.
3. Die Alarmflut eindämmen. Befunde zu Dingen, die Sie nicht ausliefern, und Duplikate erreichen nie einen Menschen.
4. Halbautomatisch triagieren. Die Fakten sind ausgefüllt; ein Mensch trifft die Entscheidung.
5. Alles maschinenlesbar machen. Jede Entscheidung wird einmal getroffen und von jedem Leser wiederverwendet.
6. Einmal öffentlich antworten. Die Anfrage, die nie eintrifft, kostet nichts.

1. Für jeden Build automatisch eine SBOM erzeugen

Was es ersetzt: die Tabelle und die Frage an die Entwicklung. Eine beim Build erzeugte SBOM beschreibt, was der Build tatsächlich verwendet hat. Wenn Sie für jede ausgelieferte Version eine aufbewahren, können Sie für das Release vom letzten Jahr genauso antworten wie für main. Kunden betreiben alte Versionen; Ihr Inventar muss sie abdecken.

Minimalversion: eine in der CI erzeugte SBOM für jeden Release-Build, gespeichert neben dem Release-Artefakt. Besser: eine SBOM, die aus dem Build selbst aufgezeichnet und nicht nachträglich aus Lockfiles abgeleitet wird, sodass auch Komponenten darin stehen, die außerhalb des Paketmanagers geladen wurden (Build-Time-SBOMs, SBOM-Automatisierung).

Aufwand: ein oder zwei Tage Pipeline-Arbeit für die Minimalversion, danach nichts mehr pro Release. Woran Sie sehen, dass es funktioniert: Für jedes Release können Sie die Komponenten auflisten, ohne jemanden zu fragen.

2. Kontinuierlich mit mehreren Schwachstellenquellen abgleichen

Was es ersetzt: das Lesen des Feeds. Abgleichen ist Aufgabe einer Maschine: jede neue CVE mit jeder gespeicherten SBOM, nicht nur mit der SBOM des Builds, der gerade gelaufen ist. Ein altes Release, das bei der Auslieferung sauber war, ist an dem Tag betroffen, an dem eine CVE für eine seiner Komponenten veröffentlicht wird.

Eine Quelle reicht nicht. Durch den Anreicherungsrückstau der NVD kommen Daten zu betroffenen Produkten spät oder gar nicht. Ökosystem-Advisories wie die GitHub Advisory Database und OSV sind oft schneller und geben in den Begriffen des jeweiligen Ökosystems an, welche Paketversionen betroffen sind. Die EU Vulnerability Database der ENISA ergänzt den EU-Kontext.

Minimalversion: ein geplanter Job, der jede gespeicherte SBOM täglich gegen eine aggregierte Quelle neu prüft und neue Treffer meldet. Woran Sie sehen, dass es funktioniert: Sie erfahren, dass ein Release betroffen ist, bevor ein Kunde es Ihnen sagt. Wie das in CRACI aussieht, zeigt die Schwachstellenverfolgung.

3. Die Alarmflut eindämmen, bevor jemand hinsieht

Was es ersetzt: die manuelle Prüfung von Befunden, die keine Rolle spielen. Der größte Teil der Alarmflut entsteht vorgelagert: durch Inventare, die Dinge auflisten, die Sie nicht ausliefern, durch mehrere Tools, die dieselbe CVE melden, und durch Abhängigkeiten, die niemand braucht. Korrigieren Sie das Inventar, zählen Sie jeden Befund einmal nach Package URL (PURL), Version und CVE, liefern Sie weniger Abhängigkeiten aus, und ergänzen Sie dann Kontext zur Ausnutzbarkeit aus CISA KEV, EPSS und VEX. Alarmflut bei Schwachstellen reduzieren geht diese Hebel einzeln durch. Woran Sie sehen, dass es funktioniert: Die Befunde pro ausgeliefertem Release sinken, und die Gründe sind dokumentiert.

4. Halbautomatisch triagieren

Was es ersetzt: einen Menschen, der für jeden Befund die Fakten zusammenträgt. Teilen Sie die Arbeit genau auf:

• Automatisch: Schweregrad, ob eine Ausnutzung bekannt ist, welche Produkte und Versionen die Komponente enthalten, das zuständige Team, eine vorgeschlagene Priorität und ein Fälligkeitsdatum.
• Menschlich: die Entscheidung. Beheben, abmildern, mit Ablaufdatum akzeptieren oder mit Begründung als nicht betroffen markieren.

Was sich nicht gefahrlos automatisieren lässt: einen Befund ohne dokumentierten Grund als nicht betroffen zu schließen. Das ist Unterdrückung, und sie kommt bei einem Audit oder einem Vorfall wieder hoch. Regeln für die Rangfolge behandelt die Seite Schwachstellen priorisieren.

Minimalversion: 15 Minuten am Tag für eine Warteschlange, die bereits sortiert und ausgefüllt ist. Woran Sie sehen, dass es funktioniert: Jede Entscheidung hat einen dokumentierten Grund, und nichts wartet darauf, dass jemand etwas nachschlägt.

5. Alles maschinenlesbar machen

Was es ersetzt: PDFs, Wiki-Seiten und E-Mails, die ein Mensch lesen muss. Veröffentlichen Sie SBOMs in CycloneDX oder SPDX (CycloneDX vs. SPDX), Entscheidungen zu „nicht betroffen“ als VEX und Advisories in CSAF. Die Scanner der Kunden und Regulierungsbehörden können sie dann ohne einen Menschen verarbeiten, sodass jede Entscheidung einmal getroffen und von allen wiederverwendet wird, die fragen.

Minimalversion für ein kleines Team: SBOMs und VEX auf Anfrage, von einem festen Ort; CSAF, sobald Kunden danach fragen. Woran Sie sehen, dass es funktioniert: Die Tools der Kunden markieren nicht mehr, was Sie bereits beantwortet haben.

6. Einmal öffentlich antworten

Was es ersetzt: einen E-Mail-Verlauf pro Kunde. Veröffentlichen Sie für jede relevante CVE ein Advisory oder eine Statusseite mit den betroffenen und den behobenen Versionen, und halten Sie eine Antwortvorlage bereit, die darauf verlinkt. Der Leitfaden „Sind wir von dieser CVE betroffen?“ beantworten zeigt, wie Sie die Antwort ermitteln. Für die Antwort selbst bietet wie Sie Kunden nach einem Lieferkettenangriff antworten Antwortvorlagen. Die günstigste Anfrage ist die, die nie eintrifft. Woran Sie sehen, dass es funktioniert: Die meisten Anfragen werden mit einem Link beantwortet.

Dann beheben

Automatisierte Pull Requests für Abhängigkeits-Updates halten die Routinearbeit in Gang; bündeln Sie sie pro Woche oder pro Release, damit das Review überschaubar bleibt. Ein Upgrade eines einzigen vorgelagerten Pakets beseitigt oft mehrere verwundbare transitive Abhängigkeiten auf einmal und ist günstiger, als jede einzeln zu patchen (automatisierte Schwachstellenbehebung). Verhindern Sie dann mit Policy Gates, die den Build stoppen, dass neue bekannt verwundbare Komponenten zurückkommen.

Ein Plan nach Teamgröße

Die Stundenangaben sind Schätzungen zur Planung, keine Benchmarks.

	Eine Person, in Teilzeit	Eine Security- oder PSIRT-Funktion mit 2 bis 5 Personen	Ein größeres Team
Zuerst automatisieren	Schritte 1 und 2: eine SBOM pro Build und kontinuierlicher Abgleich	Schritte 1 bis 3, dann die Zuweisung an Zuständige in Schritt 4	Alle sechs, mit Policy Gates in jeder Pipeline
Bleibt manuell	Die Entscheidung zu jedem hohen oder kritischen Befund; Antworten an Kunden aus einer Vorlage	Entscheidungen, VEX-Begründungen, Advisories für relevante CVEs	Entscheidungen, Ausnahmen und der Prozess selbst
Wöchentlicher Aufwand, zur Veranschaulichung	2 bis 4 Stunden	4 bis 8 Stunden pro Person	Bestimmt durch die Menge der Entscheidungen, nicht durch den Feed

Wenn Sie bereits ein PSIRT betreiben, gilt dieselbe Reihenfolge; das vollständige Prozessmodell finden Sie im Lebenszyklus des Schwachstellenmanagements. Wie Sie die Kundenanfragen bewältigen, die mit jeder CVE zunehmen, beschreibt ein PSIRT skalieren.

Woran Sie erkennen, dass es funktioniert

• Die Zeit von der Veröffentlichung einer CVE bis „betroffen“ oder „nicht betroffen“, pro Produkt.
• Der Anteil der Kundenanfragen, die mit veröffentlichtem Material beantwortet werden.
• Befunde pro ausgeliefertem Release, nicht pro Scan.
• Der Anteil der Entscheidungen mit dokumentiertem Grund.
• Die Stunden pro Woche für Schwachstellenarbeit, und ob sie sinken.

Messen Sie zuerst Ihre eigene Ausgangslage. Für diese Werte gibt es keine verlässlichen Branchen-Benchmarks, und wir nennen keine.

Einstellen, kaufen oder den Prozess ändern?

• Stellen Sie ein, wenn die Arbeit darin besteht, Schwachstellen in Ihrem eigenen Code zu beheben, oder wenn kundennahe Security-Arbeit Urteilsvermögen verlangt.
• Kaufen Sie Tools für die Schritte, die sich pro CVE wiederholen: Schritte 1, 2, 3 und 5.
• Ändern Sie den Prozess bei Zuständigkeiten und Fristen: wer entscheidet, und bis wann.

Seien Sie beim letzten Punkt ehrlich. Ein Tool ohne Verantwortlichen erzeugt ein Dashboard, das niemand liest.

Wo CRACI ins Spiel kommt

CRACI automatisiert die Schritte 1 und 2 sowie Teile der Schritte 3 und 4 für Software, die in GitHub Actions gebaut wird. Es ersetzt Ihre GitHub-hosted Runner und zeichnet bei jedem Job die Pakete auf, die der Job tatsächlich geladen hat, einschließlich Paketen, die aus CI-Caches wiederhergestellt wurden, und versteckter Abhängigkeiten, die in keinem Lockfile stehen.

• Eine SBOM aus jedem Build. Die SBOM jedes Jobs identifiziert jede Komponente per PURL und trägt einen Vollständigkeitsstatus, sodass Sie wissen, wenn etwas nicht erfasst werden konnte. Die Build-Historie bewahrt jeden vergangenen Build mit seiner SBOM auf, sodass Sie sehen, welche Builds eine verwundbare Abhängigkeit enthielten, direkt oder transitiv.
• Kontinuierlicher Abgleich. Überwachte SBOMs werden fortlaufend neu bewertet, und Befunde werden über Builds und Repositories hinweg zusammengefasst, sodass die CVE einer gemeinsam genutzten Bibliothek als ein Problem erscheint, nicht als vierzig.
• Benachrichtigungen und Gates. CRACI benachrichtigt die zuständigen Personen über eine Schwachstelle und ihren Schweregrad, und Policy Gates können einen Build in Echtzeit stoppen, auch einen Build, der eine bestimmte CVE enthält.
• Triage und Zuweisung. Security-Teams triagieren Befunde in CRACI und leiten jeden Befund an das Team weiter, das für den Fix zuständig ist.
• Maschinenlesbare SBOMs. SBOMs lassen sich als CycloneDX oder SPDX exportieren, und CRACI unterstützt VEX.

CRACI veröffentlicht keine Advisories, bietet keine Erreichbarkeitsanalyse und scannt nicht Ihren eigenen Code. Berechnet werden nur Build-Minuten: $0.002 pro vCPU-Minute ($0.004 für einen Standard-Runner mit 2 vCPUs), sekundengenau abgerechnet, ohne Monatsgebühr, ohne Kosten pro SBOM und derzeit ohne Lizenzgebühr. Siehe Preise.

Automatisieren Sie die ersten beiden Schritte noch heute: Lassen Sie Ihre Builds auf CRACI laufen. Vor der allgemeinen Verfügbarkeit nehmen wir jedes Team persönlich in Betrieb.

Wann CRACI nicht die Antwort ist

• Ihre Software wird nicht in GitHub Actions gebaut. GitLab CI und Jenkins sind auf der Roadmap.
• Ihr Risiko liegt vor allem in der Infrastruktur: Server, Endgeräte und Cloud-Konfiguration. Dafür passen Tools für das Schwachstellenmanagement von Infrastruktur besser.
• Sie integrieren Firmware von Dritten, die Sie nicht selbst bauen. Dafür passen Tools zur Binäranalyse besser.
• Ihr Backlog besteht überwiegend aus echten, ausnutzbaren Befunden in Ihrem eigenen Code. Das ist ein Problem der Behebungskapazität, kein Automatisierungsproblem.

Automatisierung des Schwachstellenmanagements: häufige Fragen

Warum gibt es heute so viel mehr CVEs?

Mehr Organisationen vergeben CVEs, und manche vergeben sie breit: Der Linux-Kernel wurde 2024 zur CVE Numbering Authority und vergibt eine CVE für jeden Bugfix, der eine Schwachstelle sein könnte. KI-gestützte Tools finden mehr Fehler pro Forscher. 2025 wurden 47.801 Einträge veröffentlicht, und 2026 liegt bei 303 pro Tag. Der Trend hält seit Jahren an.

Wie kann ein kleines Team mit neuen CVEs Schritt halten?

Indem es sie nicht liest. Erzeugen Sie für jeden Build eine SBOM, gleichen Sie neue CVEs automatisch mit jeder gespeicherten SBOM ab, dämmen Sie die Alarmflut ein, und lassen Sie Menschen nur über den Rest entscheiden. Ein kleines Team hält Schritt, indem es die Schritte streicht, die sich für jede CVE wiederholen, nicht indem es schneller arbeitet.

Was sollten wir im Schwachstellenmanagement zuerst automatisieren?

Das Inventar: eine in der CI erzeugte SBOM für jeden Release-Build, gespeichert mit dem Release. Jeder spätere Schritt hängt davon ab, und es macht aus „Sind wir betroffen?“ statt einer Frage an die Entwicklung ein Nachschlagen. Der kontinuierliche Abgleich mit diesen SBOMs kommt an zweiter Stelle.

Brauchen wir ein Security-Team für den Umgang mit Schwachstellen?

Nicht für den Anfang. Eine Person, die den Prozess in Teilzeit verantwortet, kann ihn betreiben, wenn Inventar, Abgleich und die Eindämmung der Alarmflut automatisiert sind. Sie brauchen eher einen benannten Verantwortlichen und Fristen als ein Team. Stellen Sie ein, sobald die Arbeit im Beheben Ihres eigenen Codes oder in kundennaher Security-Arbeit besteht.

Wie erfahren wir, welche neuen CVEs unser Produkt betreffen?

Bewahren Sie für jede ausgelieferte Version eine SBOM auf und prüfen Sie alle erneut, sobald neue CVEs veröffentlicht werden, mit mehr als einer Schwachstellenquelle. Eine CVE betrifft Sie, wenn sie zu einer Komponente und Version passt, die Sie tatsächlich ausliefern. Kontext zur Ausnutzbarkeit und VEX sagen dann, ob sie relevant ist.

Was bedeutet „maschinenlesbar“ bei SBOMs, VEX und Advisories, und warum ist das wichtig?

Es bedeutet ein standardisiertes, strukturiertes Format, das ein Tool verarbeiten kann: CycloneDX oder SPDX für SBOMs, VEX für Aussagen zu „nicht betroffen“, CSAF für Advisories. Der Scanner eines Kunden kann sie mit seinem Inventar abgleichen, ohne dass jemand sie liest, sodass eine einmal getroffene Entscheidung von jedem Kunden und jedem Tool wiederverwendet wird.

Wie viel der Triage lässt sich gefahrlos automatisieren?

Das Zusammentragen der Fakten: Schweregrad, Ausnutzungsstatus, welche Produkte und Versionen die Komponente enthalten, der Verantwortliche, eine vorgeschlagene Priorität und ein Fälligkeitsdatum. Die Entscheidung selbst sollte bei einem Menschen bleiben. Schließen Sie einen Befund nie automatisch ohne dokumentierten Grund als nicht betroffen.

Wie viel Zeit haben wir, um auf eine kritische CVE zu reagieren?

Weniger, als die meisten Prozesse annehmen. Mandiants M-Trends 2026 schätzt die durchschnittliche Time to Exploit für 2025 auf minus sieben Tage, also eine Ausnutzung, bevor ein Patch existiert. Nach dem EU Cyber Resilience Act braucht eine aktiv ausgenutzte Schwachstelle eine Frühwarnung innerhalb von 24 Stunden. Legen Sie Ihre eigene Frist nach Schweregrad und Ausnutzung fest, und messen Sie sich daran.