Microsoft Corregge Quasi 1.000 Falle di Sicurezza, e i Team di Patch Affrontano il Collo di Bottiglia

Microsoft ha corretto quasi 1.000 falle di sicurezza nel suo aggiornamento di settembre, incluse due vulnerabilità di Windows già sfruttate dagli aggressori. Il lotto record riguarda Windows, Office, Exchange Server, SharePoint, SQL Server, Azure e diversi strumenti di sviluppo. Trasforma inoltre il Patch Tuesday in una prova della rapidità con cui i difensori riescono a convertire i dati sulle vulnerabilità in aggiornamenti sicuri per gli ambienti di produzione.

L'aspetto più rilevante non è semplicemente che Microsoft abbia individuato più difetti. Microsoft afferma che l'intelligenza artificiale aiuta ora i suoi ricercatori a esaminare codice complesso su una scala che le revisioni manuali non potrebbero sostenere. Questa maggiore capacità può far emergere le vulnerabilità prima, ma produce anche più patch che i clienti devono valutare, testare, pianificare e monitorare.

Questo crea una corsa sbilanciata. L'AI può accelerare la scoperta all'interno di un'azienda software, mentre il deployment resta vincolato da inventari, finestre di manutenzione, test di compatibilità e approvazioni umane. Microsoft può generare correzioni più rapidamente di quanto molte organizzazioni riescano ad assorbirle in sicurezza. Il vantaggio in termini di sicurezza dipende quindi dalla capacità delle operazioni di patching di tenere il passo con il nuovo ritmo di scoperta.

Microsoft Corregge Quasi 1.000 Falle di Sicurezza in un Unico Rilascio

Il rilascio di settembre ha stabilito un record, ma i rischi più urgenti sono concentrati in un gruppo molto più ristretto di vulnerabilità.

Microsoft ha pubblicato gli aggiornamenti mensili di sicurezza l'8 settembre, affrontando 974 Common Vulnerabilities and Exposures di Microsoft, ovvero CVE. Un CVE è un identificatore standardizzato per una falla di sicurezza resa pubblica. Il lotto è stata la più grande raccolta mensile mai pubblicata da Microsoft.

I conteggi indipendenti differiscono leggermente perché i ricercatori adottano criteri di inclusione diversi. Alcuni escludono falle già affrontate o separano le vulnerabilità ereditate da Chromium. Questo spiega le segnalazioni che vanno dalla fascia media dei 960 fino ai primi 970, anziché indicare diversi rilasci di patch distinti.

Le note di rilascio di Microsoft forniscono l'inventario autorevole dei prodotti, mentre i ricercatori indipendenti perfezionano quei dati per l'uso operativo. Nonostante le differenze di conteggio, la cifra principale resta chiara. Si è trattato di un rilascio di sicurezza Microsoft senza precedenti secondo qualsiasi metodologia comune.

Il lotto record di patch includeva centinaia di vulnerabilità di Windows e Office. SecurityWeek ha contato 723 falle di Windows e 222 nell'intera famiglia Office, di cui 111 riguardavano Office 2016.

Microsoft ha inoltre affrontato 62 vulnerabilità di SQL Server, 22 negli strumenti di sviluppo, 16 in SharePoint Server e 12 in Azure. Skype for Business ed Exchange Server rappresentavano rispettivamente altre 10 e nove vulnerabilità.

Questi totali non significano che ogni cliente utilizzi 974 prodotti vulnerabili. L'esposizione di un'azienda dipende dai sistemi operativi, dalle applicazioni installate, dai servizi cloud, dai ruoli dei server, dalle configurazioni e dall'accessibilità di rete. Molte organizzazioni scopriranno che solo una parte del rilascio si applica al proprio ambiente.

Tuttavia, l'ampiezza conta. Le imprese raramente utilizzano un'unica generazione di Windows o una sola configurazione standardizzata di Office. Spesso mantengono contemporaneamente workstation per sviluppatori, macchine virtuali, server di database, piattaforme di collaborazione e applicazioni aziendali meno recenti.

