Laut Microsoft half das KI-Team FORGE bei 140 Windows-CVEs, 52 im September-Update – und warum die CRA-Meldepflicht erst bei Ausnutzung greift

Wer im September die Windows-Updates eingespielt hat, hat möglicherweise etwas mitgenommen, das bei Microsoft mit KI-Unterstützung gefunden wurde. Laut Microsoft wurden im September-Sicherheitsupdate 52 CVEs adressiert, bei deren Fund das KI-Team FORGE half. Das steht so im Beitrag im Microsoft Security Blog, den Taesoo Kim, Vice President Agentic Security bei Microsoft, am 7. Oktober veröffentlicht hat.

Was heißt das für Sie? Erst einmal etwas Nüchternes. Windows-Updates nicht aufschieben ist die unspektakulärste Konsequenz dieser Zahlen. Aber eben auch die praxistauglichste.

Dahinter steckt die eigentlich interessante Frage. Wenn KI beim Finden von Schwachstellen hilft, wer prüft dann, wer baut den Fix, wer liefert ihn aus und wer meldet, wenn es ernst wird? Und noch schärfer: Was passiert mit all den gefundenen Schwachstellen, für die am Ende niemand Zeit hat? Genau darum geht es in diesem Artikel. Ich finde, der Blogbeitrag des FORGE-Teams liefert dafür erstaunlich viel Material, auch wenn er es als Erfahrungsbericht verpackt und nicht als Aufsichtsfrage.

Eine Vorbemerkung zur Einordnung: Alle Zahlen in diesem Text sind Herstellerangaben aus Microsofts eigenem Blog. Unabhängig geprüft sind sie nicht. Wir geben sie wieder, rechnen an einzelnen Stellen selbst nach und kennzeichnen das jeweils. Am Ende folgt unsere Einordnung zum Cyber Resilience Act (CRA), dessen Meldepflicht erst bei aktiv ausgenutzten Schwachstellen greift. Microsoft selbst erwähnt den CRA in dem Beitrag nicht.

Was Microsoft tatsächlich zählt

FORGE steht für Frontier Offensive Research & Generative Exploitation und ist ein Lab bei Microsoft Security. Die Mission laut Blog: die Grenze autonomer Sicherheitsentwicklung voranbringen, KI-native Schwachstellenforschung betreiben, Zero-Day-Lücken finden und beheben. Vier Prinzipien führt das FORGE-Team an: „autonomy over labor, defense through offense, building ecosystems over individual examples, and understanding over findings“. Das Werkzeug hinter vielem im FORGE-Lab trägt den Codenamen MDASH, ein Multi-Modell-Agenten-System. Mehr dazu an dieser Stelle bewusst nicht.

Der Beitrag selbst ist als Lehrstück aufgebaut, mit drei Lehren. Die erste: der Weg von der Frontier-Fähigkeit zur Skalierung. Die zweite: weg vom reinen Token-Verbrauch, hin zu dem, was der Blog „reasoning economics“ nennt, also der Ökonomie des Denkaufwands. Die dritte: weg vom isolierten Finden, hin zu koordinierter Validierung und Behebung. Man merkt schon an der Reihenfolge, wohin die Gewichte wandern.

Der Kernsatz dazu lautet: „Discovery creates security value only when validation and remediation can keep pace.“ Übersetzt: Ein Fund schafft erst dann Sicherheit, wenn Prüfung und Behebung Schritt halten. Das ist keine Randbemerkung, sondern die Messlatte, an der sich alle folgenden Zahlen messen lassen müssen. Und es ist der Grund, warum wir in diesem Text bei Schwachstellen mehr nach dem Danach fragen als nach dem Fund.

Nun die Windows-Zahl. Laut Microsoft half FORGE von Mai bis September 2026 beim Finden von Windows-Schwachstellen, denen 140 CVEs zugewiesen wurden. 52 davon wurden allein im September-Sicherheitsupdate adressiert. „Half beim Finden“ ist dabei die Formulierung der Quelle („helped discover“) – und sie ist wichtig. Sie sagt nicht, dass eine KI diese Schwachstellen allein entdeckt hätte.

