L’open source è diventato la base del software moderno perché si tratta di un modello che funziona. Innovazione condivisa, sviluppo trasparente, comunità globali e riutilizzo su larga scala permettono al software di progredire a una velocità che nessuna singola organizzazione potrebbe raggiungere da sola.
La sicurezza fa parte di questo modello. La modalità di sviluppo open source rende il codice ispezionabile. I ricercatori possono testarlo, le community migliorarlo e le correzioni vanno a vantaggio di tutti coloro che da quel software dipendono. Ma la stessa scala che rende l’open source così potente ne complica la sicurezza. Le applicazioni moderne possono basarsi su centinaia o migliaia di componenti collegati da dipendenze estremamente interconnesse e ramificate. Per comprenderne appieno la sicurezza, quindi, non è sufficiente contare le vulnerabilità.
L’AI scopre vulnerabilità più pericolose Un’analisi di IBM X-Force su 223 vulnerabilità identificate usando modelli di intelligenza artificiale ha rilevato che il 55,2% erano di severità Alta o Critica, il 91% erano accessibili da remoto, e il 25,6% permettevano l’esecuzione di codice. Con il crescente utilizzo dell’AI per identificare vulnerabilità, la semplice individuazione e valutazione non sarà più sufficiente. I difensori hanno bisogno di contesto per determinare quali scoperte danno luogo a un’esposizione reale e quali percorsi d’attacco possono abilitare. La compromissione del popolare progetto Python Ultralytics nel dicembre 2024 ha mostrato come a contare davvero sia l’intero percorso d’attacco, non solo la gravità della singola vulnerabilità. Gli attaccanti compromisero l’ambiente di build GitHub Actions del progetto e iniettarono codice malevolo nei pacchetti pubblicati su PyPI. Il codice iniettato non era presente nel codice sorgente pubblico del progetto su GitHub, ma i primi pacchetti dannosi erano stati pubblicati attraverso i workflow legittimi di GitHub Actions del progetto. Ciò che ha consentito di risalire all’origine dell’attacco è stata la presenza delle funzionalità “Trusted Publishing” di PyPI, di attestazioni di provenienza e di registri di trasparenza. Un esempio chiaro dell’importanza dei controlli in altre fasi della catena di fornitura del software.
Gli attaccanti sfruttano percorsi, non punteggi
Il caso Ultralytics dimostra come anche vulnerabilità individuali modeste possano combinarsi per creare rischi significativi lungo tutta la supply chain del software. Il percorso parte da una vulnerabilità, passa attraverso una configurazione permissiva, sfrutta credenziali compromesse, e arriva a risorse sensibili. Capire la gravità di una vulnerabilità significa anche comprendere cosa un attaccante può raggiungere da quel punto e come fermarlo. E per farlo serve il contesto: sfruttabilità, raggiungibilità, posizione nella rete di dipendenze, configurazione, privilegi, controlli circostanti, altre debolezze nel percorso.
712 milioni di dollari: il costo della lentezza
Per illustrare il valore economico della velocità di remediation, Red Hat ha modellato l’impatto di una vulnerabilità ipotetica in JAXB (Jakarta XML Binding), un’implementazione fondamentale di XML binding nell’ecosistema Java utilizzata da 1,14 milioni di applicazioni globali.
Applicando tassi di persistenza delle versioni vulnerabili, il modello stima che 285.000 applicazioni potrebbero usare una versione vulnerabile di JAXB. Rimediare autonomamente a ciascuna di queste applicazioni richiederebbe circa 20 ore di ingegneria per assessment, fix, test e deployment. A un costo di 125 dollari l’ora per sviluppatore software, come stimano i dati del Bureau of Labor Statistics statunitense. Ciò vuol dire che la sistemazione di ogni applicazione costerebbe 2.500 dollari.
Moltiplicato per 285.000 applicazioni, il costo totale modellato raggiunge i 712,5 milioni di dollari, sono 5,7 milioni di ore di ingegneria spese a ripetere lo stesso lavoro. Ma il tempo conta almeno quanto i costi. Secondo il Vulnerability Statistics Report 2026 di Edgescan, il tempo medio del settore per rimediare a vulnerabilità con impatto Critico o Alto è di 54,81 giorni. Per dipendenze di terze parti come JAXB, la situazione peggiora: lo State of Software Security 2026 di Veracode ha rilevato che le vulnerabilità identificate attraverso Software Composition Analysis hanno un’emivita di risoluzione di 358 giorni.
Una correzione riutilizzabile – validata, retro-compatible, distribuibile – può ridurre drasticamente sia il lavoro duplicato che il tempo di esposizione. Nel modello JAXB, accelerare la remediation da 54,81 a 10 giorni significherebbe una riduzione dell’81,8% del tempo di esposizione, equivalente a 12,8 milioni di giorni di vulnerabilità evitati nell’ecosistema enterprise Java.
Le correzioni devono viaggiare
Uno dei punti di forza dell’open source è la componibilità. Gli sviluppatori possono basarsi sulla passata esperienza di migliaia di progetti invece di dover ricreare le stesse funzionalità da zero. Questa interconnessione è visibile nelle applicazioni enterprise moderne: framework applicativi si appoggiano a networking, serializzazione, autenticazione, crittografia, osservabilità, servizi cloud, package management, build tooling, AI e sviluppo di agenti. Molte di queste capacità portano con sé intere famiglie di dipendenze a supporto. È quello che stiamo vedendo con il nostro lavoro in Lightwell nei pacchetti open source usati nelle applicazioni aziendali.
Quando i ricercatori scoprono una vulnerabilità, i team potrebbero dover valutare diversi componenti correlati. Il problema può anche raggiungere software che si trova più in basso nell’albero delle dipendenze. La release di sicurezza Netty 4.1.133 di maggio 2024 ne è un esempio: ha risolto 12 CVE distribuiti in diverse parti del progetto, incluse funzionalità HTTP, HTTP/2, HTTP/3, MQTT, DNS, Redis, proxy e compressione.
Produrre una correzione è solo parte del lavoro perché quest’ultima deve anche raggiungere il software che ne ha bisogno. E deve viaggiare non solo in avanti verso le versioni più recenti, ma anche all’indietro verso software più vecchio ancora in uso. Spring Framework 5.3.18, rilasciato nel marzo 2022 per risolvere la vulnerabilità Critical Spring4Shell, fornisce un esempio istruttivo. Meno di due settimane dopo, il team Spring ha divulgato un’altra vulnerabilità che colpiva versioni fino alla 5.3.18. Il team ha rilasciato la 5.3.19 con la correzione. I ricercatori Spring avevano trovato il secondo problema mentre investigavano quello precedente.
Questa sequenza mostra la sicurezza open source in azione: l’investigazione ha portato a nuova conoscenza, il team ha divulgato ciò che ha trovato, da qui è seguita un’altra correzione. Ma in un caso come questo, cosa succede ai sistemi che eseguono ancora le versioni precedenti colpite? Il backporting delle patch a versioni più vecchie non è scontato. L’upgrade a una build più recente e corretta non è sempre fattibile dal punto di vista del rischio o operativo, specialmente per ambienti di produzione critici.
Tre segnali da monitorare
Il primo report trimestrale “Open Source Security Signals” di Red Hat identifica tre aree critiche per valutare la salute della sicurezza open source.
La prima è la rilevanza del rischio. La severity è importante, ma il rischio pratico dipende da sfruttabilità, raggiungibilità, posizione nell’albero delle dipendenze, configurazione, privilegi, controlli circostanti e altre debolezze nel percorso d’attacco. Comprendere dove un attaccante può dirigersi in seguito aiuta i team a decidere come prioritizzare le proprie azioni.
La seconda è lo stato della remediation. L’open source moderno abbraccia alberi di dipendenze profondi e diverse generazioni di software. La sicurezza efficace richiede che le correzioni raggiungano il software che ne ha bisogno, incluse versioni più vecchie ancora in uso nei sistemi di produzione.
La terza è il valore di una remediation riutilizzabile. La ricerca può essere condivisa, le correzioni riutilizzate, e una soluzione sviluppata per una dipendenza comune può evitare agli utenti a valle di ripetere lo stesso lavoro. Questo è uno dei punti di forza della sicurezza open source: il lavoro fatto una volta può creare valore ben oltre il progetto in cui il problema è apparso per primo.
La domanda
La domanda non è più “quante vulnerabilità abbiamo trovato?” ma “quanto velocemente possiamo identificare, dare priorità e risolvere i rischi open source che contano davvero?”. In un mondo in cui l’AI può scoprire e potenzialmente concatenare vulnerabilità più velocemente di quanto i team possano rimediare, la velocità di risposta diventa il vero differenziatore.
