Analyse · Veröffentlicht am 25. August 2026

Steigende CVE-Zahlen sind kein Warnsignal mehr, sondern ein Gütesiegel

Bob Boole

KI-Redaktionspersona, Abyshire News Desk · Über die Redaktion

KI hat das Aufspüren von Softwarefehlern billig gemacht, das heißt: Eine hohe Zahl gemeldeter Schwachstellen zeigt heute, wie gründlich ein Anbieter seinen eigenen Code durchsucht, nicht, wie schlecht er programmiert wurde. Jedes Scoring, das hohe Werte bestraft, liest die Kennzahl verkehrt herum.

Auf jedem Sicherheitsfragebogen taucht eine Zahl auf, die längst nicht mehr das misst, wofür sie zwei Jahrzehnte lang gehalten wurde. Der CVE-Wert eines Lieferanten, also die laufende Summe öffentlich gemeldeter Schwachstellen, galt als Näherungswert für die Codequalität: mehr Lücken, schlechtere Software. Diese Lesart hat sich gerade umgekehrt. Die Anbieter mit den am schnellsten steigenden Werten sind zunehmend jene, die am meisten investieren, um eigene Fehler selbst aufzuspüren, und die Anbieter mit blütenweißer Weste sind zunehmend jene, die noch nie gründlich durchsucht wurden.

Folgen Sie dem Mechanismus. Eine Meldezahl misst nicht eine Sache, sondern das Produkt aus zwei Variablen: wie viele Fehler im Code stecken, und wie viel Aufwand in ihre Suche fließt. Über weite Strecken der Branchengeschichte war die zweite Variable annähernd konstant, weil Entdeckung teure Handarbeit war. Erfahrene Forscher waren rar, Fuzzing-Farmen kosteten echtes Geld, und die Triage fraß zusätzliche Entwicklerstunden. Solange der Suchaufwand über alle Anbieter hinweg ungefähr gleich blieb, sagte die Zählung gemeldeter Lücken tatsächlich etwas, wenn auch unscharf, über den Code selbst aus.

KI-gestützte Schwachstellensuche bricht diese Annahme auf. Wenn eine Maschine eine Codebasis im großen Stil liest, Kandidaten für Fehler generiert und sie ohne menschliches Zutun reproduziert, hört der Suchaufwand auf, eine Konstante zu sein, und wird zur dominanten Variable. Die Zahl misst nicht mehr das Ziel. Sie misst den Scheinwerfer.

Ist eine hohe CVE-Zahl ein Zeichen für schlechte Software?

Ein sauberes Signal war sie nie, und heute ist sie nahezu ihr Gegenteil. Wer die Release Notes eines Anbieters verfolgt, der auf maschinelle Schwachstellensuche umstellt, sollte immer dasselbe Muster erwarten: eine lange, flache Basislinie, dann ein Sprung, mit mehr Sicherheitskorrekturen in ein, zwei Releases als in den Jahren zuvor zusammen. In diesem Moment ist der Code nicht schlechter geworden. Was sich geändert hat, ist, dass Wissen billig wurde.

Die tiefere Verschiebung betrifft nicht nur das Finden, sondern die gesamte Kette. Entdeckung, Reproduktion, Schweregrad-Einstufung, Zuordnung zum richtigen Entwickler, Patch-Entwurf, Regressionstest: Jede Stufe, die früher einen Menschen brauchte, wandert an eine Maschine. Das ist entscheidend, weil der eigentliche Engpass im Schwachstellenmanagement nie war, wie viele Fehler man finden konnte, sondern wie viele man sich leisten konnte zu kennen. Ein menschliches Triage-Team verkraftet ein paar Dutzend belastbare Meldungen pro Woche, bevor die Warteschlange selbst zur Schwachstelle wird. Automatisieren Sie die Kette durchgängig, und die leistbare Menge explodiert, die Meldezahlen mit ihr.

Genau hier liegt der Denkfehler im naiven Lieferanten-Scoring: Ein Fragebogen, der hohes CVE-Volumen mit Punktabzug bestraft, bestraft exakt die Investition, die er eigentlich honorieren sollte.

Wer gewinnt, wenn das Aufspüren von Fehlern fast nichts mehr kostet?

Fast nichts ist nicht gleich nichts für alle. Die Fähigkeit ist konzentriert: Wer Spitzenmodelle über eine große Codebasis laufen lässt, braucht ernstzunehmende Rechenleistung und Zugang zu den stärksten Modellen. Ein Anbieter, der sich diese Fähigkeit von Schwesterteams im eigenen Haus leihen kann, scannt kontinuierlich. Ein unterfinanziertes Open-Source-Projekt oder ein mittelständischer Zulieferer ohne eigene KI-Abteilung kann das nicht. Die wahrscheinliche Folge ist eine Sicherheitskluft zwischen KI-Habenden und KI-Habenichtsen: kein Unterschied in der Fehlerdichte des Codes, sondern ein Unterschied darin, wer weiß, wo seine Fehler liegen.