Unsere Rechnung, Basis 52 von 140: Das sind rund 37 Prozent. Mehr sollten Sie daraus nicht ableiten.

Warum nicht? Weil Microsoft unter der Grafik selbst einen Hinweis gibt: Die Monatswerte zeigen Ankündigungs- und Auslieferungskohorten, nicht Entdeckungsdaten und nicht den Scan-Durchsatz. Anders gesagt: Sie zeigen, wann CVEs angekündigt und ausgeliefert wurden. Wann etwas gefunden wurde, steht dort nicht. Wie viel gescannt wurde, ebenso wenig. Der September-Wert taugt deshalb nicht als Tempo-Messung, und Monatsvergleiche verbieten sich von selbst.

Ehrlich gesagt gefällt mir an diesem Hinweis, dass er überhaupt dasteht. Herstellerblogs neigen dazu, jede Zahl wie einen Fahrtenschreiber zu behandeln. Hier steht ein Absatz, der die eigene Grafik vor Überinterpretation schützt. Das ist ein Stück Transparenz, das glaubwürdig wirkt.

155 Reports, 93 mit Rückmeldung

Der zweite Zahlenblock betrifft Open Source. Laut Microsoft prüften FORGE-Mitglieder über drei Monate Projekte aus Bereichen wie Kernel, Laufzeitumgebungen, Netzwerkbibliotheken, Container-Technologien und Medien-Parser auf Schwachstellen. Das Ergebnis: 155 intern validierte Reports in 23 Projekten. Zum Zeitpunkt des Blogbeitrags hatten 93 Reports in 14 Projekten oder Projektfamilien eine dokumentierte Bestätigung oder Annahme durch die Maintainer.

Genannt werden unter anderem curl, FFmpeg, Linux, llama.cpp, Node.js, Rust, SQLite und vLLM. Wir bei digital-magazin.de haben diese Liste zweimal gelesen, weil sie viel Infrastruktur versammelt, auf der andere Produkte aufbauen.

Warum das für Sie relevant ist, auch wenn Sie nie eine dieser Bibliotheken bewusst installiert haben? Weil solche Projekte oft unsichtbar mitlaufen: ein Werkzeug für Datenübertragung hier, eine eingebettete Datenbank dort, ein Medienformat-Parser im Hintergrund einer Anwendung. Wo ein Produkt solche Bausteine verwendet, hängt seine Sicherheit auch an der Sorgfalt in diesen Projekten. Details zu einzelnen Schwachstellen gehören nicht in einen Artikel wie diesen. Die Kategorie genügt, um die Tragweite zu verstehen.

Unsere Rechnung, Basis 93 von 155: Das sind 60 Prozent der eingereichten Reports mit dokumentierter Rückmeldung der Maintainer. Eine Erfolgsquote ist das ausdrücklich nicht.

Denn was heißt „acknowledgement or acceptance“? Es heißt: Die Maintainerinnen und Maintainer haben den Eingang des Reports dokumentiert oder ihn angenommen. Beides ist möglich, und die Quelle trennt es nicht weiter auf. Es heißt nicht automatisch, dass jemand den Report als berechtigt anerkannt hätte. Es heißt nicht, dass es 93 bestätigte Bugs gäbe. Und es heißt auch nicht, dass es 93 ausgelieferte Fixes gibt. Zu den übrigen 62 FORGE-Reports sagt die Quelle lediglich, dass sich Reports in unterschiedlichen Prozessstadien befinden. Mehr wissen wir nicht, und Spekulation hilft niemandem. Nur Teilmengen sind laut Blog bislang öffentlich offengelegt – von außen lässt sich vieles also noch gar nicht nachprüfen.

