AI och ISV:ernas releasecykel: vad det betyder för paketeringsteam

Förändrar AI hur ofta programvaruleverantörer släpper nya versioner, och vad bör ett team för programpaketering göra åt det? Vår nya forskning om Windows-patchning ger ett avvägt svar: AI är dokumenterat i hur vissa sårbarheter hittades, och vissa leverantörer kopplar det till förändringar i sina releasecykler, men rapporten mäter inte hur stor del av förändringen som AI förklarar. Det här inlägget håller de två isär. Avsnitt med rubriken "Vad rapporten belägger" redovisar vad studien dokumenterar. Avsnitt märkta "Vår tolkning" är vår läsning, inte resultat. Här är oberoende programvaruleverantörer (ISV:er) de som levererar de program som ditt team paketerar och distribuerar. Forskningen är skriven av företaget självt och har inte genomgått referentgranskning. Vi behandlade de viktigaste resultaten och statistiken i tidigare inlägg, och hela rapporten finns på registreringssidan.

Vad rapporten belägger: AI-assisterad upptäckt

Studien dokumenterar 18 Windows-CVE:er med erkännande för AI-assisterad upptäckt. Sexton kommer från en kohort som Microsoft anger har hittats med sitt Multi-Model Agentic Scanning Harness (MDASH), och ytterligare två är erkännanden från oktober 2026 som uttryckligen anger Claude eller MDASH som källa. Rapporten kallar detta en källverifierad uppsättning exempel. Det är inte en uttömmande klassificerare och inte en uppskattning av AI:s andel, och omärkta upptäckter förblir okända, inte enbart mänskliga.

Microsofts Windows-ledning kopplar också uttryckligen uppskalad AI-upptäckt till fler säkerhetsfixar i releaser. Rapporten läser det som att det fastställer ett bidrag och en rimlig operativ mekanism. Den kvantifierar inte hur stor del av den samlade ökningen som skulle ha inträffat utan AI.

Tre varningar från rapporten är värda att ha i åtanke:

• Kampanjtakt är inte branschmultiplikatorer. Mozilla bekräftade 22 CVE:er från en rapporterad tvåveckorskampanj, ungefär 11 i veckan. Den takten hör till den kampanjen, och det finns ingen matchad kontrafaktisk jämförelse med enbart mänsklig upptäckt.
• Andra förklaringar verkar vid sidan av AI. Microsoft rapporterar ett utökat omfång för sitt bug bounty-program, fler deltagande forskare och AI-stödd forskning under samma period, inklusive över 300 rapporter från ett område som tidigare inte var berättigat i sin granskning av bug bounty-programmet i augusti 2026. Rensning av eftersläpning och tilldelningspraxis kan också förändra serien.
• Räkneenheten kan vilseleda. Mozilla rapporterade 271 buggar som hittats med en AI-modell och åtgärdats i Firefox 150, medan 316 internt upptäckta buggar från flera tekniker grupperades under tre sammanslagna CVE:er. De 271 är inte 271 CVE:er, så CVE-summor mellan leverantörer räknar publicerade identifierare, inte underliggande defekter.

Vad rapporten belägger: releasetakt

Rapporten följer sex releaseströmmar för program: Chrome, Edge, Firefox, Visual Studio Code, Notepad++ och 7-Zip. Det här är en strategiskt utvald panel, inte en totalundersökning av Windows-programvara. Under det senaste fullständiga året gav strömmarna mellan 4 releasedagar (7-Zip) och 69 (Edge). Under de tre fullständiga åren gick Edge från 60 till 64 till 69 releasedagar, Chrome från 53 till 50 till 64, Visual Studio Code från 29 till 39 till 61 och Firefox från 30 till 40 till 44, medan Notepad++ och 7-Zip förblev glesa.

Tre stora leverantörer meddelade kortare releasecykler under studien, enligt rapporten:

• Chrome gick över från fyra till två veckor för större Stable-releaser från och med den 8 september 2026. Rapporten anger att Google kopplar den högre patchvolymen till automatiserad AI-upptäckt och rapporter från communityn, och skiljer samtidigt det nya milstolpsschemat från de pågående säkerhetsuppdateringarna.
• Edge gick över till en Stable-cykel på två veckor från och med version 152 i slutet av augusti, medan intervallet för funktioner i Extended Stable fortfarande är åtta veckor.
• Firefox meddelade en övergång från en regelbunden cykel på fyra veckor till två veckor, med start vid version 155 den 1 september 2026.

Visual Studio Code är en annan mekanism. Dess tekniska redogörelse från mars 2026 säger att agenter gjorde det möjligt att gå från ett decennium av månatliga releaser till veckovis Stable-leverans. Rapportens tolkning är att AI kan öka paketeringstrycket både genom upptäckt av sårbarheter och genom snabbare leverans av vanliga produktändringar, men ingen av redogörelserna fastställer att varje extra provtagen version orsakades av AI eller innehåller en säkerhetsfix. Det här är policyövergångar, inte observationer under ett helt år av de nya schemana. Milstolpar varannan vecka innebär ungefär 26 större releaser under ett jämnt 52-veckorsår, jämfört med ungefär 13 vid fyra veckor, och veckovis leverans innebär ungefär 52.

Ett fall från oktober 2026 visar varför versionsnummer inte räcker. Den 26 oktober publicerades PHP för Windows-byggen på nytt som 8.2.35-1, 8.3.36-1, 8.4.27-1 och 8.5.12-1 för att inkludera ett korrigerat Brotli 1.2.1 för CVE-2026-111497, medan PHP-körmiljön och källkodsversionen inte ändrades. En kontroll som bara läser PHP-versionen kan missa den korrigerade beroendenyttolasten. Rapporten använder det för att illustrera spridning av komponenter nedströms, inte flera oberoende AI-upptäckter.

