AI en de releasecyclus van ISV's: wat het betekent voor packagingteams

Verandert AI hoe vaak softwareleveranciers releasen, en wat moet een applicatiepackagingteam daaraan doen? Ons nieuwe Windows-patchingonderzoek geeft een afgewogen antwoord: AI is gedocumenteerd in hoe sommige kwetsbaarheden zijn gevonden, en sommige leveranciers koppelen het aan veranderingen in hun releasecyclus, maar het paper meet niet hoeveel van de verandering AI verklaart. Dit bericht houdt die twee uit elkaar. Secties met de kop "Wat het paper aantoont" geven weer wat het onderzoek documenteert. Secties met het label "Onze interpretatie" zijn onze lezing, geen bevindingen. Onafhankelijke softwareleveranciers (ISV's) zijn hier de leveranciers van de applicaties die uw team packaget en uitrolt. Het onderzoek is door het bedrijf zelf geschreven en is niet peer-reviewed. We behandelden de belangrijkste bevindingen en de statistieken in eerdere berichten, en het volledige paper staat op de registratiepagina.

Wat het paper aantoont: AI-ondersteunde ontdekking

Het onderzoek documenteert 18 Windows-CVE's met vermelding van AI-ondersteunde ontdekking. Zestien komen uit een cohort waarvan Microsoft zegt dat het is gevonden met zijn Multi-Model Agentic Scanning Harness (MDASH), en twee andere zijn erkenningen uit oktober 2026 waarin Claude of MDASH uitdrukkelijk wordt gecrediteerd. Het paper noemt dit een aan de bron geverifieerde set voorbeelden. Het is geen uitputtende classificatie en geen schatting van het AI-aandeel, en ontdekkingen zonder label blijven onbekend en worden niet als uitsluitend menselijk beschouwd.

Ook de Windows-leiding van Microsoft koppelt opgeschaalde AI-ontdekking uitdrukkelijk aan meer beveiligingsfixes binnen releases. Het paper leest dat als aantoning van een bijdrage en een aannemelijk operationeel mechanisme. Het kwantificeert niet hoeveel van de totale stijging zonder AI zou zijn opgetreden.

Drie waarschuwingen uit het paper zijn het onthouden waard:

• Campagnepercentages zijn geen multipliers voor de hele sector. Mozilla bevestigde 22 CVE's uit een gerapporteerde campagne van twee weken, ongeveer 11 per week. Dat tempo hoort bij die campagne, en er is geen vergelijkbaar contrafactueel scenario met alleen menselijke ontdekking.
• Andere verklaringen werken naast AI. Microsoft meldt een uitgebreider bereik van het bugbountyprogramma, meer deelname van onderzoekers en AI-ondersteund onderzoek in dezelfde periode, waaronder meer dan 300 meldingen uit een voorheen niet in aanmerking komend bereik in de evaluatie van het bountyprogramma van augustus 2026. Het wegwerken van achterstanden en de toewijzingspraktijk kunnen de reeks ook veranderen.
• De teleenheid kan misleiden. Mozilla meldde 271 bugs die met een AI-model zijn gevonden en in Firefox 150 zijn opgelost, terwijl 316 intern ontdekte bugs uit meerdere technieken zijn gegroepeerd onder drie overkoepelende CVE's. Die 271 zijn niet 271 CVE's, dus CVE-totalen over leveranciers heen tellen gepubliceerde identificaties, niet onderliggende defecten.

Wat het paper aantoont: releaseritme

Het paper volgt zes releasestromen van applicaties: Chrome, Edge, Firefox, Visual Studio Code, Notepad++ en 7-Zip. Dit is een doelgericht samengesteld panel, geen volledige telling van Windows-software. In het laatste volledige jaar leverden de stromen tussen 4 releasedagen (7-Zip) en 69 (Edge) op. Over de drie volledige jaren ging Edge van 60 naar 64 naar 69 releasedagen, Chrome van 53 naar 50 naar 64, Visual Studio Code van 29 naar 39 naar 61 en Firefox van 30 naar 40 naar 44, terwijl Notepad++ en 7-Zip schaars bleven.

Drie grote leveranciers kondigden tijdens het onderzoek kortere releasecycli aan, zoals het paper meldt:

• Chrome ging met major Stable-releases van vier weken naar twee, vanaf 8 september 2026. Het paper meldt dat Google een hoger patchvolume koppelt aan geautomatiseerde AI-ontdekking en meldingen uit de community, en onderscheidt daarbij het nieuwe mijlpaalschema van doorlopende beveiligingsupdates.
• Edge ging over op een Stable-cyclus van twee weken vanaf versie 152 eind augustus, waarbij het interval voor de Extended Stable-functies nog steeds acht weken is.
• Firefox kondigde een overstap aan van een reguliere cyclus van vier weken naar twee weken, te beginnen met versie 155 op 1 september 2026.

Visual Studio Code is een ander mechanisme. Het engineeringverslag van maart 2026 zegt dat agents de overstap mogelijk maakten van een decennium aan maandelijkse releases naar wekelijkse Stable-levering. Het paper leest dit zo dat AI de packagingdruk kan verhogen via zowel het ontdekken van kwetsbaarheden als de snellere levering van gewone productwijzigingen, maar geen van beide verslagen toont aan dat elke extra bemonsterde versie door AI is veroorzaakt of een beveiligingsfix bevat. Dit zijn beleidsovergangen, geen waarnemingen over een heel jaar van de nieuwe schema's. Mijlpalen van twee weken impliceren grofweg 26 major releases in een gelijkmatig jaar van 52 weken, tegenover ongeveer 13 bij vier weken, en wekelijkse levering impliceert ongeveer 52.

Een geval uit oktober 2026 laat zien waarom versienummers niet genoeg zijn. Op 26 oktober zijn PHP voor Windows-builds opnieuw gepubliceerd als 8.2.35-1, 8.3.36-1, 8.4.27-1 en 8.5.12-1 om een gecorrigeerde Brotli 1.2.1 voor CVE-2026-111497 op te nemen, terwijl de PHP-runtime en de broncodeversie niet veranderden. Een controle die alleen de PHP-versie leest, kan de gecorrigeerde afhankelijkheidslading missen. Het paper gebruikt het om downstream-verspreiding van componenten te illustreren, niet meerdere onafhankelijke AI-ontdekkingen.

Wat het paper niet vaststelt

Het paper is direct over zijn beperkingen, en wij ook.

• Geen AI-aandeel. Het aandeel van de ontdekkingen dat aan AI is toe te schrijven, is ongemeten.
• Geen universele snelheidsmultiplier. Er is geen cijfer voor de ontdekkingssnelheid door AI dat voor de hele populatie geldt.
• Geen verandering in compromitteringsrisico. Elke proportionele verandering in het risico op compromittering is ongemeten.
• Geen causale claim. Het onderzoek zegt niet dat AI de groei van CVE's of de snellere releasecycli heeft veroorzaakt.

Volgens het paper zijn voor een causale schatting nodig: ontdekkingsmethoden op CVE-niveau, data van ontdekking, melding, validatie en fix, en vergelijkbare productgroepen met consistente toewijzingsregels, geanalyseerd met een gecontroleerd of zorgvuldig onderbouwd quasi-experimenteel ontwerp.

Onze interpretatie

Alles in deze sectie is onze lezing van het bewijs, geen bevinding van het onderzoek.

1. Plan per applicatie en kanaal, niet per kalendermaand. Een panel dat loopt van 4 tot 69 releasedagen per jaar is niet te beschrijven met één maandelijkse patchkalender. Wij lezen de verschuiving als een overgang van plannen per maand naar plannen per applicatie en releasestroom.
2. Een release is een besluit, geen taak. Het paper onderscheidt waargenomen leveranciersreleases, versies die na beoordeling van de toepasbaarheid zijn geselecteerd, kwalificatieruns, centraal gebouwde artefacten en installaties op endpoints. Aantallen releasedagen overschatten het packagingwerk, en een sneller leveranciersritme maakt selectieve adoptie en risicogebaseerde validatie belangrijker, zoals het paper ook stelt.
3. Detectielogica is waar leverancierswijzigingen het eerst voelbaar worden. Het PHP-voorbeeld suggereert dat detectie op alleen de versie een zwakke maatregel is wanneer een leverancier een pakket opnieuw publiceert met een gecorrigeerde component. Wij zouden ook de pakketrevisie, de identiteit van de component of een goedgekeurde bestandshash controleren.
4. Betere preventie kan samengaan met meer CVE's. De eigen scenario's van het paper, die het zelf het oordeel van de auteur noemt en geen gekalibreerde kansen, zijn dat de openbaarmaking van eind 2026 tot 2028 verhoogd of volatiel kan blijven terwijl AI oude kwetsbaarheden vindt, en dat aanhoudende analyse vóór de release het ontsnappen van kwetsbaarheden in nieuwe code bij ISV's die dit toepassen rond 2029 tot 2031 kan verlagen, als bevindingen worden gevalideerd en grondoorzaken worden verholpen. De steekproef kan niet zeggen of en wanneer het aantal CVE's zijn piek bereikt.

Het operatiemodel van het paper voor packagingteams

Dit is een voorstel dat uit het bewijs is afgeleid, geen resultaat dat in het onderzoek is waargenomen. Het heeft vier onderdelen.

• Continue release-intake, met geautomatiseerde dagelijkse monitoring om toepasselijke releases, ondersteuningsdeadlines en urgentie te identificeren en om uitzonderingen te routeren.
• Aparte sporen naar releasegedrag, voor snelle, voorspelbare en schaarse releasestromen, plus door leveranciers of catalogi onderhouden apps, elk met een eigen ritme (hieronder weergegeven).
• Bewijs dat elke update draait. Beschikbaarheid bij de leverancier bewijst niet dat een endpoint de juiste branch heeft geïnstalleerd, opnieuw is gestart of een kwetsbare ingebedde component heeft laten vervangen.
• Automatisering voor de uitvoering, mensen voor de verantwoordelijkheid. Automatisering kan de build, uitrol en testuitvoering dragen, terwijl mensen eigenaar blijven van wat wordt getest, wat als geslaagd telt en welke uitzonderingen acceptabel zijn.

De voorgestelde werksporen van het paper. Het zijn werkritmes, geen door leveranciers opgelegde deadlines.

Twee verduidelijkingen uit het paper houden dit eerlijk. Dagelijkse monitoring betekent niet dat elke app elke dag handmatig opnieuw wordt gebouwd, en er blijft een versnelde route beschikbaar wanneer uitbuiting, blootstelling, het intrekken van ondersteuning of instructies van de leverancier wachten ongepast maken. Het menselijke deel is belangrijk omdat elk groen resultaat alleen zijn eigen claim ondersteunt: "het is geïnstalleerd" ondersteunt een installatieclaim, "het is gestart" een startclaim en "de workflow is geslaagd" de gespecificeerde workflow, gegevens, identiteit en assertions. Onze eerdere studie MSIX op schaal scheidde om dezelfde reden het maken van pakketten, installatie, starten en een volledig geslaagde smoke test.

De rol van EtherApps Forge

Het onderzoek evalueert EtherApps Forge noch enig ander commercieel product, en EfficientEther vermeldt in het paper zijn belang bij EtherApps Forge. Voor de teams die snellere leveranciersreleases moeten opvangen, legt EtherApps Forge applicaties vast waar ze al draaien en bouwt het ondertekende MSIX-, MSI-, Intune- en App Attach-pakketten. De workflow voor agentische applicatiepackaging beveelt een route aan op basis van de werkelijke footprint van de applicatie, en MSIX-packaging en -uitrol behandelt hoe die pakketten Intune en Azure Virtual Desktop bereiken. Bent u een ISV die levert aan beheerde Windows-omgevingen, dan behandelt MSIX-packaging voor ontwikkelaars en ISV's het bouwen, ondertekenen en valideren van MSIX binnen een bestaande releasepipeline. Voor het bredere bewijs over packagingkosten en gereedheid, zie de stand van applicatiepackaging in 2026.

Ontvang het Windows-patchingonderzoek om het bewijs, de beperkingen en het voorgestelde operatiemodel volledig te lezen.