Due vulnerabilità di Windows meritano attenzione immediata perché Microsoft ha identificato uno sfruttamento attivo. CVE-2026-85880 interessa Windows Advanced Local Procedure Call, o ALPC. Windows utilizza ALPC per comunicazioni ad alta velocità tra processi sullo stesso computer.

La vulnerabilità riguarda un buffer overflow basato sull'heap. Microsoft afferma che un aggressore con esecuzione di codice all'interno di un AppContainer a basso privilegio può evadere da quell'ambiente ristretto e ottenere privilegi System. L'exploit non richiede ulteriore interazione dell'utente dopo che l'aggressore ha ottenuto la necessaria posizione locale.

La seconda falla sfruttata, CVE-2026-81963, interessa lo Windows Update Stack. Questa raccolta di componenti installa e gestisce gli aggiornamenti di Windows. La debolezza riguarda il seguimento dei collegamenti, in cui il software accede a un file o a una posizione referenziata senza risolverne in modo sicuro la destinazione.

Un aggressore può usare la falla per elevare i privilegi locali a System. La sua collocazione nel meccanismo di aggiornamento ne aumenta la rilevanza operativa, anche se Microsoft non ha divulgato chi la stia sfruttando. Le informazioni pubbliche non stabiliscono neppure la scala o gli obiettivi degli attacchi.

CISA ha aggiunto entrambe le vulnerabilità al proprio catalogo delle falle sfruttate. L'inclusione conferma prove di sfruttamento, ma non dimostra che gli attacchi siano diffusi.

Questa distinzione dovrebbe guidare la risposta. Il totale record descrive il carico di lavoro, mentre le prove di sfruttamento identificano il pericolo immediato. Trattare ogni voce come ugualmente urgente consumerebbe il tempo necessario per le vulnerabilità già utilizzate dagli aggressori.

Il rilascio di settembre cambia quindi più di una statistica mensile. Rende la prioritizzazione il controllo di sicurezza centrale. Le organizzazioni devono identificare le vulnerabilità applicabili, raggiungibili e sfruttate prima che il mero volume travolga il loro processo di deployment.

La Scoperta delle Vulnerabilità con l'AI Sta Espandendo la Pipeline delle Patch

I rilasci più ampi di Microsoft riflettono un sistema di scoperta in grado di ispezionare più codice, ma individuare una falla resta solo il primo passo.

Microsoft sta integrando la ricerca sulle vulnerabilità assistita dall'AI in Windows, Azure, nei sistemi di identità e in altri flussi di lavoro ingegneristici. L'azienda descrive questo lavoro come un modo per esaminare superfici di codice che richiedono competenze e tempo significativi per essere sottoposte ad audit manuale.

Un sistema Microsoft, noto con il nome in codice MDASH, analizza componenti complessi quali il kernel di Windows, Hyper-V, networking e Active Directory. Queste aree impongono confini di fiducia e gestiscono risorse tra processi, macchine o ambienti virtuali.

Secondo Microsoft, il sistema combina ragionamento incentrato sul codice con flussi di lavoro per validazione e correzione. Le rilevazioni confermate possono comparire in GitHub Advanced Security, Azure DevOps e Microsoft Defender. Gli ingegneri possono quindi assegnare la responsabilità, creare elementi di lavoro, esaminare le correzioni e bloccare le build interessate.

Questa integrazione conta perché un avviso generato dall'AI non è automaticamente una vulnerabilità. I team di sicurezza devono riprodurre il comportamento, stabilire se gli aggressori possano raggiungerlo, valutarne l'impatto e distinguere i difetti dai falsi positivi. Una rilevazione valida deve poi superare la revisione del codice e i test di regressione.

