{"id":30610,"date":"2026-04-17T13:19:05","date_gmt":"2026-04-17T11:19:05","guid":{"rendered":"https:\/\/www.kaspersky.it\/blog\/?p=30610"},"modified":"2026-04-17T13:19:05","modified_gmt":"2026-04-17T11:19:05","slug":"open-source-vulnerabilities-in-ai-era","status":"publish","type":"post","link":"https:\/\/www.kaspersky.it\/blog\/open-source-vulnerabilities-in-ai-era\/30610\/","title":{"rendered":"Vulnerabilit\u00e0 open-source: ora un problema per ogni azienda"},"content":{"rendered":"

Un tempo erano solo software house e giganti della tecnologia specializzati quelli che perdevano il sonno a causa delle vulnerabilit\u00e0 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\u2019azienda<\/a> 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. \u00c8 ci\u00f2 che richiede l\u2019efficienza aziendale moderna. Tuttavia, il prodotto che ne deriva \u00e8 una nuova generazione di vulnerabilit\u00e0 del software, quel tipo molto pi\u00f9 complicato da correggere rispetto alla semplice installazione dell\u2019ultimo aggiornamento di Windows.<\/p>\n

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

La carenza di dati sulle vulnerabilit\u00e0 open source<\/h2>\n

Anche se l\u2019organizzazione dispone di un solido processo di gestione delle vulnerabilit\u00e0<\/a> per il software commerciale di terze parti, il codice open source richiede una revisione completa di tale processo. I database pubblici pi\u00f9 utilizzati sono spesso incompleti, imprecisi o semplicemente lenti nel ricevere gli aggiornamenti quando si tratta di open source. Questo trasforma l\u2019assegnazione delle priorit\u00e0 delle vulnerabilit\u00e0 in un gioco di indovinelli. Nessuna automazione pu\u00f2 essere di aiuto se i dati di base sono pieni di lacune.<\/p>\n

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

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

Il deficit di dati sulla vulnerabilit\u00e0 \u00e8 in aumento e il processo di segnalazione sta rallentando. Negli ultimi cinque anni il numero totale di CVE \u00e8 raddoppiato, ma il numero di CVE privi di punteggio di gravit\u00e0 \u00e8 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<\/a> dalla scoperta di una vulnerabilit\u00e0, ma per ottenere la stessa vulnerabilit\u00e0 elencata nell\u2019NVD sono stati necessari in media 15 giorni. I processi di arricchimento, come l\u2019assegnazione di un punteggio CVSS, sono ancora pi\u00f9 lenti: Sonatype nello stesso studio<\/a> stima che il tempo mediano per l\u2019assegnazione di un punteggio CVSS sia di 41 giorni, con alcuni difetti che rimangono senza punteggio per un massimo di un anno.<\/p>\n

Il problema del codice open source legacy<\/h2>\n

Librerie, applicazioni e servizi di cui non viene pi\u00f9 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<\/a>, secondo HeroDevs. Nei cinque registri del codice open source pi\u00f9 diffusi, sono presenti almeno 81.000 pacchetti che contengono vulnerabilit\u00e0 note ma appartengono a versioni obsolete e non supportate. Questi pacchetti non vedranno mai le patch ufficiali. Questo \u201cbagaglio legacy\u201d rappresenta circa il 10% dei pacchetti in Maven Central e PyPI e uno sbalorditivo 25% in npm.<\/p>\n

L\u2019utilizzo di questo tipo di codice open source interrompe il ciclo di vita standard di gestione delle patch: non \u00e8 possibile aggiornare, automaticamente o manualmente, una dipendenza che non \u00e8 pi\u00f9 supportata. Inoltre, quando le versioni EOL vengono omesse dai bollettini ufficiali sulle vulnerabilit\u00e0, i security scanner possono classificarle come \u201cnon interessate\u201d da un difetto e ignorarle.<\/p>\n

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

Ad aggravare questo problema c\u2019\u00e8 il divario di visibilit\u00e0. Molte organizzazioni non hanno gli strumenti necessari per mappare un albero delle dipendenze completo o ottenere la visibilit\u00e0 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.<\/p>\n

Malware nei registri open source<\/h2>\n

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

La motivazione alla base di questi attacchi varia notevolmente: furto di criptovaluta, raccolta delle credenziali degli sviluppatori, spionaggio industriale, accesso all\u2019infrastruttura 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<\/a> che dai criminali informatici motivati dal punto di vista finanziario<\/a>. Sempre pi\u00f9 spesso, la compromissione di un pacchetto open source \u00e8 solo il primo passaggio di una violazione aziendale in pi\u00f9 fasi.<\/p>\n

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 \u201cutile\u201d 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 \u00e8 stata l\u2019aumento degli attacchi automatizzati simili a worm. L\u2019esempio pi\u00f9 famoso \u00e8 la campagna Shai-Hulud<\/a>. 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.<\/p>\n

Sebbene questo scenario non sia tecnicamente correlato alle vulnerabilit\u00e0, gli strumenti di protezione e i criteri necessari per gestirlo sono gli stessi utilizzati per la gestione delle vulnerabilit\u00e0.<\/p>\n

In che modo gli agenti di intelligenza artificiale aumentano i rischi di utilizzo del codice open source<\/h2>\n

L\u2019integrazione affrettata e onnipresente degli agenti di IA nello sviluppo del software aumenta significativamente la velocit\u00e0 degli sviluppatori, ma amplifica anche qualsiasi errore. Senza una sorveglianza rigorosa e limiti chiaramente definiti, il codice generato dall\u2019IA \u00e8 eccezionalmente vulnerabile. La ricerca mostra che il 45% del codice generato dall\u2019IA contiene difetti inclusi nella Top 10 di OWASP<\/a>, mentre il 20% delle applicazioni basate sull\u2019IA distribuite presenta pericolosi errori di configurazione. Questo accade perch\u00e9 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 \u00e8 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<\/a>.<\/p>\n

Nel 2025 anche i principali LLM raccomandavano versioni delle dipendenze errate, semplicemente inventando una risposta, nel 27% dei casi<\/a>.<\/p>\n

L\u2019IA pu\u00f2 risolvere tutto?<\/h2>\n

\u00c8 un\u2019idea semplice e allettante: basta puntare un agente di intelligenza artificiale verso la base di codice e consentirgli di dare la caccia a ogni vulnerabilit\u00e0. Purtroppo, l\u2019IA non pu\u00f2 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\u00e0 sono mancanti o inaffidabili, invece di trovare le vulnerabilit\u00e0 note, \u00e8 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.<\/p>\n

Inoltre, se viene rilevata una vulnerabilit\u00e0 in un componente obsoleto o non supportato, un agente di intelligenza artificiale non pu\u00f2 \u201ccorreggerla automaticamente\u201d. \u00c8 ancora necessario sviluppare patch personalizzate o eseguire una migrazione complessa. Se un difetto \u00e8 sepolto in profondit\u00e0 all\u2019interno di una catena di dipendenze, \u00e8 probabile che l\u2019IA lo trascuri del tutto.<\/p>\n

Cosa fare, dunque, per proteggersi?<\/h2>\n

Per ridurre al minimo i rischi descritti sopra, sar\u00e0 necessario espandere il processo di gestione delle vulnerabilit\u00e0 per includere criteri di download dei pacchetti open source, regole operative dell\u2019assistente IA e il processo di compilazione del software. Tra cui:<\/p>\n