La stessa vulnerabilità, migliaia di aziende impegnate a risolverla ciascuna per proprio conto. È una duplicazione che può costare centinaia di milioni di dollari: Red Hat, nel primo rapporto trimestrale “Open Source Security Signals”, stima in 712,5 milioni la spesa per correggere separatamente un ipotetico problema di sicurezza in un componente Java utilizzato su larga scala. Condividere una patch validata e riutilizzabile può evitare di ripetere lo stesso lavoro e accelerare la messa in sicurezza delle applicazioni.
Il rapporto, relativo al terzo trimestre del 2026, esamina costi e tempi della sicurezza open source, mentre l’intelligenza artificiale accelera l’individuazione delle vulnerabilità. Per i team aziendali diventa essenziale stabilire quali problemi affrontare prima e far arrivare le correzioni ai sistemi interessati, comprese le versioni meno recenti ancora in produzione.
Indice degli argomenti
Il modello Java: 5,7 milioni di ore per intervenire sulle applicazioni
Per stimare il lavoro necessario a risolvere un problema comune a molte organizzazioni, Red Hat ha modellato l’impatto di una vulnerabilità ipotetica in JAXB, Jakarta XML Binding, utilizzato per collegare dati XML e oggetti Java. Il componente è impiegato da 1,14 milioni di applicazioni a livello globale.
Applicando tassi di persistenza delle versioni vulnerabili, il modello stima che 285.000 applicazioni potrebbero utilizzare una versione interessata dalla falla. Per ciascuna, la risoluzione autonoma richiederebbe circa 20 ore di ingegneria, distribuite tra valutazione, correzione, test e rilascio.
Il calcolo assume un costo di 125 dollari l’ora per sviluppatore, sulla base dei dati del Bureau of Labor Statistics statunitense citati da Red Hat. La spesa raggiungerebbe così 2.500 dollari per applicazione e 712,5 milioni nell’intero scenario considerato. Una patch condivisa, validata, compatibile con le versioni precedenti e pronta per la distribuzione può ridurre la duplicazione di queste attività.
Ridurre il tempo in cui i sistemi restano esposti
Al lavoro dei team si aggiunge il periodo durante il quale le applicazioni rimangono vulnerabili. Secondo il Vulnerability Statistics Report 2026 di Edgescan, richiamato nel rapporto, il tempo medio del settore per risolvere problemi con impatto critico o alto è di 54,81 giorni.
Per le dipendenze di terze parti, Red Hat cita lo State of Software Security 2026 di Veracode: le vulnerabilità individuate attraverso la Software Composition Analysis, l’analisi dei componenti software, hanno un’emivita di risoluzione di 358 giorni, ossia il tempo necessario a risolverne la metà.
Nello scenario JAXB, portare la risoluzione da 54,81 a 10 giorni consentirebbe una riduzione dell’81,8% del tempo di esposizione. Il modello traduce questo risultato in 12,8 milioni di giorni di vulnerabilità evitati, sommando il beneficio sulle applicazioni considerate nell’ecosistema enterprise Java.
Le vulnerabilità individuate dall’AI e la valutazione delle priorità
La rapidità di intervento assume un peso crescente con l’impiego dell’intelligenza artificiale nella ricerca delle falle. Un’analisi di IBM X-Force su 223 vulnerabilità identificate con modelli AI, citata da Red Hat, ha rilevato che il 55,2% presentava una gravità alta o critica. Il 91% era accessibile da remoto e il 25,6% permetteva l’esecuzione di codice.
Per assegnare le priorità, il rapporto richiama la necessità di valutare le condizioni concrete di sfruttamento: la raggiungibilità del componente, la sua posizione nella rete delle dipendenze, la configurazione, i privilegi disponibili e i controlli presenti. Una debolezza può combinarsi con altre lungo un percorso che conduce fino alle risorse sensibili.
Il rischio dipende quindi anche da ciò che un attaccante può raggiungere dopo aver sfruttato la prima vulnerabilità. Configurazioni permissive e credenziali compromesse possono contribuire a trasformare debolezze singolarmente modeste in una sequenza di attacco con conseguenze significative.
Il caso Ultralytics e i controlli sulla filiera software
La compromissione del progetto Python Ultralytics, avvenuta nel dicembre 2024, mostra l’importanza dei controlli nelle diverse fasi della produzione e distribuzione del software. Gli attaccanti hanno compromesso l’ambiente di build GitHub Actions e inserito codice malevolo nei pacchetti pubblicati su PyPI.
Il codice dannoso era assente dal sorgente pubblico del progetto su GitHub, mentre i primi pacchetti compromessi erano stati pubblicati attraverso i workflow legittimi di GitHub Actions. Per ricostruire l’origine dell’attacco sono state utili le attestazioni di provenienza e i registri di trasparenza, insieme alle funzionalità Trusted Publishing di PyPI.
L’episodio evidenzia il ruolo delle verifiche sulla catena di fornitura: il codice sorgente, l’ambiente di build e la distribuzione dei pacchetti partecipano tutti alla sicurezza del software utilizzato dalle aziende.
Le patch devono raggiungere anche le versioni precedenti
La distribuzione delle correzioni deve seguire la struttura delle applicazioni. Framework e servizi aziendali utilizzano componenti per autenticazione, crittografia, networking, osservabilità, cloud e intelligenza artificiale, ciascuno con ulteriori dipendenze. Una vulnerabilità può richiedere verifiche su più componenti collegati.
Le patch devono inoltre raggiungere le versioni più vecchie ancora utilizzate in produzione. Il rapporto ricostruisce il caso di Spring Framework 5.3.18, rilasciato nel marzo 2022 per risolvere la vulnerabilità critica Spring4Shell. Meno di due settimane dopo, il team Spring ha divulgato un’altra vulnerabilità, individuata durante l’indagine sulla precedente, che interessava anche la versione 5.3.18. La correzione è arrivata con la 5.3.19.
Per i sistemi rimasti sulle release precedenti, la disponibilità della patch dipende anche dal backporting, cioè dall’adattamento della correzione alle versioni meno recenti. L’aggiornamento a una nuova build può presentare difficoltà operative e rischi, soprattutto negli ambienti di produzione critici.
I tre aspetti che Red Hat seguirà nei prossimi rapporti
Il primo ambito individuato da Red Hat è la rilevanza del rischio: comprendere quali vulnerabilità possano essere sfruttate e quali risorse risultino raggiungibili aiuta i team a decidere dove intervenire prima.
Il secondo riguarda lo stato della risoluzione dei problemi lungo alberi di dipendenze profondi e attraverso diverse generazioni di software. La disponibilità di una patch deve tradursi nella sua effettiva distribuzione ai sistemi interessati, comprese le versioni meno recenti.
Il terzo è il valore delle correzioni riutilizzabili. Ricerca e patch condivise possono evitare agli utilizzatori di una stessa dipendenza di ripetere il lavoro. Le prossime edizioni del rapporto seguiranno l’evoluzione delle vulnerabilità, i tempi di valutazione e risoluzione dei problemi significativi, la resilienza delle dipendenze importanti e la riduzione del lavoro duplicato.
Partecipa alla community