La corsa tra chi scopre una vulnerabilità e chi prova a sfruttarla sta diventando sempre più rapida. Quando Drupal ha divulgato la falla CVE-2026-9082 a maggio, i tentativi di exploit sono stati segnalati entro 48 ore. Per le organizzazioni che dipendono da software open source, la finestra disponibile per individuare i sistemi coinvolti, valutare il rischio e intervenire si restringe così fino a mettere sotto pressione procedure costruite per tempi decisamente più lunghi.
L’intelligenza artificiale sta accelerando la scoperta delle vulnerabilità e abbassando la barriera tecnica necessaria per sviluppare nuovi exploit. Le proiezioni aggiornate di FIRST stimano che nel 2026 saranno divulgate quasi 66.000 CVE, con una revisione al rialzo dell’11% rispetto alla previsione formulata a febbraio. Fino ad aprile, infatti, le segnalazioni avevano superato del 46% il ritmo previsto, indicando una crescita che i team di sicurezza devono assorbire senza poter operare alla stessa velocità delle macchine.
Il volume grezzo delle vulnerabilità, tuttavia, non coincide automaticamente con un aumento equivalente del rischio sfruttabile. Strumenti di classificazione come KEV ed EPSS possono aiutare a stabilire le priorità e a concentrare gli interventi sulle minacce più concrete. Il modello basato su selezione e aggiornamento incontra però un limite strutturale: presuppone che esista una patch. Quando un’applicazione utilizza framework arrivati a fine vita, l’aggiornamento di sicurezza può non essere più distribuito e la normale procedura di gestione delle vulnerabilità perde efficacia proprio sui sistemi più difficili da sostituire.
I responsabili della sicurezza devono ancora identificare gli ambienti esposti, stimare l’impatto sul business, collaudare le correzioni e distribuirle senza interrompere le attività. Il divario tra scoperta e rimedio si amplia ulteriormente quando componenti essenziali non ricevono più supporto dai manutentori originari. Molte imprese continuano a utilizzare versioni obsolete di framework come Drupal, Spring e AngularJS: sostituire applicazioni critiche può essere costoso, provocare disservizi e richiedere anni, mentre le vulnerabilità continuano a emergere.
Alla pressione tecnica si aggiungono aspettative normative più stringenti. Quadri come Cyber Resilience Act, DORA, NIS2 e PCI DSS 4.0 attribuiscono maggiore peso alla manutenzione del software, alla visibilità sulla catena di fornitura e alla continuità del supporto. Il software non più mantenuto diventa quindi un problema operativo e di conformità, non soltanto una voce nell’inventario delle vulnerabilità. Poiché la modernizzazione richiede spesso tempi lunghi, la transizione deve includere una strategia capace di mantenere sicuri e supportati i sistemi esistenti.
Gli investimenti effettuati negli strumenti di rilevamento consentono alle organizzazioni di sapere dove si trovano molte delle falle presenti nei propri ambienti. Resta però una seconda domanda: il software interessato è ancora supportabile? Per rispondere occorre affiancare alla gestione delle vulnerabilità una visione completa del ciclo di vita del software, distinguendo i componenti ancora mantenuti da quelli prossimi alla fine del supporto o già abbandonati dalla comunità. Servono inoltre misure che proteggano le applicazioni durante tutto il periodo necessario alla loro sostituzione.
L’AI modifica il modo in cui il software viene sviluppato, le falle vengono individuate e gli attacchi possono essere preparati, ma non trasferisce altrove la responsabilità delle imprese. La sicurezza dell’open source dipenderà sempre più dalla capacità di governare supporto, manutenzione e resilienza lungo l’intero ciclo di vita. Le organizzazioni meglio preparate non saranno necessariamente quelle che applicano ogni patch per prime, ma quelle in grado di mantenere operative e protette le applicazioni critiche mentre procedono con la modernizzazione secondo tempi sostenibili.