Vulnerabilità open-source: ora un problema per ogni azienda

Un tempo erano solo software house e giganti della tecnologia specializzati quelli che perdevano il sonno a causa delle vulnerabilità open source e degli attacchi alla supply chain. Tuttavia, i tempi sono cambiati. Oggi anche le piccole imprese gestiscono i propri centri di sviluppo, il che rende il problema rilevante per tutti. Ogni secondo i team IT interni dell’azienda sono impegnati a scrivere codice, configurare integrazioni e automatizzare i flussi di lavoro, anche se il core business non ha assolutamente nulla a che fare con il software. È ciò che richiede l’efficienza aziendale moderna. Tuttavia, il prodotto che ne deriva è una nuova generazione di vulnerabilità del software, quel tipo molto più complicato da correggere rispetto alla semplice installazione dell’ultimo aggiornamento di Windows.

Lo sviluppo del software moderno è inseparabile dai componenti open source. Tuttavia, i rischi associati sono proliferati negli ultimi anni, aumentando sia per varietà che per sofisticatezza. Stiamo assistendo a codice dannoso iniettato negli archivi famosi, dati sulle vulnerabilità frammentati e difettosi, uso sistematico di componenti obsoleti e vulnerabili e catene di dipendenze sempre più complesse.

La carenza di dati sulle vulnerabilità open source

Anche se l’organizzazione dispone di un solido processo di gestione delle vulnerabilità per il software commerciale di terze parti, il codice open source richiede una revisione completa di tale processo. I database pubblici più utilizzati sono spesso incompleti, imprecisi o semplicemente lenti nel ricevere gli aggiornamenti quando si tratta di open source. Questo trasforma l’assegnazione delle priorità delle vulnerabilità in un gioco di indovinelli. Nessuna automazione può essere di aiuto se i dati di base sono pieni di lacune.

Secondo i dati di Sonatype, circa il 65% delle vulnerabilità open-source a cui è stato assegnato un ID CVE non ha un punteggio di gravità (CVSS) nella NVD, la knowledge base sulle vulnerabilità più utilizzata. Di queste vulnerabilità senza punteggio, quasi il 46% sarebbe effettivamente classificato come Alto se analizzato correttamente.

Anche quando è disponibile un punteggio CVSS, diverse fonti concordano sulla gravità solo nel 55% circa delle volte. Un database potrebbe contrassegnare una vulnerabilità come Critica, mentre un altro database assegna un punteggio Medio. Anche i metadati più dettagliati, come le versioni dei pacchetti interessate, sono spesso pieni di errori e incoerenze. Gli scanner di vulnerabilità che confrontano le versioni del software finiscono per gridare al lupo con falsi positivi o per fornire falsamente un buono stato di salute.

Il deficit di dati sulla vulnerabilità è in aumento e il processo di segnalazione sta rallentando. Negli ultimi cinque anni il numero totale di CVE è raddoppiato, ma il numero di CVE privi di punteggio di gravità è esploso di 37 volte. Secondo Tenable, entro il 2025 il codice exploit del proof-of-concept (PoC) pubblico era in genere disponibile entro una settimana dalla scoperta di una vulnerabilità, ma per ottenere la stessa vulnerabilità elencata nell’NVD sono stati necessari in media 15 giorni. I processi di arricchimento, come l’assegnazione di un punteggio CVSS, sono ancora più lenti: Sonatype nello stesso studio stima che il tempo mediano per l’assegnazione di un punteggio CVSS sia di 41 giorni, con alcuni difetti che rimangono senza punteggio per un massimo di un anno.

Il problema del codice open source legacy

Librerie, applicazioni e servizi di cui non viene più eseguita la manutenzione, ovvero quando vengono abbandonati o hanno raggiunto da tempo il termine del ciclo di vita (EOL) ufficiale, sono presenti nel 5-15% dei progetti aziendali, secondo HeroDevs. Nei cinque registri del codice open source più diffusi, sono presenti almeno 81.000 pacchetti che contengono vulnerabilità note ma appartengono a versioni obsolete e non supportate. Questi pacchetti non vedranno mai le patch ufficiali. Questo “bagaglio legacy” rappresenta circa il 10% dei pacchetti in Maven Central e PyPI e uno sbalorditivo 25% in npm.

L’utilizzo di questo tipo di codice open source interrompe il ciclo di vita standard di gestione delle patch: non è possibile aggiornare, automaticamente o manualmente, una dipendenza che non è più supportata. Inoltre, quando le versioni EOL vengono omesse dai bollettini ufficiali sulle vulnerabilità, i security scanner possono classificarle come “non interessate” da un difetto e ignorarle.

Un ottimo esempio di ciò è Log4Shell, la vulnerabilità critica (CVSS 10) nella popolare libreria Log4j scoperta nel 2021. La versione vulnerabile ha rappresentato 40 milioni dei 300 milioni di download di Log4j nel 2025. Stiamo parlando di una delle vulnerabilità più famigerate e ampiamente segnalate della storia, una vulnerabilità che è stata attivamente sfruttata, corretta dallo sviluppatore e gestita in tutti i principali prodotti a valle. La situazione per i difetti meno pubblicizzati è significativamente peggiore.

Ad aggravare questo problema c’è il divario di visibilità. Molte organizzazioni non hanno gli strumenti necessari per mappare un albero delle dipendenze completo o ottenere la visibilità completa dei pacchetti e delle versioni specifici incorporati nello stack di software. Di conseguenza, questi componenti obsoleti spesso rimangono invisibili, senza mai entrare nella coda di correzione.

