KI und der ISV-Release-Zyklus: Was das für Paketierungsteams bedeutet

Verändert KI, wie oft Softwarehersteller ausliefern, und was sollte ein Team für Anwendungspaketierung dagegen tun? Unsere neue Forschung zum Windows-Patching gibt eine abgewogene Antwort: KI ist dokumentiert in der Art, wie einige Schwachstellen gefunden wurden, und einige Hersteller verknüpfen sie mit Änderungen ihrer Release-Zyklen, doch das Papier misst nicht, wie viel der Veränderung KI erklärt. Dieser Beitrag hält beides auseinander. Abschnitte mit der Überschrift "Was das Papier belegt" berichten, was die Studie dokumentiert. Abschnitte mit der Bezeichnung "Unsere Interpretation" sind unsere Lesart, keine Befunde. Unabhängige Softwarehersteller (Independent Software Vendors, ISVs) sind hier die Lieferanten der Anwendungen, die Ihr Team paketiert und bereitstellt. Die Forschung stammt aus dem Haus des Unternehmens und wurde nicht begutachtet (Peer Review). Die Kernbefunde und die Statistik haben wir in früheren Beiträgen behandelt, und das vollständige Papier finden Sie auf der Registrierungsseite.

Was das Papier belegt: KI-gestützte Entdeckung

Die Studie dokumentiert 18 Windows-CVEs mit Anerkennung für KI-gestützte Entdeckung. Sechzehn stammen aus einer Kohorte, die Microsoft als mit seinem Multi-Model Agentic Scanning Harness (MDASH) gefunden benennt, und zwei weitere sind Danksagungen vom Oktober 2026, die Claude oder MDASH ausdrücklich nennen. Das Papier bezeichnet dies als quellengeprüfte Beispielsammlung. Sie ist kein erschöpfender Klassifikator und keine Schätzung des KI-Anteils, und nicht gekennzeichnete Entdeckungen bleiben unbekannt und gelten nicht als rein menschlich.

Die Windows-Leitung von Microsoft verknüpft zudem ausdrücklich die skalierte KI-Entdeckung mit mehr Sicherheitskorrekturen innerhalb von Releases. Das Papier liest dies als Nachweis eines Beitrags und eines plausiblen operativen Mechanismus. Es quantifiziert nicht, wie viel des Gesamtanstiegs auch ohne KI eingetreten wäre.

Drei Vorbehalte aus dem Papier sollten Sie im Blick behalten:

• Raten aus Kampagnen sind keine Branchenmultiplikatoren. Mozilla bestätigte 22 CVEs aus einer berichteten zweiwöchigen Kampagne, etwa 11 pro Woche. Diese Rate gehört zu dieser Kampagne, und es gibt keine vergleichbare rein menschliche kontrafaktische Referenz.
• Neben KI wirken andere Erklärungen. Microsoft berichtet im selben Zeitraum von einem erweiterten Umfang des Bug-Bounty-Programms, mehr Beteiligung von Forschenden und KI-gestützter Forschung, darunter über 300 Meldungen aus zuvor nicht berechtigtem Umfang in der Bounty-Auswertung vom August 2026. Auch der Abbau von Rückständen und die Zuordnungspraxis können die Reihe verändern.
• Die Zähleinheit kann in die Irre führen. Mozilla meldete 271 mit einem KI-Modell gefundene und in Firefox 150 behobene Fehler, während 316 intern mit mehreren Techniken entdeckte Fehler unter drei Sammel-CVEs zusammengefasst wurden. Die 271 sind nicht 271 CVEs, daher zählen herstellerübergreifende CVE-Summen veröffentlichte Kennungen, nicht zugrunde liegende Defekte.

Was das Papier belegt: Release-Taktung

Das Papier verfolgt sechs Anwendungs-Release-Streams: Chrome, Edge, Firefox, Visual Studio Code, Notepad++ und 7-Zip. Das ist ein gezielt zusammengestelltes Panel, keine Vollerhebung der Windows-Software. Im letzten vollständigen Jahr erzeugten die Streams zwischen 4 Release-Tagen (7-Zip) und 69 (Edge). Über die drei vollständigen Jahre stieg Edge von 60 über 64 auf 69 Release-Tage, Chrome von 53 über 50 auf 64, Visual Studio Code von 29 über 39 auf 61 und Firefox von 30 über 40 auf 44, während Notepad++ und 7-Zip selten blieben.

Drei große Hersteller kündigten während der Studie kürzere Release-Zyklen an, wie das Papier berichtet:

