Die meisten Unternehmen gehen nicht pleite, weil jemand einen brillanten Exploit geschrieben hat. Sie gehen pleite, weil jemand eine öffentliche CVE-Beschreibung in Metasploit kopiert und sie auf einen Server gerichtet hat, der seit elf Monaten nicht gepatcht wurde. Die Schwachstelle war bekannt. Der Fix war bekannt. Die Zeit ist einfach abgelaufen.
Dieser Beitrag wirft einen nüchternen Blick auf die Zahlen hinter diesem stillen Zusammenbruch und darauf, was sich an der Rechnung ändert, wenn kontinuierliches Scannen als Infrastruktur behandelt wird und nicht als vierteljährliche Feuerübung.
Das Volumenproblem
Im Jahr 2020 hat die NVD rund 17.000 neue CVE-Einträge erfasst. 2025 überschritt die Zahl 28.961. Das Wachstum ist nicht linear. Es vervielfacht sich, getrieben von zwei Kräften, die sich nicht umkehren lassen: (1) Die Abhängigkeitsgraphen moderner Software werden immer länger, und (2) automatisierte Discovery-Tools (Fuzzer, SAST, LLM-gestützte Code-Reviews) finden Dinge, die Menschen jahrzehntelang übersehen haben.
Für ein Team ohne dedizierte AppSec-Funktion bedeutet das: Der Posteingang mit „Dingen, die Sie wissen sollten“, hat sich in fünf Jahren ungefähr verdoppelt. Die Kosten für die Triage haben sich ebenfalls ungefähr verdoppelt. Die verfügbare Zeit nicht.
Die Patch-Lücke
Die ernüchternde Statistik ist nicht, dass Schwachstellen existieren. Es ist, dass die meisten ausgenutzten Schwachstellen alt sind. Öffentliche Daten der letzten drei Jahre erzählen eine konsistente Geschichte:
| Kennzahl | 2023 | 2024 | 2025 |
|---|---|---|---|
| Median bis zur Veröffentlichung eines CVE-Patches (Anbieter) | 7 Tage | 5 Tage | 4 Tage |
| Median bis zur Anwendung eines CVE-Patches (Kunde) | 102 Tage | 93 Tage | 88 Tage |
| % der Einbrüche, bei denen ein Patch bereits verfügbar war | 71% | 74% | 76% |
| Durchschn. Verweildauer vor Erkennung | 213 Tage | 194 Tage | 187 Tage |
Anbieter werden schneller. Kunden nicht. Die Lücke zwischen „ein Fix existiert“ und „ein Fix ist angewendet“ ist der Ort, an dem moderne Einbrüche stattfinden.
„Der mit Abstand größte Faktor, der Unternehmen unterscheidet, die sich innerhalb von 30 Tagen von einem Einbruch erholt haben, von denen, die es nicht geschafft haben, war, ob sie ein kontinuierliches Inventar ihrer exponierten Abhängigkeiten hatten." ENISA Threat Landscape Report 2025, Executive Summary
Die Pleite-Rechnung
Die Kosten des Nichtstuns sind nicht nur das Bußgeld oder die Kosten der Einbruchsmeldung. Es ist der kumulative Druck, der Unternehmen mit knappen Margen über die Kante drückt.
1. Der Einbruch selbst
Europäischer Mittelstandsdurchschnitt: €4,7 Mio. Dazu gehören Forensik, Rechtsberatung, Kundenbenachrichtigung, System-Neuaufbau und Ausfallzeiten. Reputationsschäden sind nicht eingerechnet.
2. Das Bußgeld
DSGVO Art. 83 begrenzt Bußgelder auf das Höhere von €20 Mio. oder 4 % des weltweiten Jahresumsatzes. Die Durchsetzung ist nicht länger theoretisch: Allein 2025 haben europäische Datenschutzbehörden €2,1 Mrd. an Bußgeldern verhängt, mit einem Median von €340.000 bei Vorfällen im KMU-Maßstab. Diese Zahl steigt, sie fällt nicht.
3. Der Kundenverlust
Studien zu öffentlich gemeldeten Einbrüchen zeigen durchgängig eine 3-7 %ige Umsatzauswirkung im ersten Jahr durch Kundenabwanderung, mit Schwerpunkt im B2B-Bereich, wo vertragliche SLA-Verletzungsklauseln automatische Kündigungen auslösen. Für ein Unternehmen mit knappen Margen ist dieser einzelne Schlag existenzbedrohend.
4. Der Cyberversicherungs-Schlag
Prämien steigen nach einem gemeldeten Vorfall bei der Verlängerung um 30-180 %, und Ausschlüsse werden enger. Einige Versicherer lehnen Unternehmen ab, die auf Anfrage kein 30-Tage-Schwachstellenprotokoll vorlegen können.
Sie müssen nicht perfekt sein. Sie müssen schneller sein als der Median.
Die mediane Time-to-Exploit für eine öffentliche CVE, die Lücke zwischen Veröffentlichung und aktiver Ausnutzung in freier Wildbahn, liegt jetzt bei unter 14 Tagen. Der Kundenmedian zum Patchen liegt bei 88 Tagen. Diese Lücke von 88 auf 14 Tage zu schließen, erfordert keine Sicherheitsabteilung. Es erfordert einen kontinuierlichen Scanner und einen Workflow, der Scan-Ergebnisse in einen Pull Request übersetzt, nicht in eine Slack-Nachricht.
Was wir dagegen tun
CyberDebunk führt kontinuierlich einen Abgleich zwischen zwei beweglichen Zielen durch: einem 300.000-Einträge-Korpus bekannter Schwachstellen und dem Live-Zustand Ihrer Repositories und Cloud-Konten. Der Abgleich läuft alle 60 Sekunden. Wenn eine neue CVE mit einer Abhängigkeit in Ihrem Stack übereinstimmt, passieren drei Dinge parallel:
- Ein Befund wird erstellt mit Schweregrad, Status der Ausnutzung in freier Wildbahn und einer verständlichen Erklärung, was ein Angreifer damit tatsächlich anstellen würde.
- Ein Pull-Request-Entwurf wird geöffnet im betroffenen Repository mit dem minimalen Versions-Bump, dem Diff und dem Changelog. Meistens ist die einzige Entscheidung Ihres Engineers „mergen oder schließen".
- Ein unveränderlicher Audit-Eintrag wird geschrieben, der den Befund Ihrer Compliance-Position zuordnet (z. B. SOC 2, NIS2, DSGVO Art. 32). Dieser Eintrag belegt gegenüber einem Prüfer oder Versicherer, dass Sie das Problem nicht ignoriert haben.
Für Cloud-Konten (AWS, Azure, GCP) prüft dieselbe Pipeline IAM-Konfiguration, öffentliche Exposition, unverschlüsselten Speicher und Abweichungen von Ihrer letzten bekannten guten Baseline. Befunde erscheinen als dieselbe verständliche Warnung, mit Remediation-Schritten, die auf die CLI des Cloud-Anbieters abgebildet sind.
So sieht das in der Praxis aus
Vor einigen Wochen wurde der xz-utils-Backdoor (CVE-2024-3094) an einem Freitagnachmittag öffentlich bekannt gegeben. Unsere Scanner hatten innerhalb von vier Minuten einen Treffer für betroffene Fleet-Versionen. Kunden mit betroffenen Versionen erhielten einen PR-Entwurf und eine E-Mail mit der Erklärung, den betroffenen Services und einer einzeiligen CLI zum Rollback, falls der Patch etwas kaputt gemacht hatte. Die mediane Time-to-Merge für dieses CVE betrug 18 Minuten, Kaffeepause inbegriffen.
Das ist kein Argument für ein Wunderwerkzeug. Die CVE war mit jedem modernen Scanner auffindbar. Das Argument gilt für einen Workflow, in dem die Lücke zwischen „eine CVE existiert“ und „der Fix ist in Produktion“ standardmäßig in Minuten statt Monaten schließt, ohne dass ein Meeting nötig ist.
Was Sie diese Woche tun können, auch ohne uns
- Erfassen Sie jede Abhängigkeit. Wenn Sie nicht jede Third-Party-Bibliothek und jedes Image in Produktion auflisten können, können Sie sich nicht gegen die nächste öffentliche CVE verteidigen.
- Abonnieren Sie anbieterspezifische Advisory-Feeds. Die NVD ist ein Fallback. Die eigene Security-Mailingliste des Anbieters ist meist um Stunden schneller.
- Legen Sie ein 14-Tage-SLA für Patches mit kritischer Schwere fest. Wählen Sie die Zahl, die zu Ihrem Team passt, aber schreiben Sie sie auf. Ungeschriebene SLAs werden nie eingehalten.
- Führen Sie ein Audit-Protokoll über Schwachstellenentscheidungen. Wenn Sie sich gegen ein Patchen entscheiden (veraltete Komponente, keine Exposition usw.), dokumentieren Sie die Begründung. Dieses Dokument ist der Unterschied zwischen „fahrlässig“ und „dokumentierter Risikoakzeptanz“ in einer Versicherungs- oder Regulierungsprüfung.
Die gute Nachricht: Das ist ein lösbares Problem. Anbieter patchen schneller. Tools werden besser im Abgleich. Die verbleibenden Kosten sind operativ: Jemand muss hinschauen, entscheiden und mergen. Genau das automatisieren wir.