Malware nei registri open source

Gli attacchi che coinvolgono pacchetti open source infetti o intrinsecamente dannosi sono diventati una delle minacce a crescita più rapida per la catena di approvvigionamento del software. Secondo i ricercatori Kaspersky, entro la fine del 2024 erano stati individuati circa 14.000 pacchetti dannosi nei registri più diffusi, con un aumento del 48% su base annua. Sonatype ha registrato un’impennata ancora più esplosiva nel corso del 2025, rilevando oltre 450.000 pacchetti dannosi.

La motivazione alla base di questi attacchi varia notevolmente: furto di criptovaluta, raccolta delle credenziali degli sviluppatori, spionaggio industriale, accesso all’infrastruttura tramite pipeline CI/CD o compromissione di server pubblici per ospitare campagne di spam e phishing. Queste tattiche sono impiegate sia dai gruppi APT di spionaggio che dai criminali informatici motivati dal punto di vista finanziario. Sempre più spesso, la compromissione di un pacchetto open source è solo il primo passaggio di una violazione aziendale in più fasi.

Tra gli scenari di attacco comuni sono inclusi la compromissione delle credenziali di un gestore di pacchetto open source legittimo, la pubblicazione di una libreria “utile” con codice dannoso incorporato o la pubblicazione di una libreria dannosa con un nome quasi identico a uno popolare. Una tendenza particolarmente allarmante nel 2025 è stata l’aumento degli attacchi automatizzati simili a worm. L’esempio più famoso è la campagna Shai-Hulud. In questo caso, il codice dannoso ha rubato i token GitHub e npm e ha continuato a infettare i nuovi pacchetti, fino a diffondersi a oltre 700 pacchetti npm e a decine di migliaia di archivi. Durante il processo sono stati divulgati i segreti CI/CD e le chiavi di accesso al cloud.

Sebbene questo scenario non sia tecnicamente correlato alle vulnerabilità, gli strumenti di protezione e i criteri necessari per gestirlo sono gli stessi utilizzati per la gestione delle vulnerabilità.

In che modo gli agenti di intelligenza artificiale aumentano i rischi di utilizzo del codice open source

L’integrazione affrettata e onnipresente degli agenti di IA nello sviluppo del software aumenta significativamente la velocità degli sviluppatori, ma amplifica anche qualsiasi errore. Senza una sorveglianza rigorosa e limiti chiaramente definiti, il codice generato dall’IA è eccezionalmente vulnerabile. La ricerca mostra che il 45% del codice generato dall’IA contiene difetti inclusi nella Top 10 di OWASP, mentre il 20% delle applicazioni basate sull’IA distribuite presenta pericolosi errori di configurazione. Questo accade perché i modelli di IA vengono addestrati su enormi set di dati che includono grandi volumi di codice obsoleto, dimostrativo o puramente didattico. Questi problemi sistemici si ripresentano quando un modello di IA decide quali componenti open source includere in un progetto. Il modello spesso non sa quali versioni del pacchetto esistono attualmente o quali sono state contrassegnate come vulnerabili. Suggerisce invece una versione dipendente estratta dai dati di addestramento, che è quasi certamente obsoleta. In alcuni casi, i modelli tentano di chiamare versioni inesistenti o librerie completamente allucinate. Questo apre la strada ad attacchi di confusione delle dipendenze.

Nel 2025 anche i principali LLM raccomandavano versioni delle dipendenze errate, semplicemente inventando una risposta, nel 27% dei casi.

L’IA può risolvere tutto?

È un’idea semplice e allettante: basta puntare un agente di intelligenza artificiale verso la base di codice e consentirgli di dare la caccia a ogni vulnerabilità. Purtroppo, l’IA non può risolvere completamente questo problema. Gli ostacoli fondamentali di cui abbiamo discusso svantaggiano gli agenti IA tanto quanto gli sviluppatori umani. Se i dati sulle vulnerabilità sono mancanti o inaffidabili, invece di trovare le vulnerabilità note, è necessario riscoprirle da zero. Si tratta di un processo incredibilmente dispendioso in termini di risorse che richiede competenze di nicchia e che rimane fuori dalla portata della maggior parte delle aziende.

Inoltre, se viene rilevata una vulnerabilità in un componente obsoleto o non supportato, un agente di intelligenza artificiale non può “correggerla automaticamente”. È ancora necessario sviluppare patch personalizzate o eseguire una migrazione complessa. Se un difetto è sepolto in profondità all’interno di una catena di dipendenze, è probabile che l’IA lo trascuri del tutto.

Cosa fare, dunque, per proteggersi?

Per ridurre al minimo i rischi descritti sopra, sarà necessario espandere il processo di gestione delle vulnerabilità per includere criteri di download dei pacchetti open source, regole operative dell’assistente IA e il processo di compilazione del software. Tra cui:

• l’utilizzo di una soluzione completa per la protezione dei carichi di lavoro nel cloud;
• il controllo dei pacchetti open source utilizzati nel processo di sviluppo software con feed di threat intelligence per i componenti open source;
• Considerando le misure di sicurezza per proteggere il codice e gli agenti IA;
• Rimozione sistematica dei componenti open source obsoleti.

Ulteriori informazioni sulla gestione delle vulnerabilità nell’open source sono disponibili in un post dedicato del blog.