Il flusso di lavoro AI per la sicurezza pubblicato da Microsoft sottolinea che gli esseri umani restano coinvolti. L'azienda afferma che l'AI amplia la portata dei ricercatori anziché sostituire gli specialisti che comprendono il comportamento dei sistemi a basso livello.

Microsoft aveva già affermato che i modelli recenti si stavano avvicinando ai ricercatori umani esperti in alcuni compiti di scoperta delle vulnerabilità. Ha inoltre dichiarato che i sistemi AI possono operare in modo continuo, limitati soprattutto dalle risorse computazionali disponibili. Si tratta di affermazioni dell'azienda e la valutazione indipendente a lungo termine resta incompleta.

Il lotto di settembre offre comunque evidenza di un importante cambiamento operativo. Microsoft sta elaborando un numero di rilevazioni molto maggiore rispetto a quanto richiesto dalla sua precedente cadenza mensile. Questa crescita segue altri rilasci insolitamente grandi nel corso del 2026.

A luglio, le note di rilascio ufficiali di Microsoft elencavano 663 CVE Microsoft. Ars Technica ha riferito che ricercatori esterni avevano contato circa 570 vulnerabilità appena corrette secondo criteri più restrittivi. Agosto ha portato un altro rilascio contenente centinaia di correzioni.

A settembre, il volume mensile è nuovamente aumentato. Ars ha stimato che Microsoft avesse corretto 2.760 vulnerabilità nel corso del 2026 entro il rilascio di settembre. Quel totale era già più del doppio del conteggio dell'anno precedente secondo la metodologia della pubblicazione.

Questo andamento non dimostra che il software Microsoft sia improvvisamente diventato meno sicuro. I conteggi delle vulnerabilità mescolano bug introdotti di recente con difetti più vecchi individuati dai ricercatori solo di recente. Una migliore scoperta può far apparire peggiori i numeri pubblicati di un prodotto, riducendone però il rischio nascosto.

Un'analogia con un magazzino aiuta a spiegare il ribaltamento. Installare luci più luminose può rivelare più inventario danneggiato senza causare il danno. L'operatore affronta quindi una coda di riparazioni più ampia perché problemi prima invisibili sono diventati gestibili.

L'AI cambia anche quale codice può ricevere attenzione costante. Le revisioni manuali della sicurezza tendono a concentrarsi su componenti esposti o storicamente problematici. L'analisi automatizzata può ispezionare ripetutamente percorsi poco visibili, interfacce legacy e interazioni in una vasta base di codice.

Questa copertura più ampia è preziosa per Windows, che deve supportare estesi requisiti di compatibilità hardware, applicativa ed enterprise. È inoltre probabile che mantenga elevati i conteggi delle patch mentre Microsoft esamina codice accumulato attraverso molte generazioni di prodotti.

Tuttavia, la produttività della scoperta è solo una misura del successo. Microsoft deve validare le rilevazioni, produrre correzioni corrette e prevenire regressioni. I clienti devono distribuire tali correzioni prima che gli aggressori trasformino le informazioni divulgate in exploit affidabili.

Microsoft Corregge Quasi 1.000 Falle di Sicurezza descrive quindi l'output di una linea di produzione della sicurezza più ampia. Non dimostra che l'intera linea, incluso il deployment presso i clienti, abbia accelerato allo stesso ritmo.

Il Vero Collo di Bottiglia Si Sposta dalla Scoperta dei Bug al Deployment delle Correzioni

L'AI può aumentare la capacità di scoperta di Microsoft, ma il patching enterprise procede ancora al ritmo dei test, della responsabilità e del controllo delle modifiche.

Un aggiornamento di sicurezza non protegge semplicemente perché Microsoft lo pubblica. La protezione inizia quando un'organizzazione identifica le risorse interessate, ottiene l'aggiornamento, lo testa, lo distribuisce e conferma che l'installazione sia riuscita.

