L’IA sta cambiando la sicurezza del software open source: la responsabilità del ciclo di vita del software deve cambiare con essa.

Quando Drupal ha reso nota la CVE-2026-9082 a maggio, sono stati segnalati tentativi di sfruttamento entro 48 ore. Quella finestra di tempo sempre più breve tra la divulgazione e lo sfruttamento illustra la nuova realtà che le organizzazioni che si affidano al software open source devono affrontare. Hanno meno tempo che mai per valutare il rischio e rispondere prima che le vulnerabilità vengano attivamente mirate.

L’IA sta accelerando questo cambiamento aumentando drasticamente la velocità e la portata della scoperta delle vulnerabilità. Mentre la scoperta delle vulnerabilità si accelera, la sfida per le imprese non è più solo l’identificazione delle vulnerabilità, ma assicurarsi che il software di cui dipendono rimanga sicuro, supportabile e resiliente durante l’intero ciclo di vita.

L’IA sta accelerando le minacce più velocemente di quanto le imprese possano rispondere

Gli strumenti alimentati dall’IA stanno accelerando la scoperta delle vulnerabilità e abbassando la barriera per lo sviluppo degli exploit, riducendo il tempo che le organizzazioni hanno per valutare il rischio e rispondere. Le nuove proiezioni dell’industria di FIRST stimano che circa 66.000 CVE saranno rese note nel 2026, una revisione al rialzo dell’11% rispetto alle previsioni di febbraio, dopo che le segnalazioni hanno superato del 46% il ritmo previsto fino ad aprile.

FIRST osserva giustamente che il rischio sfruttabile non è cresciuto allo stesso ritmo del volume grezzo, e che la triage di KEV e EPSS può assorbire l’ondata. Ma la triage-e-patch presuppone che esista una patch. Per il software costruito su framework obsoleti, non esiste, e l’intero modello di priorità crolla esattamente nel punto in cui conta di più.

Nel frattempo, i team di sicurezza non operano alla velocità delle macchine. Devono ancora determinare quali sistemi sono interessati, valutare il rischio aziendale, testare le correzioni e distribuire gli aggiornamenti senza interrompere le operazioni. Per le organizzazioni che si affidano al software open source, questa sfida diventa ancora più grande quando i componenti aziendali critici hanno raggiunto la fine del ciclo di vita e non ricevono più patch di sicurezza dai loro maintainer originali.

Il risultato è un divario sempre più ampio tra l’identificazione delle vulnerabilità e la loro effettiva mitigazione. Le organizzazioni hanno bisogno di più della visibilità sulle vulnerabilità. Hanno bisogno della fiducia che il software di cui dipendono rimarrà sicuro e supportabile durante l’intero ciclo di vita.

Il software non supportato sta diventando un rischio crescente per le imprese

Molte organizzazioni continuano a utilizzare versioni obsolete di framework open source come Drupal, Spring e AngularJS perché sostituire le applicazioni aziendali critiche è costoso, disruptivo e spesso richiede anni per essere completato.

Questa realtà sta collidendo sempre più con le nuove aspettative normative. I framework come l’Atto di resilienza cibernetica dell’UE, DORA, NIS2 e PCI DSS 4.0 pongono maggiore enfasi sulla manutenzione del software, sulla visibilità della catena di approvvigionamento e sul supporto del software continuo, rendendo il software non supportato un problema di conformità e operativo crescente.

Poiché la modernizzazione spesso richiede anni, le organizzazioni hanno bisogno di una strategia per mantenere il software sicuro e supportato durante la transizione.

Le organizzazioni hanno bisogno di visibilità sul ciclo di vita, non solo sulla visibilità delle vulnerabilità

La maggior parte delle organizzazioni ha investito molto in strumenti progettati per identificare le vulnerabilità in tutti i loro ambienti. Quegli strumenti rispondono alla domanda di dove si trovino le vulnerabilità. Non affrontano un’altra domanda che sta diventando altrettanto importante: è questo software ancora supportabile?

Rispondere a questa domanda richiede alle organizzazioni di guardare oltre la gestione delle vulnerabilità. Hanno bisogno di visibilità su是否 i componenti open source aziendali critici sono ancora mantenuti attivamente, se stanno per raggiungere la fine del ciclo di vita o se non ricevono più il supporto della comunità, e di una strategia per mantenere quei sistemi sicuri fino a quando la modernizzazione non sarà completata.

I leader aziendali dovrebbero concentrarsi su tre priorità:

• Sapere cosa si possiede. Identificare il software non supportato prima che le vulnerabilità, le audizioni o gli incidenti lo impongano, e capire quali applicazioni aziendali critiche dipendono da esso.
• Pianificare la modernizzazione sicura. Inserire la pianificazione del ciclo di vita nell’acquisto, nello sviluppo e nelle strategie di modernizzazione, con piani chiari per mantenere il software in modo sicuro durante la transizione.
• Trattare il supporto del software come una priorità aziendale. Mentre gli ecosistemi del software diventano più complessi, il supporto del software a lungo termine dovrebbe essere trattato come una capacità aziendale strategica e non solo come una preoccupazione ingegneristica.

L’IA sta cambiando il modo in cui il software viene costruito, il modo in cui le vulnerabilità vengono scoperte e il modo in cui le organizzazioni sono attese a rispondere. Ciò che non è cambiato è la responsabilità aziendale di mantenere il software di cui già si affidano in modo sicuro. Mentre l’IA ridisegna la sicurezza del software open source, il successo dipenderà dal trattare la responsabilità del ciclo di vita del software come una capacità di sicurezza fondamentale, non solo come una considerazione tecnica.

Le organizzazioni che avranno successo non saranno necessariamente quelle che applicheranno le patch più velocemente. Saranno quelle che potranno gestire con fiducia il rischio del software durante l’intero ciclo di vita, mantenendo le applicazioni aziendali critiche sicure e operative mentre si modernizzano a modo loro.