• Chrome stellte die Haupt-Stable-Releases ab dem 8. September 2026 von vier auf zwei Wochen um. Das Papier berichtet, dass Google das höhere Patch-Volumen mit automatisierter KI-Entdeckung und Meldungen aus der Community verbindet, und unterscheidet dabei den neuen Meilensteinplan von den fortlaufenden Sicherheits-Refreshes.
• Edge wechselte ab Version 152 Ende August zu einem zweiwöchigen Stable-Zyklus, wobei das Intervall für Funktionen im Extended Stable weiterhin acht Wochen beträgt.
• Firefox kündigte den Wechsel von einem vierwöchigen zu einem zweiwöchigen regulären Zyklus an, beginnend mit Version 155 am 1. September 2026.

Visual Studio Code folgt einem anderen Mechanismus. Sein technischer Bericht vom März 2026 besagt, dass Agenten den Wechsel von einem Jahrzehnt monatlicher Releases zu wöchentlichen Stable-Auslieferungen ermöglicht haben. Das Papier liest dies so, dass KI den Paketierungsdruck sowohl über die Schwachstellenentdeckung als auch über die schnellere Auslieferung gewöhnlicher Produktänderungen erhöhen kann, doch keiner der beiden Berichte belegt, dass jede zusätzliche Version in der Stichprobe durch KI verursacht wurde oder eine Sicherheitskorrektur enthält. Dies sind Richtlinienwechsel, keine Beobachtungen ganzer Jahre mit den neuen Zeitplänen. Zweiwöchige Meilensteine ergeben in einem gleichmäßigen 52-Wochen-Jahr etwa 26 Haupt-Releases, gegenüber etwa 13 bei vier Wochen, und wöchentliche Auslieferung ergibt etwa 52.

Ein Fall vom Oktober 2026 zeigt, warum Versionsnummern nicht genügen. Am 26. Oktober wurden PHP-für-Windows-Builds als 8.2.35-1, 8.3.36-1, 8.4.27-1 und 8.5.12-1 neu veröffentlicht, um ein korrigiertes Brotli 1.2.1 für CVE-2026-111497 einzuschließen, während sich die PHP-Laufzeit und die Quellversion nicht änderten. Eine Prüfung, die nur die PHP-Version liest, kann die korrigierte Abhängigkeitsnutzlast übersehen. Das Papier nutzt den Fall, um die Verteilung auf nachgelagerte Komponenten zu veranschaulichen, nicht mehrere unabhängige KI-Entdeckungen.

Was das Papier nicht belegt

Das Papier ist über seine Grenzen offen, und wir sind es ebenfalls.

• Kein KI-Anteil. Der Anteil der Entdeckungen, der KI zuzuschreiben ist, ist ungemessen.
• Kein universeller Geschwindigkeitsmultiplikator. Es gibt keine bevölkerungsweite Kennzahl für die Entdeckungsgeschwindigkeit durch KI.
• Keine belegte Änderung des Kompromittierungsrisikos. Jede proportionale Änderung des Kompromittierungsrisikos ist ungemessen.
• Keine kausale Behauptung. Die Studie sagt nicht, dass KI das Wachstum der CVEs oder die schnelleren Release-Zyklen verursacht hat.

Vor jeder kausalen Schätzung braucht es nach Angabe des Papiers Entdeckungsmethoden auf CVE-Ebene, Daten zu Entdeckung, Meldung, Validierung und Korrektur sowie vergleichbare Produktgruppen mit einheitlichen Zuordnungsregeln, ausgewertet mit einem kontrollierten oder sorgfältig begründeten quasi-experimentellen Design.

Unsere Interpretation

Alles in diesem Abschnitt ist unsere Lesart der Belege, kein Befund der Studie.