Ogni fase contiene attrito. Gli inventari delle risorse possono essere incompleti, specialmente quando i team gestiscono computer remoti, carichi di lavoro cloud, sistemi di laboratorio e unità aziendali acquisite. Il software non supportato può restare connesso perché un progetto di sostituzione non è terminato.

I test introducono un altro vincolo. Gli aggiornamenti di Windows e Office possono influire su autenticazione, driver dei dispositivi, macro, componenti del browser, connessioni ai database o applicazioni aziendali specializzate. I team operativi hanno bisogno di prove che una correzione non interromperà ricavi, produzione, assistenza sanitaria o altro lavoro essenziale.

Un rilascio da 974 CVE non richiede 974 installazioni separate. Microsoft distribuisce molte correzioni di Windows tramite pacchetti cumulativi, che combinano correzioni attuali e precedenti. Questo modello di distribuzione semplifica l'installazione ma non elimina la valutazione del rischio.

I team di sicurezza devono comunque mappare le singole vulnerabilità alle risorse e ai servizi aziendali. Devono stabilire se un aggiornamento cumulativo raggiunga ogni sistema interessato. Devono inoltre predisporre piani di fallback quando un aggiornamento causa problemi di compatibilità.

Il rilascio di settembre includeva nuovi Servicing Stack Updates per diverse piattaforme meno recenti. Il servicing stack è il componente di Windows che installa gli aggiornamenti del sistema operativo. Problemi a quel livello possono impedire la corretta installazione delle successive correzioni di sicurezza.

Gli ambienti più datati meritano particolare attenzione perché i loro percorsi di manutenzione sono spesso più complessi. Un’organizzazione potrebbe necessitare di accordi di supporto esteso, finestre di indisponibilità ristrette o dell’approvazione di un fornitore di applicazioni. La macchina più esposta è talvolta anche la più difficile da modificare.

Per questo il conteggio mensile può diventare fuorviante. Una falla a bassa gravità su una workstation isolata può meritare meno attenzione di una singola debolezza sfruttata su un server esposto a Internet. Anche una valutazione critica non rivela automaticamente se un attaccante possa raggiungere il componente interessato.

La ripartizione delle vulnerabilità ha identificato 20 falle che i ricercatori hanno ritenuto potenzialmente wormable. Una vulnerabilità wormable può consentire l’esecuzione di codice remoto senza autenticazione né interazione dell’utente, permettendo al software dannoso di propagarsi tra i sistemi.

La potenziale wormabilità non significa che esista già un worm funzionante. Requisiti di configurazione, esposizione di rete e affidabilità dell’exploit possono limitare il rischio pratico. Ciononostante, queste falle meritano un esame rapido perché uno sfruttamento riuscito può estendersi oltre un singolo dispositivo compromesso.

CVE-2026-55007 in Exchange Server illustra questa preoccupazione. I ricercatori hanno segnalato che un attaccante remoto potrebbe tentare l’esecuzione di codice inviando un allegato Visio dannoso. L’infrastruttura email è spesso esposta e svolge una funzione aziendale centrale, complicando la manutenzione d’emergenza.

CVE-2026-69525 interessa Remote Desktop Services e ha ricevuto un punteggio di gravità pari a 9,8. Remote Desktop può offrire un prezioso accesso amministrativo, ma le distribuzioni esposte o ampiamente raggiungibili creano anche percorsi di attacco allettanti.

SharePoint, SQL Server e i componenti di identità generano pressioni diverse. Spesso custodiscono informazioni sensibili, collegano più applicazioni o supportano flussi di lavoro interni. Un aggiornamento affrettato potrebbe interrompere servizi dipendenti, mentre un aggiornamento ritardato può lasciare esposto un bersaglio di valore.

La risposta non è testare ogni patch per lo stesso periodo. I programmi maturi creano anelli di distribuzione. Aggiornano prima un piccolo gruppo rappresentativo, osservano i risultati, estendono l’aggiornamento a gruppi più ampi e riservano una gestione speciale ai sistemi critici.

