Die VC-Firma a16z hat gerade ein Diagramm geteilt, das in den letzten Tagen auf X explodiert ist. Das Diagramm zeigt, dass kritische und hohe CVEs bei 21 großen Softwareunternehmen seit Frühjahr 2026 von unter 100 pro Monat auf über 600 pro Monat gestiegen sind. Die Daten stammen von Epoch AI und umfassen Zählungen von Apple, AWS, Microsoft, Google und Adobe.
Und da es sich um X handelt, haben natürlich alle möglichen Leute ihre Meinung kundgetan (ja, wir tun hier dasselbe).
Sie waren in zwei Lager unterteilt. Die einen werteten dies als eine echte Veränderung des Risikos, während die anderen darauf hinwiesen, dass sich bekannte ausgenutzte Schwachstellen (KEV) seit 2024 nicht verändert haben – mehr Offenlegungen bedeuten also nicht zwangsläufig mehr Gefahr.
Selbst der Bericht von a16z räumt dies ein:
„Ob es tatsächlich mehr Schwachstellen gibt oder ob dies auf Änderungen bei der Berichterstattung oder Definition zurückzuführen ist, lässt sich allein anhand des Diagramms nur schwer sagen. Es ist jedoch wahrscheinlich, dass zumindest ein Teil (und vielleicht ein Großteil) dieses parabolischen Wachstums auf eine wesentliche Änderung bei der Entdeckung von Schwachstellen und/oder der Definition dessen zurückzuführen ist, was noch als sicher gilt.“
Aber beide Seiten interpretieren dies völlig falsch. Weder die Gesamtzahl neuer CVEs noch ein konstanter KEV-Wert bestimmen das tatsächliche Risiko. Das Risiko hängt davon ab, wie schnell Sie herausfinden, welche Schwachstellen wichtig sind, und wie schnell sie nach ihrer Validierung behoben werden.
Es ist offensichtlich, dass KI das Aufspüren von Schwachstellen (sowohl für Angreifer als auch für Verteidiger) erheblich vereinfacht hat. Frontmodelle finden Schwachstellen schneller, als Prüfer sie validieren können, darunter auch langjährige Fehler, die jahrelange manuelle Prüfungen überstanden hatten.
Der Anstieg im a16z-Diagramm lässt sich also am besten damit erklären, dass KI das Auffinden bereits vorhandener Fehler beschleunigt hat, und nicht damit, dass Software plötzlich unsicherer geworden ist. Das ist jedoch nur ein Teil der Geschichte.
Was passiert, wenn eine Institution versucht, mit der einfachen Erkennung Schritt zu halten
Das NIST, die von allen als Goldstandard für Schwachstellendaten betrachtete Institution, kämpft bei einem größeren Volumen mit genau demselben Problem. Ausgehend von der Annahme, dass mehr CVEs auch mehr Gefahr bedeuten, hatte das NIST versucht, jede eingehende CVE zu bewerten. Doch das schiere Volumen an CVEs machte dies praktisch unmöglich. Schließlich brach das System zusammen.
Eine Bundesprüfung im Mai ergab, dass der Rückstand innerhalb von achtzehn Monaten von 13.000 auf über 27.000 angewachsen war. Die vorgeschlagene Lösung des NIST? Nicht mehr alles zu bewerten. Stattdessen werden CVEs priorisiert, die mit der Bundesverwaltung, kritischer Software oder der Liste bekannter Exploits von CISA zusammenhängen. Alles andere wird als „nicht eingeplant“ markiert, sodass die Wahrscheinlichkeit hoch ist, dass diese Fälle nicht mehr geprüft werden.
Der Kampf des NIST dreht sich um die Offenlegung und Bewertung von Schwachstellen. Doch selbst bei denjenigen, die diese Hürde komplett nehmen – also bestätigt, bewertet und als aktiv ausgenutzt bekannt sind –, scheint die Fehlerbehebung nach wie vor zu scheitern.
Das eigentliche Nadelöhr ist die Behebung
Der Data Breach Investigations Report 2026 von Verizon, der auf über einer Milliarde Schwachstellendatensätzen basiert, ergab, dass im Jahr 2025 nur 26 % der bestätigten, aktiv ausgenutzten Schwachstellen (auf der KEV-Liste der CISA) vollständig behoben wurden (gegenüber 38 % im Vorjahr). Die mediane Zeit bis zur vollständigen Behebung stieg von 32 auf 43 Tage.
Selbst Organisationen mit den besten Ressourcen beheben im ersten Monat nur 30 bis 40 % dieser Schwachstellen vollständig. Verizon bezeichnet dies als „Remediation-Paradoxon“, was schlicht bedeutet, dass die Zahl der Schwachstellen rasant steigt, während die Behebung langsamer wird.
Es ist bekannt, dass diese Schwachstellen aktiv ausgenutzt werden und auf einer öffentlichen Liste stehen. Dennoch werden sie nach wie vor nicht schnell genug behoben.
Wie eine schnelle Behebung tatsächlich aussieht
Diesen Monat traf eine unauthentifizierte RCE-Schwachstelle namens Stylesmuggler Adobe Commerce und Magento Open Source. Weder gab es dazu eine CVE noch einen Sicherheitshinweis von Adobe.
Eine Schwachstelle benötigt keine CVE-Nummer oder einen Herstellersicherheitshinweis, um real zu sein oder ausgenutzt zu werden. Wer vor dem Handeln auf beides wartet, verschafft Angreifern einen Vorsprung. Der einzige Ausweg besteht darin, sich auf ein System zu verlassen, das Schwachstellen eigenständig finden und bestätigen und sie anschließend schnell beheben kann.
Aikido Intel hat die Schwachstelle unabhängig erkannt, ohne auf Adobe oder eine CVE-Nummer zur Bestätigung ihrer Echtheit zu warten. Sie wurde unter drei verschiedenen Entitäten verfolgt, und Aikido Libraries veröffentlichte einen funktionierenden Fix für mehrere betroffene Versionen. Dieser wurde als AutoFix-Pull-Request direkt in den von Teams bereits verwendeten Workflow integriert, anstatt eine separate, mühsame manuelle Migration erforderlich zu machen. Und das alles, bevor Adobe über 24 Stunden später seinen eigenen Hotfix veröffentlichte.
StyleSmuggle ist jedoch kein Einzelfall. Im ersten Betriebsjahr von Intel wurden 67 % der Pakete, in denen Schwachstellen entdeckt wurden, niemals öffentlich in einer Datenbank offengelegt (weder NVD noch GitHub Advisory noch MITRE noch sonst irgendwo).
Die eigentliche Geschichte lautet also …
Ein steigendes CVE-Volumen ist vergleichbar mit der Anzahl der jährlich veröffentlichten npm-Pakete: Es summiert sich, weshalb die bloße Beobachtung dieses Wachstums im Grunde bedeutungslos ist. Worauf es ankommt, ist, wie schnell eine echte, bestätigte Schwachstelle behoben wird – und im Moment geht das branchenweit einfach nicht schnell genug.
Da KI die Erkennungs- und Ausnutzungsmöglichkeiten kommerzialisiert, muss sich die Cybersicherheit um die Frage drehen, was nach der Entdeckung passiert. Das beginnt damit, zu wissen, welche der auftretenden Schwachstellen tatsächlich erreichbar und ausnutzbar sind. Die Erreichbarkeitsanalyse von Aikido filtert alles heraus, was keinen Ausführungspfad zum anfälligen Code aufweist, und die CVE-Ausnutzbarkeitsanalyse geht noch einen Schritt weiter, indem sie analysiert, wie ein Paket in Ihrer Umgebung tatsächlich verwendet wird, um zu entscheiden, ob eine erreichbare Schwachstelle ein Handeln erfordert.
Aikido führt die Behebung auf zwei Wegen durch. Bei bekannten, patchbaren Problemen kann AutoFix den Fix direkt generieren. Bei Open-Source-Paketen wird genau die Version gepatcht, die bereits in der Lockfile des Teams festgelegt ist, ohne dass ein Upgrade oder eine Migration erforderlich ist. Dasselbe gilt für anfällige Container-Basisbilder und AnwendungsCode. Wenn ein Fix eine menschliche Entscheidung erfordert, wird die Schwachstelle dennoch mit einer spezifischen, umsetzbaren Empfehlung versehen, sodass jemand sofort handeln kann, anstatt erst überlegen zu müssen, was als Nächstes zu tun ist. Der nächste Schritt – dies vollautomatisch bis in die Produktion durchzuführen, ohne auf einen Merge durch einen Menschen zu warten –, ist nicht mehr weit.
Das Finden von Schwachstellen war noch nie so einfach. Jetzt sollte der Fokus darauf liegen, wie Sie die relevanten Schwachstellen vom Rauschen filtern und diese schnell beheben.