Vad rapporten inte fastställer

Rapporten är rak om sina begränsningar, och det är vi också.

• Ingen AI-andel. Den andel av upptäckterna som kan tillskrivas AI är omätt.
• Ingen universell hastighetsmultiplikator. Det finns ingen siffra för AI:s upptäcktshastighet som gäller hela populationen.
• Ingen förändring av intrångsrisken. Varje proportionell förändring av risken för intrång är omätt.
• Inget orsakspåstående. Studien säger inte att AI orsakade ökningen av CVE:er eller de snabbare releasecyklerna.

Innan någon orsaksmässig uppskattning kan göras säger rapporten att den behöver upptäcktsmetoder på CVE-nivå, datum för upptäckt, rapport, validering och korrigering, samt matchade produktgrupper med konsekventa tilldelningsregler, analyserade med en kontrollerad eller noggrant motiverad kvasiexperimentell design.

Vår tolkning

Allt i det här avsnittet är vår läsning av underlaget, inte ett resultat från studien.

1. Planera efter program och kanal, inte efter kalendermånad. En panel som sträcker sig från 4 till 69 releasedagar om året kan inte beskrivas av en enda månatlig patchkalender. Vi läser förändringen som en övergång från planering per månad till planering per program och releaseström.
2. En release är ett beslut, inte ett jobb. Rapporten skiljer mellan observerade leverantörsreleaser, versioner som valts efter tillämplighetsbedömning, kvalificeringskörningar, centralt byggda artefakter och installationer på slutpunkter. Antalet releasedagar överskattar paketeringsarbetet, och en snabbare leverantörstakt gör selektivt införande och riskbaserad validering viktigare, vilket rapporten också anger.
3. Detekteringslogiken är där leverantörsförändringar slår först. PHP-exemplet tyder på att detektering enbart på version är en svag kontroll när en leverantör publicerar ett paket på nytt med en korrigerad komponent. Vi skulle även kontrollera paketrevision, komponentidentitet eller en godkänd filhash.
4. Bättre prevention kan samexistera med fler CVE:er. Rapportens egna scenarier, som den kallar författarens bedömning och inte kalibrerade sannolikheter, är att offentliggörandet kan förbli förhöjt eller volatilt från slutet av 2026 till 2028 när AI hittar äldre brister, och att varaktig analys före release kan sänka antalet sårbarheter som slipper igenom i ny kod hos ISV:er som inför det, senast omkring 2029 till 2031, om resultaten valideras och grundorsaker åtgärdas. Urvalet kan inte säga när, eller om, antalet CVE:er når sin topp.

Rapportens driftmodell för paketeringsteam

Det här är ett förslag som härletts ur underlaget, inte ett resultat som observerats i studien. Det har fyra delar.

• Löpande mottagning av releaser, med automatiserad daglig bevakning för att identifiera tillämpliga releaser, supportdeadlines och brådskandegrad och för att dirigera undantag.
• Separata spår efter releasebeteende, för snabba, förutsägbara och glesa releaseströmmar, plus program som leverantören eller en katalog underhåller, var och en med sin egen rytm (visas nedan).
• Belägg för att varje uppdatering körs. Att leverantören gjort något tillgängligt bevisar inte att en slutpunkt har installerat rätt gren, startats om eller fått en sårbar inbäddad komponent utbytt.
• Automatisering för utförande, människor för ansvar. Automatisering kan driva bygget, distributionen och testkörningen, medan människor äger vad som testas, vad som räknas som godkänt och vilka undantag som är acceptabla.

Rapportens föreslagna arbetsspår. De är driftrytmer, inte tidsfrister som leverantörer föreskriver.

Två förtydliganden från rapporten håller det här ärligt. Daglig bevakning betyder inte att varje app byggs om manuellt varje dag, och en påskyndad väg finns kvar när utnyttjande, exponering, indragen support eller leverantörens instruktioner gör det olämpligt att vänta. Den mänskliga delen är viktig eftersom varje grönt resultat bara stöder sitt eget påstående: "det installerades" stöder ett installationspåstående, "det startade" ett startpåstående och "arbetsflödet godkändes" det angivna arbetsflödet, de angivna uppgifterna, identiteten och assertions. Vår tidigare studie MSIX i stor skala skilde av samma skäl mellan paketskapande, installation, start och ett fullständigt godkänt smoke test.

Där EtherApps Forge passar in

Studien utvärderar varken EtherApps Forge eller någon kommersiell produkt, och EfficientEther redovisar sitt intresse av EtherApps Forge i rapporten. För de team som drabbas av snabbare leverantörsreleaser fångar EtherApps Forge program där de redan körs och bygger signerade MSIX-, MSI-, Intune- och App Attach-paket. Dess arbetsflöde för agentisk programpaketering rekommenderar en väg utifrån programmets verkliga fotavtryck, och MSIX-paketering och distribution beskriver hur de paketen når Intune och Azure Virtual Desktop. Om du är en ISV som levererar till hanterade Windows-miljöer beskriver MSIX-paketering för utvecklare och ISV:er hur man bygger, signerar och validerar MSIX i en befintlig releasepipeline. För bredare underlag om paketeringskostnader och beredskap, se läget för programpaketering 2026.

Hämta forskningen om Windows-patchning för att läsa underlaget, begränsningarna och den föreslagna driftmodellen i sin helhet.