Le vulnerabilità di emergenza richiedono una corsia più rapida. I sistemi interessati da sfruttamento attivo non dovrebbero attendere dietro alle normali correzioni dei desktop. I responsabili della sicurezza e delle operazioni devono avere l’autorità di abbreviare i cicli di approvazione quando esposizione e impatto aziendale giustificano tale decisione.

Il Center for Internet Security raccomanda una correzione basata sul rischio. Le sue linee guida combinano aggiornamenti tempestivi con test, gestione automatizzata delle patch, scansione delle vulnerabilità e controlli di privilegio minimo.

Il privilegio minimo è particolarmente rilevante per le falle di Windows già sfruttate. Entrambe possono aiutare un attaccante locale a ottenere privilegi System. Limitare i privilegi iniziali di utenti e applicazioni non può eliminare queste vulnerabilità, ma può ridurre i punti di ingresso disponibili e limitare alcune catene di attacco.

Anche i controlli compensativi possono far guadagnare tempo. La segmentazione di rete può limitare l’accesso ai servizi vulnerabili. I controlli applicativi possono bloccare codice non approvato. Il rilevamento sugli endpoint può monitorare modifiche sospette ai privilegi mentre i team convalidano le patch.

Nessuno di questi controlli sostituisce l’aggiornamento. Il loro scopo è gestire l’intervallo tra la divulgazione e la distribuzione verificata. Questo intervallo diventa più significativo con l’accelerazione della scoperta delle vulnerabilità.

Un Conteggio Record Non Equivale a un’Ondata di Attacchi Record

Il volume delle patch segnala una maggiore visibilità, ma i difensori non hanno ancora prove che lo sfruttamento stia crescendo allo stesso ritmo.

Il pacchetto di settembre invita a due errori opposti. Uno è la compiacenza, perché la maggior parte delle vulnerabilità non interesserà ogni organizzazione. L’altro è il panico, perché un titolo con quattro cifre può far sembrare impossibile una prioritizzazione ordinata.

I team di sicurezza hanno bisogno di una domanda più circoscritta: quali vulnerabilità creano percorsi di attacco credibili in questo ambiente? Rispondervi richiede più dei punteggi di gravità. I team necessitano dello stato di sfruttamento, dell’esposizione degli asset, dei privilegi richiesti, dell’interazione dell’utente e del valore dei sistemi interessati.

Due vulnerabilità hanno uno sfruttamento confermato. Questa evidenza le porta davanti alle falle con un impatto soltanto teorico. Il catalogo di CISA fornisce un forte segnale di prioritizzazione perché richiede prove che attori malevoli abbiano utilizzato un problema.

Tuttavia, lo sfruttamento confermato non rivela tutto. Microsoft non ha identificato pubblicamente gli attaccanti, le vittime, le dimensioni della campagna o i metodi di accesso iniziale collegati ai due zero-day di Windows. I difensori dovrebbero evitare di inventare una narrazione della campagna a partire da dati incompleti.

Analogamente, le 20 vulnerabilità potenzialmente wormable meritano attenzione senza essere descritte come worm attivi. Una vulnerabilità può soddisfare le condizioni tecniche per una propagazione automatizzata pur rimanendo difficile da sfruttare in modo affidabile nelle reti reali.

I ricercatori hanno inoltre avvertito che rilasci di patch più grandi creano pagliai più grandi. Satnam Narang di Tenable ha sostenuto che il numero di problemi che interessano una tipica organizzazione resta molto inferiore al totale mensile. Il suo punto di vista favorisce il triage contestuale rispetto al conteggio grezzo.

La sfida è decidere quali aghi contano prima che li trovino gli attaccanti. La pubblicazione fornisce i dettagli tecnici di cui i difensori hanno bisogno, ma tali dettagli possono anche aiutare gli sviluppatori di exploit. Gli strumenti di IA possono ridurre il tempo di analisi per entrambe le parti.