Interessant ist, was Microsoft über die Gegenseite schreibt. Manche Projekte wollten einen Patch mitgeliefert bekommen, andere nicht. Manche bevorzugten private Offenlegung, andere öffentliche Kanäle. Und nicht immer sahen die Maintainer gleich, ob ein Problem tatsächlich eine Sicherheitsgrenze überschreitet. Daraus leitet der Blog einen Satz ab, den ich unterschreiben würde: Open-Source-Sicherheitsforschung könne nur skalieren, wenn die Forschungsteams die entstehende Komplexität selbst auffangen, statt sie an die Projektverantwortlichen weiterzureichen.

Meiner Einschätzung nach ist das der ehrlichste Satz des ganzen Beitrags. Er räumt ein, dass ein Report nicht gratis ist, nur weil er automatisch entstanden ist. Wer ihn schreibt, schuldet dem Gegenüber Aufmerksamkeit. Wer ihn bekommt, zahlt sie womöglich mit Freizeit. Wer trägt das auf Dauer?

3,61 Dollar – und was darin nicht steckt

Eine Zahl, die sich leicht merken lässt, betrifft den Linux-Kernel. Laut Microsoft markierte MDASH dort tausende verdächtige Stellen mit möglichen Schwachstellen. Validierungsagenten lieferten unterstützende Belege für 627 Funde. Für eine Teilmenge hat Microsoft die Kosten gemessen: Über 182 bestätigte Absturz-Funde lag der Durchschnitt bei 3,61 US-Dollar Modellkosten und 21,5 Minuten – je Nachweis, dass ein Absturz reproduzierbar ist. Eingesetzt wurde GPT-5.5, ohne aufwendiges aufgabenspezifisches Tuning. Microsofts Schluss: Automatisierte Validierung könne „useful results at practical cost and latency“ liefern.

Das klingt günstig. Es ist ein Durchschnitt über die erfolgreichen Fälle, und genau darin liegt der Knackpunkt.

Die Durchschnitte umfassen alle Versuche, die zu diesen erfolgreichen Fällen führten. Ausgeschlossen sind laut Blog:

• das erste Screening,
• gescheiterte oder herausgefilterte Kandidaten,
• die menschliche Untersuchung,
• die Vorbereitung eines Patches.

Also fast alles, was einen Fund zu einem ausgelieferten Fix macht. Die 3,61 Dollar beschreiben einen Ausschnitt der Kette, nicht die Kette. Deshalb setzen wir die Zahlen 627 und 182 auch nicht ins Verhältnis, und deshalb rechnen wir nichts hoch. Beides würde eine Genauigkeit vortäuschen, die die Quelle nicht hergibt.

Der Blog denkt übrigens selbst weiter: Scan-Ergebnisse sollen als Trainingsdaten für spezialisierte Cyber-Modelle dienen, eine Lernschleife also. Und Ideen wie das Routing von Routinearbeit auf günstigere Modelle bezeichnet er als „hypotheses to test“ – als Hypothesen, die zu prüfen sind, nicht als Effizienzgewinne, die man einfach annehmen dürfe. Diese Zurückhaltung tut dem Text gut.

Hand aufs Herz: Als Schlagzeile wäre die Zahl verlockend. Aber sie beantwortet die falsche Frage. Die Frage lautet nicht, was ein Nachweis kostet, sondern was es kostet, bis eine Lücke geschlossen und das Update bei den Nutzenden angekommen ist.

Ich finde, die eigentliche Rechnung ist die Menschenzeit. Jemand muss beurteilen, ob der Fund sicherheitsrelevant ist. Jemand muss den Patch schreiben oder prüfen, mit den Maintainern sprechen, die Auslieferung begleiten. Microsoft formuliert es selbst so: „A reproducible defect is not yet a serviced fix.“ Und ebenso klar: Die knappe Ressource sei nicht immer die Modellintelligenz – es könne ein lauffähiger Build sein, ein reproduzierbarer Auslöser oder schlicht die Zeit einer Ingenieurin oder eines Ingenieurs.

