In circa il 60% delle violazioni, era già disponibile una patch quando gli attaccanti sono entrati. Questa conclusione emerge dal report di J.P. Morgan di luglio 2026, “Patchmageddon”, e sposta la domanda dall’esistenza di una correzione al tempo necessario per distribuirla.
Questa finestra si sta riducendo rapidamente. Lo stesso report descrive strumenti di AI in grado di decodificare il funzionamento di una patch appena rilasciata e trasformarla in un exploit funzionante in pochi minuti. Ogni giorno in cui una patch disponibile resta non distribuita è un giorno che gli attaccanti possono sfruttare.
Per le app di terze parti gestite in Microsoft Intune, molti di quei giorni vengono assorbiti dal packaging. I team IT scaricano il programma di installazione, creano il pacchetto, scrivono le regole di rilevamento, testano e assegnano, poi ripetono tutto per ogni app e ogni release. Il risultato è un ritardo nell'applicazione delle patch che nessuno aveva previsto.
Ecco quanto rapidamente si sta chiudendo la finestra di sfruttamento, dove il packaging delle app in Intune rallenta le cose e cosa serve per colmare il divario.
Con quale velocità oggi gli attaccanti sfruttano le nuove vulnerabilità
Sfruttare le vulnerabilità è ormai il modo più comune con cui gli aggressori riescono a introdursi. Secondo il Data Breach Investigations Report 2026 di Verizon, lo sfruttamento delle vulnerabilità ha rappresentato il 31% degli accessi iniziali nelle violazioni, in aumento rispetto al 20% dell'anno precedente.
Molti di questi attacchi iniziano subito. Secondo il Zero Day Clock, oltre un quarto delle vulnerabilità aggiunte di recente all’elenco di quelle sfruttate nella prima metà del 2026 era già sotto attacco il giorno stesso in cui è diventato pubblico.
Le patch non hanno tenuto il passo. Verizon ha rilevato che le organizzazioni hanno impiegato una mediana di 43 giorni per correggere completamente vulnerabilità note già sfruttate, rispetto ai 32 giorni precedenti, e solo circa un quarto di esse è stato corretto del tutto.
Anche le vecchie vulnerabilità continuano a essere sfruttate. In una sola settimana alla fine di agosto 2026, la vulnerabilità tipica presa di mira dagli attaccanti era stata resa pubblica quattro anni prima, secondo il Zero Day Clock.
Un ciclo di patching misurato in settimane lascia esposte le app di terze parti durante il periodo più rischioso. Un aggiornamento che non viene mai distribuito le lascia esposte per anni.
Perché le patch disponibili non vengono applicate
Se le patch esistono, perché così tante restano non distribuite? Secondo il 2026 Open Source Landscape Report di TuxCare, il 61% degli incidenti di sicurezza tra gli utenti enterprise dell’open source ha coinvolto patch disponibili ma mai applicate. I vincoli di downtime sono stati il motivo più comune dei ritardi, citato dal 43% dei rispondenti.
Questa indagine si è concentrata sugli ambienti open source, ma le stesse cause emergono ovunque i team IT distribuiscano aggiornamenti:
Paura di rompere qualcosa. Un aggiornamento che compromette un'app business-critical o forza un riavvio non pianificato diventa esso stesso un incidente. Quando i test non sono stati eseguiti, aspettare sembra più sicuro che distribuire.
Troppo poche persone con le competenze giuste. Per creare correttamente un'app Win32 servono competenze specialistiche. Quando queste competenze sono nelle mani di una o due persone, ogni aggiornamento deve aspettare la loro disponibilità.
Ogni aggiornamento è un progetto a sé. I fornitori terzi rilasciano secondo le proprie tempistiche, e ogni rilascio richiede la stessa preparazione prima di poter essere distribuito. Il lavoro raramente si raggruppa in modo ordinato, quindi la coda cresce più velocemente di quanto si riduca.
Nessuna prova che le patch siano state applicate. Senza una conferma a livello di dispositivo, l'IT non può sapere quali endpoint eseguono ancora la versione vulnerabile e le lacune passano inosservate finché qualcuno non si mette a cercarle.
Dove il packaging delle app in Intune rallenta il patching di terze parti
Sebbene Intune gestisca bene gli aggiornamenti di Windows e Microsoft 365, le app di terze parti sono più difficili da gestire. Enterprise App Management di Microsoft aiuta offrendo un catalogo di app Windows Microsoft e non Microsoft già preparate, che Intune può mantenere aggiornate. Tuttavia, il catalogo include solo le app preparate da Microsoft e Microsoft non garantisce che un'app richiesta verrà aggiunta.
Le app fuori dal catalogo, le app personalizzate e interne e i tenant senza Enterprise App Management continuano a seguire il processo standard Win32.
Per ogni nuovo rilascio, il processo in genere si presenta così:
Scarica l’installer dal fornitore e conferma che sia la versione e l’architettura corrette.
Trova i comandi di installazione silenziosa e disinstallazione. Intune richiede che le app Win32 vengano installate senza interazione dell’utente, quindi qualcuno deve capire quali opzioni supporta ciascun programma di installazione.
Converti il programma di installazione in un file .intunewin utilizzando Microsoft Win32 Content Prep Tool.
Scrivi regole di rilevamento così Intune può confermare che l'app è stata installata correttamente.
Configura la sostituzione in modo che la nuova versione rimpiazzi quella precedente.
Testa il pacchetto su un dispositivo di riserva o una macchina virtuale prima che arrivi agli utenti.
Assegna l'app ai gruppi giusti.
Verifica la distribuzione e risolvi i problemi di eventuali dispositivi in cui non è andata a buon fine.
Poi il fornitore rilascia un altro aggiornamento e il ciclo ricomincia. Moltiplica questi passaggi per ogni app di terze parti nell’ambiente e per ogni release che ciascuna rilascia, e la distribuzione di app Win32 con Intune diventa un arretrato costante. È in quell’arretrato che “disponibile” si trasforma in settimane.
Cosa serve per un processo di patching di terze parti più rapido
Il report di J.P. Morgan raccomanda alle organizzazioni di utilizzare le versioni software più recenti e di ridurre i tempi di test e distribuzione delle patch. Per le app di terze parti in Intune, tutto si riduce ad alcuni requisiti operativi:
Un inventario aggiornato delle app di terze parti. Ogni decisione sul patching parte dal sapere quali app e versioni sono in esecuzione su quali dispositivi.
Fonti affidabili e verificate per gli installer. Prelevare gli installer da fonti verificate riduce il rischio di distribuire un pacchetto manomesso o dannoso.
Packaging automatizzato. I comandi di installazione e disinstallazione silenziosa, le regole di rilevamento e la sostituzione devono essere generati automaticamente per ogni release, senza script scritti a mano.
Rilevamento automatico delle nuove versioni. Quando un fornitore rilascia un aggiornamento, il nuovo pacchetto dovrebbe essere creato senza aspettare che qualcuno si accorga del rilascio.
Test automatizzati e scansione di sicurezza prima della distribuzione. Testare ogni build su una macchina pulita elimina uno dei motivi principali per cui i team rimandano gli aggiornamenti.
Rilascio graduale. Distribuire prima a un gruppo pilota limita l’impatto nel caso in cui un aggiornamento causi problemi.
Controlli per l'utente finale. Rinvii, prompt di riavvio e periodi di tolleranza consentono di distribuire gli aggiornamenti senza interrompere chi è nel mezzo di un'attività.
Stato della distribuzione e visibilità per gli audit. La reportistica per dispositivo conferma che ogni patch sia stata effettivamente applicata e lascia una traccia per gli audit.
Domande per misurare la finestra di patching di terze parti
Prima di cambiare strumenti o processi, è utile sapere a che punto è oggi il tuo team. Queste domande mostrano quanto sia davvero ampia la tua finestra di esposizione:
Quanti giorni passano tra il rilascio di un fornitore e l'assegnazione in Intune per le tue 10 principali app di terze parti? Questo numero rappresenta la tua reale finestra di patching ed è spesso più lungo di quanto i team si aspettino.
Quante persone del tuo team sanno creare correttamente il pacchetto di un'app Win32? Se la risposta è una o due, ogni aggiornamento dipende dalla loro disponibilità.
Quando hai rimandato l’ultima volta un aggiornamento perché i test non erano completati? Rinvii frequenti indicano un collo di bottiglia nei test, non nella pianificazione.
Puoi dimostrare che una patch è arrivata a tutti i dispositivi? Senza una conferma per ogni singolo dispositivo, un aggiornamento che sembra completo potrebbe comunque lasciare gli endpoint esposti.
Come il packaging agentico accorcia il percorso dal rilascio alla distribuzione
Il report di J.P. Morgan sottolinea un aspetto facile da non notare tra tutti gli avvertimenti: gli stessi strumenti di AI usati per trovare e sfruttare le vulnerabilità possono anche aiutare a correggerle. L’agentic packaging applica questa idea alla parte più lenta del patching di terze parti.
In un flusso di lavoro di packaging agentico, gli agenti AI si occupano dei passaggi ripetitivi del packaging delle app in Intune. Leggono l’installer, determinano i comandi di installazione e disinstallazione silenziosa, creano il pacchetto e generano la logica di rilevamento. Ogni build viene poi testata su una macchina pulita e i risultati vengono inviati a un amministratore per la revisione prima che qualsiasi cosa venga pubblicata su Intune.
Scopri l'agentic packaging in azione il 21 ottobre
Una patch già esistente è utile solo quanto il tempo necessario per raggiungere ogni dispositivo. Per le app di terze parti in Intune, gran parte di questo tempo viene impiegata nel packaging.
Il packaging agentico elimina il lavoro ripetitivo da ogni rilascio, così le nuove versioni possono passare attraverso i test e a una distribuzione graduale senza restare in coda.
Splashtop ospita un webinar di 30 minuti, “Dal packaging manuale a quello agentico: semplificare la distribuzione delle app con Microsoft Intune”, il 21 ottobre alle 8:00 PT / 11:00 ET. Il Microsoft MVP Maxime Guillemin e Brandon Shopp, Head of Product di Splashtop, mostreranno come l’AI e i flussi di lavoro agentici riducono l’impegno richiesto per il packaging e gli errori, inclusa una dimostrazione pratica del packaging agentico in azione.