Questa dinamica a duplice uso spiega perché Microsoft sta investendo in una scoperta più rapida. Individuare e correggere una falla prima dello sfruttamento offre ai difensori un vantaggio iniziale. Pubblicare centinaia di correzioni contemporaneamente, tuttavia, divide l’attenzione su una coda molto più ampia.

Il valore a lungo termine della ricerca di bug assistita dall’IA resta incerto. I critici mettono in dubbio i costi dei modelli, i tassi di falsi positivi, la progettazione dei benchmark e lo sforzo umano necessario per convalidare gli output. I fornitori hanno inoltre incentivi a presentare i sistemi di sicurezza IA come prova dei loro investimenti più ampi.

I sostenitori indicano il crescente numero di risultati convalidati nei principali progetti software. Sostengono che le vulnerabilità nascoste restano pericolose, indipendentemente dal fatto che i ricercatori riescano o meno a vederle. In quest’ottica, un rilascio di grandi dimensioni rappresenta una visibilità tardiva piuttosto che un calo della qualità.

Entrambe le posizioni possono essere in parte vere. L’IA può identificare vulnerabilità reali producendo al contempo rumore costoso. Un sistema produttivo deve migliorare il rapporto tra risultati utilizzabili e tempo degli analisti, non semplicemente massimizzare il numero di avvisi.

Microsoft afferma di instradare i risultati convalidati nei sistemi di engineering esistenti, con responsabili nominati e modifiche al codice. Questo approccio affronta un fallimento comune nell’automazione della sicurezza, in cui l’output degli scanner si accumula senza raggiungere gli sviluppatori responsabili della correzione.

Le organizzazioni clienti necessitano di un analogo ciclo chiuso. Un record di vulnerabilità dovrebbe collegarsi a un asset, a un responsabile, a un servizio aziendale, a una decisione di distribuzione e a prove di completamento. Senza questi collegamenti, un rilevamento più rapido amplia soltanto l’arretrato.

I disaccordi sui conteggi rafforzano inoltre la necessità di precisione. Il dibattito sul conteggio mensile ha prodotto totali di 972, 974 o altre cifre vicine. I ricercatori differivano sulle correzioni di Chromium, sulle voci ripubblicate e sulle vulnerabilità affrontate in precedenza.

Queste differenze non mettono in dubbio il rilascio. Mostrano che i totali CVE sono riepiloghi contabili, non misure dirette del rischio per il cliente. Un dashboard utile dovrebbe separare i problemi appena divulgati, i prodotti applicabili, lo sfruttamento confermato, l’esposizione e lo stato di distribuzione.

Le organizzazioni dovrebbero misurare anche la qualità delle patch. Un aggiornamento che si installa con successo ma interrompe un’applicazione critica crea rischio operativo. Una patch che sembra distribuita ma lascia attivo un componente più vecchio crea una falsa fiducia.

Tassi di rollback, installazioni non riuscite, eccezioni di emergenza e asset esposti non patchati rivelano più del conteggio mensile delle CVE. Questi indicatori mostrano se un programma di sicurezza può assorbire l’output più rapido di Microsoft senza perdere il controllo.

Il rilascio di settembre non è quindi la prova che gli attaccanti abbiano già ottenuto un’accelerazione equivalente. È la prova che la scoperta e la divulgazione delle vulnerabilità sono entrate in una fase a maggior volume. L’esito difensivo resta incerto.

Cosa Dovrebbero Monitorare i Team di Sicurezza Dopo Settembre

Tre segnali mostreranno se questo rilascio record migliora la sicurezza o si limita ad ampliare l’arretrato delle patch.

Il primo segnale è l’attività di sfruttamento relativa a CVE-2026-85880 e CVE-2026-81963. Nuove linee guida di CISA, indicatori pubblici di compromissione o rapporti di incidenti più ampi ne aumenterebbero la priorità oltre le evidenze attuali.