Das ist der Unterschied zwischen Herstellerblog und Aufsichtspraxis: Der eine zeigt, was sich messen lässt. Die andere fragt, was am Ende beim Produkt ankommt.

Der Flaschenhals heißt Prüfen

Jetzt zur eigentlichen These des FORGE-Beitrags. Microsoft formuliert sie so: „the bottleneck shifts from discovery to determining which reports are real, reachable, and security-relevant.“ Der Engpass wandert also vom Finden zur Frage, welche Reports echt sind, erreichbar und sicherheitsrelevant. Das ist der Kern der drei Lehren, die der Blog zieht.

Der Blog gibt dazu ein Bild, das ich einleuchtend finde: „Adding auditors can increase candidate volume without increasing the rate of validated findings or shipped fixes.“ Mehr Auditoren, also spezialisierte Such-Agenten am Anfang der Kette, erhöhen die Zahl der Kandidaten, aber nicht automatisch die Zahl geprüfter Funde oder ausgelieferter Fixes. Kommen Reports schneller an, als die Prüfstelle sie abarbeitet, wächst zuerst die Warteschlange. Bei Microsoft ist diese Prüfstelle das Microsoft Security Response Center (MSRC). Doppelte oder schlecht belegte Reports zu Schwachstellen binden dort Aufmerksamkeit, die für echte Fälle fehlt.

Eine Gegenmaßnahme nennt der Blog konkret. In einem internen Projekt reduzierte ein deterministisches Verfahren auf Basis des abstrakten Syntaxbaums laut Microsoft rund 45 Prozent doppelte Funde über mehrere Scans desselben Codes. Das entlastete die nachgelagerte Prüfung durch Menschen. Wichtig: Das gilt für dieses eine Projekt. Verallgemeinern sollten Sie es nicht.

Dann der Blick auf die Open-Source-Seite. Die Projekte ticken eben unterschiedlich: Manche wünschten sich einen Patch, andere nicht, und nicht alle zogen die Sicherheitsgrenze an derselben Stelle. Der Blog folgert, Forschungsteams müssten die entstehende Komplexität auffangen: „absorb the resulting complexity rather than pass it on to maintainers“. Das ist ein hoher Anspruch. Ob er im Alltag eingelöst wird, können wir von außen nicht beurteilen.

Zwei Beispiele zeigen, wie Microsoft das angeht. Beim jährlichen Microsoft-Hackathon lief die „FORGE OSS Bug Hunt Party“ (Project Sunshine): 50 Teilnehmende, 39 Reports in sechs Projekten, darunter Hyperlight, Linux, vLLM, Gemini CLI und llama.cpp. Diese 39 sind in den 155 Reports enthalten – bitte nicht addieren.

Das zweite Beispiel heißt Akrites, eine Initiative der Linux Foundation. Sie koordiniert die vertrauliche Behebung und Offenlegung (Coordinated Vulnerability Disclosure, CVD) für Schwachstellen in kritischer Open-Source-Software. FORGE reichte neun Linux-Funde ein, intern mit CVSS-Werten über 7,0 bewertet. Zusammen mit Einreichungen anderer Teilnehmender, darunter Google, halfen sie, den frühen CVD-Ablauf zu testen. Einer der Reports war die erste Akrites-Einreichung, die zu einem in den Linux-Kernel gemergten Patch führte.

Interessant ist, dass auch die Verteidigerseite das Thema Prüfen und Verteilen kennt. Google gibt sein neues Frontier-Modell zunächst vertrauenswürdigen Cyber-Verteidigenden in die Hand, wie wir bei Gemini 4 Argon eingeordnet haben. Ein Zahlenvergleich verbietet sich, die Ausgangslagen sind zu verschieden. Die Richtung ähnelt sich aber: Wer Funde in großer Zahl erzeugt, trägt Verantwortung für den Weg danach.