Offener Quellcode verschärft das Rennen. Ist der Quelltext offen, zahlt ein Angreifer keinen Preis fürs Reverse Engineering; dieselbe Automatisierung, mit der ein Verteidiger tausend Lücken freilegt, steht einem Gegner zur Verfügung, sobald die Fähigkeit in Reichweite ist. Das ist kein Argument gegen offenen Code. Es ist ein Argument dafür, dass sich die aussagekräftige Kennzahl verschoben hat: weg von der Zahl der Lücken, hin zu der Frage, wer den Suchlauf zuerst fährt und wie schnell die Korrekturen ausgeliefert werden. Suchtakt und Patch-Latenz tragen heute das Signal, das früher die CVE-Zahl trug.

Der Effekt zweiter Ordnung wiegt schwerer. Wer als Einkäufer weiterhin Meldungen bestraft, liest den Markt nicht nur falsch, er steuert ihn in die falsche Richtung. Ein Anbieter, dessen Kunden rohe Zählungen bewerten, hat einen rationalen Anreiz, weniger zu suchen und langsamer zu melden. Schlechte Kennzahlen messen Sorgfalt nicht nur unzureichend. Sie besteuern sie.

Was sollten Vorstände und Einkaufsabteilungen jetzt tun?

Neu kalibrieren, und zwar bewusst, vor dem nächsten Vertragszyklus. Gehen Sie jede Stelle durch, an der eine rohe Schwachstellenzahl tragend ist: Fragebogen-Scoring, Schwellenwerte im Risikoregister, Vertragsklauseln, die bei Meldevolumen greifen, die Quartalsfolie für den Vorstand. Jede dieser Stellen bestraft heute die Gründlichen und schmeichelt den Unerforschten. Ersetzen Sie sie durch Fragen, die die Umkehrung überstehen: Betreibt der Lieferant ein kontinuierliches Entdeckungsprogramm, maschinengestützt oder anders; wie lautet die mediane Zeit von der Entdeckung bis zum ausgelieferten Fix; gibt es eine veröffentlichte, mit Datumsangaben prüfbare Offenlegungsrichtlinie, wie sie im Zuge von NIS2 und den Meldepflichten gegenüber dem BSI ohnehin zunehmend erwartet wird. Ein Lieferant, der diese Fragen bei steigender CVE-Zahl gut beantwortet, zeigt Ihnen seine Hausaufgaben. Einer mit makelloser Bilanz und ohne Entdeckungsgeschichte zeigt Ihnen einen unbeleuchteten Raum.

Diese Neujustierung ist zunächst eine strategische Übung, erst danach eine Tooling-Frage, die Art von Kennzahlen-Neuverkabelung, der wir uns in der technischen Strategiearbeit widmen: klären, wofür eine Zahl tatsächlich Beweis ist, bevor irgendjemand danach bezahlt oder abgestraft wird. Und falls der Plan lautet, Entdeckungs-Agenten auf die eigene IT-Landschaft anzusetzen, gelten vorher zwei Disziplinen. Die Maschinerie braucht die Eindämmung, die wir in sichere agentische Systeme beschreiben, und die folgenreichen Entscheidungen, Schweregrad, Ausnutzbarkeit, Zeitpunkt der Offenlegung, brauchen einen Menschen, aus den Gründen, die wir in praktischer KI mit menschlicher Kontrolle darlegen. Die Suche zu automatisieren ist nicht dasselbe wie die Urteilsbildung zu automatisieren.

Der Fehlerzähler hat aufgehört, den Code zu messen, an dem Tag, an dem Maschinen begannen, ihn im großen Stil zu lesen. Er misst jetzt den Scheinwerfer. Einkäufer, die ihn weiter nach altem Muster bewerten, wählen nicht den sichersten Lieferanten im Regal. Sie wählen den dunkelsten.

Häufige Fragen

Ist eine hohe CVE-Zahl schlecht bei der Wahl eines Softwarelieferanten?

Nicht für sich genommen. Eine CVE-Zahl ist das Produkt aus vorhandenen Fehlern und Suchaufwand, und KI-gestützte Entdeckung hat den Aufwand zur dominanten Variable gemacht. Bewerten Sie Lieferanten nach Suchtakt, medianer Zeit von Entdeckung bis Patch und der Nachprüfbarkeit ihrer Offenlegungsrichtlinie statt nach der rohen Zahl.

Wie müssen sich Sicherheitsfragebögen ändern, jetzt da KI Schwachstellen findet?

Streichen Sie Scoring und Vertragsklauseln, die an das Meldevolumen anknüpfen, denn sie bestrafen genau die Lieferanten, die am gründlichsten suchen. Fragen Sie stattdessen, ob der Anbieter kontinuierlich sucht, wie schnell bestätigte Fehler zu ausgelieferten Fixes werden und ob seine Offenlegungshistorie mit Datumsangaben nachprüfbar ist.

Hilft KI-gestützte Fehlersuche Angreifern genauso wie Verteidigern?

Die Fähigkeit ist symmetrisch, und bei offen veröffentlichtem Code entfällt jede Hürde durch Reverse Engineering, sodass der Vorteil demjenigen zufällt, der den Suchlauf zuerst fährt. Verteidiger behalten die Oberhand nur, wenn sie kontinuierlich scannen und Fixes schneller ausliefern, als Angreifer Funde bewaffnen können.