Le organizzazioni dovrebbero monitorare gli asset Windows interessati per rilevare sospette escalation dei privilegi e modifiche insolite intorno ai componenti di aggiornamento. Dovrebbero inoltre verificare la distribuzione anziché fare affidamento soltanto sullo stato della console di gestione. Un’installazione segnalata è utile solo quando è effettivamente in esecuzione la versione protetta.

Se Microsoft o CISA collegassero una delle due falle a campagne ampie, il rilascio di settembre diventerebbe un evento attivo di gestione degli incidenti. Se lo sfruttamento rimanesse limitato, i team avrebbero comunque bisogno di una correzione tempestiva, ma potrebbero mantenere una sequenza di distribuzione controllata.

Il secondo segnale è l’affidabilità degli aggiornamenti di settembre. Problemi di compatibilità, errori di installazione o revisioni d’emergenza fuori banda rallenterebbero l’adozione da parte delle imprese. Pacchetti cumulativi stabili sosterrebbero l’affermazione di Microsoft secondo cui la sua pipeline di engineering può gestire un volume maggiore di scoperte.

I team responsabili delle patch dovrebbero monitorare i tassi di successo per gruppo di dispositivi e classe di applicazioni. Dovrebbero confrontare i guasti tra workstation standard, macchine degli sviluppatori, server e sistemi specializzati. Queste evidenze possono rivelare dove test o responsabilità necessitano di miglioramenti.

Un primo anello di distribuzione riuscito dovrebbe innescare l’espansione, non un periodo di osservazione indefinito. Le organizzazioni spesso perdono tempo tra test riusciti e approvazione su larga scala. Soglie chiare possono impedire che un processo prudente diventi un ritardo non gestito.

Il terzo segnale è la dimensione e la composizione dei prossimi rilasci di Microsoft. Un altro mese insolitamente ampio suggerirebbe che la scoperta assistita dall’IA ha cambiato permanentemente la cadenza. Un rapido calo sosterrebbe l’idea che Microsoft stia smaltendo un inventario accumulato di difetti nascosti.

La composizione conta più del totale. I difensori dovrebbero osservare la quota di falle sfruttabili da remoto, attacchi confermati, componenti di infrastruttura critica e vulnerabilità scoperte tramite i sistemi IA di Microsoft. Queste categorie riveleranno se il beneficio per la sicurezza sta diventando più significativo sul piano operativo.

Microsoft deve inoltre dimostrare che la prevenzione migliora insieme alla scoperta. Individuare vecchi bug è prezioso, ma il risultato più forte consiste nell’impedire difetti simili prima che il codice venga distribuito. Classi di falle ricorrenti suggerirebbero che la correzione non ha ancora modificato a sufficienza le pratiche di sviluppo.

Per i leader aziendali, la lezione immediata è pratica. Microsoft chiude quasi 1.000 falle di sicurezza, ma i clienti non hanno bisogno di 974 progetti di emergenza identici. Hanno bisogno di un unico processo difendibile che identifichi con coerenza il piccolo insieme di problemi che richiedono azione immediata.

Iniziate dalle due vulnerabilità Windows sfruttate. Esaminate quindi i percorsi raggiungibili di esecuzione di codice remoto, i server esposti, i sistemi di identità e i servizi di dati ad alto valore. Fate passare i restanti aggiornamenti applicabili attraverso anelli di distribuzione testati con responsabili identificabili.

Fate una domanda conclusiva dopo la chiusura della finestra di patch: la vostra organizzazione può dimostrare quali sistemi esposti restano vulnerabili, perché restano vulnerabili e quando questa condizione terminerà? Se la risposta dipende da fogli di calcolo, inventari incompleti o eccezioni informali, il rilascio record di settembre ha messo in luce una lacuna di processo tanto importante quanto qualsiasi singolo CVE.