1. Planen Sie nach Anwendung und Kanal, nicht nach Kalendermonat. Ein Panel, das von 4 bis 69 Release-Tagen pro Jahr reicht, lässt sich nicht mit einem einzigen monatlichen Patch-Kalender beschreiben. Wir lesen die Verschiebung als Wechsel von der Planung nach Monaten zur Planung nach Anwendung und Release-Stream.
2. Ein Release ist eine Entscheidung, kein Auftrag. Das Papier trennt beobachtete Hersteller-Releases, nach der Anwendbarkeitsprüfung ausgewählte Versionen, Qualifizierungsläufe, zentral gebaute Artefakte und Installationen auf Endpunkten. Zahlen zu Release-Tagen überzeichnen die Paketierungsarbeit, und eine schnellere Taktung der Hersteller macht selektive Übernahme und risikobasierte Validierung wichtiger, wie das Papier ebenfalls festhält.
3. Die Erkennungslogik trifft Herstelleränderungen zuerst. Das PHP-Beispiel legt nahe, dass eine reine Versionserkennung eine schwache Kontrolle ist, wenn ein Hersteller ein Paket mit einer korrigierten Komponente neu veröffentlicht. Wir würden zusätzlich die Paketrevision, die Komponentenidentität oder einen freigegebenen Datei-Hash prüfen.
4. Bessere Prävention kann neben mehr CVEs bestehen. Die eigenen Szenarien des Papiers, die es als Einschätzung des Autors und nicht als kalibrierte Wahrscheinlichkeiten bezeichnet, lauten: Die Offenlegung könnte von Ende 2026 bis 2028 erhöht oder schwankend bleiben, solange KI Altschwachstellen findet, und eine nachhaltige Analyse vor dem Release könnte das Entweichen von Schwachstellen in neuem Code bei einführenden ISVs etwa in den Jahren 2029 bis 2031 senken, sofern Befunde validiert und Grundursachen behoben werden. Die Stichprobe kann nicht sagen, wann oder ob die CVE-Anzahlen ihren Höhepunkt erreichen.

Das Betriebsmodell des Papiers für Paketierungsteams

Dies ist ein aus den Belegen abgeleiteter Vorschlag, kein in der Studie beobachtetes Ergebnis. Er hat vier Teile.

• Kontinuierliche Release-Aufnahme mit automatisierter täglicher Überwachung, um anwendbare Releases, Supportfristen und Dringlichkeit zu erkennen und Ausnahmen weiterzuleiten.
• Getrennte Bahnen nach Release-Verhalten für schnelle, vorhersehbare und selten erscheinende Release-Streams sowie für durch Hersteller oder Katalog gewartete Apps, jeweils mit eigenem Rhythmus (unten dargestellt).
• Belege, dass jedes Update läuft. Die Verfügbarkeit beim Hersteller beweist nicht, dass ein Endpunkt den richtigen Zweig installiert hat, neu gestartet wurde oder eine verwundbare eingebettete Komponente ersetzt wurde.
• Automatisierung für die Ausführung, Menschen für die Verantwortung. Automatisierung kann Build, Bereitstellung und Testausführung übernehmen, während Menschen verantworten, was getestet wird, was als bestanden gilt und welche Ausnahmen akzeptabel sind.

Die vom Papier vorgeschlagenen Arbeitsbahnen. Es sind operative Rhythmen, keine vom Hersteller vorgegebenen Fristen.

Zwei Klarstellungen aus dem Papier halten das ehrlich. Tägliche Überwachung bedeutet nicht, jede App täglich manuell neu zu bauen, und ein beschleunigter Pfad bleibt verfügbar, wenn Ausnutzung, Gefährdung, eingestellter Support oder Herstellervorgaben das Abwarten unangemessen machen. Der menschliche Anteil ist wichtig, weil jedes grüne Ergebnis nur seine eigene Aussage stützt: "Es wurde installiert" stützt eine Installationsaussage, "es wurde gestartet" eine Startaussage und "der Workflow wurde bestanden" den festgelegten Workflow samt Daten, Identität und Prüfungen. Unsere frühere Studie MSIX im großen Maßstab hat aus demselben Grund Paketerstellung, Installation, Start und einen vollständig bestandenen Smoke-Test getrennt.

Wo EtherApps Forge ins Bild passt

Die Studie bewertet weder EtherApps Forge noch ein kommerzielles Produkt, und EfficientEther legt im Papier sein Interesse an EtherApps Forge offen. Für die Teams, die schnellere Hersteller-Releases verkraften müssen, erfasst EtherApps Forge Anwendungen dort, wo sie bereits laufen, und baut signierte MSIX-, MSI-, Intune- und App-Attach-Pakete. Sein Workflow für agentische Anwendungspaketierung empfiehlt einen Weg auf Basis des tatsächlichen Anwendungs-Footprints, und MSIX-Paketierung und -Bereitstellung beschreibt, wie diese Pakete zu Intune und Azure Virtual Desktop gelangen. Wenn Sie ein ISV sind, der in verwaltete Windows-Umgebungen ausliefert, behandelt MSIX-Paketierung für Entwickler und ISVs das Erstellen, Signieren und Validieren von MSIX innerhalb einer bestehenden Release-Pipeline. Weitere Belege zu Paketierungskosten und Bereitschaft finden Sie unter Der Stand der Anwendungspaketierung 2026.

Die Windows-Patching-Forschung erhalten, um die Belege, die Grenzen und das vorgeschlagene Betriebsmodell vollständig zu lesen.