Unsere Einordnung: Was der CRA heute verlangt – und was nicht

Dieses Bild wurde komplett mit KI generiertProviderhiggsfieldModellgpt_image_2PromptPhotorealistic close photo of a desk with a tall stack of blank paper files tied with a string next to a closed laptop and a small hourglass, soft warm light, shallow depth of field, no logos, no readable text, no writing on the paper, no watermarks, 16:9

Unsere Einordnung beginnt mit einer Klarstellung: Microsoft erwähnt den Cyber Resilience Act in dem Beitrag nicht. Alles, was jetzt kommt, ist unsere Sicht auf die Aufsichtsseite, kein Bestandteil von Microsofts Aussagen.

Seit dem 11. September gilt die CRA-Meldepflicht: Hersteller müssen laut EU-Kommission aktiv ausgenutzte Schwachstellen und schwere Sicherheitsvorfälle melden, die die Sicherheit ihrer Produkte mit digitalen Elementen betreffen. Die Fristen sind eng gestaffelt:

• Frühwarnung binnen 24 Stunden nach Kenntnis,
• vollständige Meldung binnen 72 Stunden,
• Abschlussbericht spätestens 14 Tage, nachdem eine Korrekturmaßnahme für eine aktiv ausgenutzte Schwachstelle verfügbar ist,
• bei schweren Vorfällen: Abschlussbericht binnen eines Monats nach der 72-Stunden-Meldung.

Gemeldet wird nur einmal, über die Single Reporting Platform (SRP) der ENISA. Die Meldung geht an das CSIRT des Mitgliedstaats der Hauptniederlassung und wird, außer unter besonders außergewöhnlichen Umständen, gleichzeitig für ENISA zugänglich gemacht. Die Einzelheiten stehen auf der Seite der Kommission zu den CRA-Meldepflichten. Wie die Plattform funktioniert, haben wir in unserem Countdown zur Meldepflicht und zur SRP beschrieben. Das wiederholen wir hier nicht.

Jetzt der Punkt, auf den es uns ankommt. Aus unserer Sicht gilt: Die CRA-Meldepflicht seit 11.9. greift erst, wenn eine Lücke aktiv ausgenutzt wird. Für frisch gefundene, nicht ausgenutzte Lücken zählt heute vor allem koordinierte Offenlegung — die übrigen CRA-Pflichten der Hersteller gelten erst ab Dezember 2027.

Wir bei digital-magazin.de halten diese CRA-Unterscheidung für wichtig, weil sie zwei Dinge trennt, die im Alltag leicht verschwimmen: das Finden einer Schwachstelle und ihre tatsächliche Ausnutzung. Die CRA-Meldepflicht sitzt am zweiten Ende.

Und was sagt das über die FORGE-Funde und den CRA? Nichts. Ob einer davon meldepflichtig war oder ist, wissen wir nicht, und der Blog äußert sich dazu auch nicht. Wir stellen deshalb keine Verbindung her. Wir ordnen nur ein, an welcher Stelle der Kette die neue CRA-Pflicht ansetzt.

Gefunden, aber nicht ausgenutzt

Zwischen Fund und Ausnutzung liegt eine Zone, die in der öffentlichen Debatte oft zu kurz kommt. Eine Lücke ist gefunden, geprüft, vielleicht schon repariert, aber niemand nutzt sie aus. Hier greift die CRA-Meldepflicht für diese Schwachstellen nicht. Hier zählt vor allem, ob Funde sauber und koordiniert offengelegt werden.

Akrites ist dafür ein gutes Beispiel, weil es zeigt, wie so ein Ablauf aussehen kann: vertraulich melden, gemeinsam beheben, dann offenlegen. Dass der Blog den frühen Ablauf als Test beschreibt, finde ich ehrlich. Es ist ein Anfang, kein fertiges System.

Was gilt rechtlich ab wann? Der CRA ist seit dem 10. Dezember 2024 in Kraft. Die Hauptpflichten gelten ab dem 11. Dezember 2027, die Meldepflichten seit dem 11. September. Zu den Hauptpflichten gehört unter anderem, Schwachstellen über den gesamten Lebenszyklus eines Produkts zu behandeln; dazu kommen CE-Kennzeichnung und Durchsetzung durch die nationale Marktüberwachung. Open-Source-Software-Stewards unterliegen laut Kommission nach Art. 71 Abs. 2 in Verbindung mit Art. 24 Abs. 3 den Meldepflichten erst ab dem 11. Dezember 2027. Einen Überblick bietet die Seite der Kommission zum Cyber Resilience Act. Rechtsberatung ist das nicht – prüfen Sie Ihren Einzelfall mit Fachleuten.

Man kann es als Lücke lesen oder als Übergangsfrist. Ich neige zu Letzterem, mit einem Vorbehalt: Angreifende können dieselben Werkzeuge nutzen. Das ist keine Prognose, nur ein Grund, die Zeit bis 2027 nicht als Schonfrist für Untätigkeit zu verstehen.

Meiner Einschätzung nach entscheidet sich in dieser Zone, ob KI-gestützte Suche der Sicherheit nützt. Nicht beim Fund. Nicht bei der Meldung. Sondern dazwischen, bei Prüfkapazität, Offenlegungsdisziplin und der Frage, wie schnell ein Fix bei den Nutzenden ankommt.

Was heißt das für Sie?

Kurz und praktisch. Die folgenden Punkte sind Prüffragen, keine Rechtsberatung und keine Compliance-Prüfung Ihres Einzelfalls.

• Hersteller: Wissen Sie, wer in Ihrem Unternehmen eine aktiv ausgenutzte Lücke binnen 24 Stunden meldet – auch an einem Wochenende, auch im Urlaub der zuständigen Person? Gibt es eine Vertretung, und kennt sie den Weg zur Meldeplattform?
• IT-Verantwortliche: Wie schnell spielen Sie Updates ein, und wer entscheidet, wenn ein Patch Ausfälle riskiert? Die Zahlen von Microsoft ändern daran nichts, sie machen die Frage nur dringlicher.
• Open-Source-Nutzende: Welche Open-Source-Projekte tragen Ihr Produkt – und wer prüft dort Reports? Eine aktuelle Software-Stückliste (SBOM) hilft, diese Frage überhaupt beantworten zu können.
• Privatnutzende: Aktivieren Sie automatische Updates und lassen Sie sie laufen. Das ist eine praxistaugliche Maßnahme, die Sie selbst in der Hand haben.

Wer tiefer einsteigen möchte, findet im Kontrast die Verteidigerseite: Wir haben beschrieben, wie Red Teams agentische Systeme als Ganzes prüfen. Auch dort zeigt sich, dass einzelne Funde selten die ganze Geschichte erzählen.

Mal ehrlich: Keine dieser Fragen ist neu. Neu ist nur, dass mehr Funde schneller bei Ihnen oder Ihren Zulieferern landen können. Dann kommt es darauf an, ob die Abläufe dahinter tragen.

Und jetzt?

Ich nehme aus dem Beitrag vor allem einen Satz mit, und er steht in Microsofts Schlussteil: Wer KI-gestützte Schwachstellensuche bewertet, solle „count validated fixes, not just findings“ und die Modellkosten neben der menschlichen Prüfzeit wägen. Dem ist wenig hinzuzufügen.

Wir bei digital-magazin.de bleiben dabei: Zahlen aus Herstellerblogs sind ein Anfang, keine Aufsicht. Sie zeigen, was ein Team gemessen hat. Ob das System als Ganzes funktioniert, zeigt sich erst bei Prüfung, Fix und Auslieferung.

Bleibt die offene Frage, die der Blog nicht beantwortet und die wir auch nicht beantworten können: Wer bezahlt die Prüfzeit, vor allem bei den Open-Source-Projekten, die Ihr Produkt tragen?