L'open source regge internet. I dati sulle vulnerabilità sono divisi tra 40 database

OSV, il database delle vulnerabilità open source gestito da Google, non conserva gli avvisi in proprio. Li aggrega. La sua pagina iniziale elenca contatori per ecosistema che sembrano un censimento di tutto ciò con cui è costruito il software moderno: npm a 228.732 avvisi, Chainguard a 1.023.658, Wolfi a 288.261, MinimOS a 144.169, GIT a 108.035, Debian a 68.356, Ubuntu a 65.370. Sono conteggi di avvisi per ecosistema, non di bug unici. Lo stesso difetto può comparire in diversi di essi.

La sovrapposizione è il punto. Il sito si descrive come "un approccio aperto, preciso e distribuito alla produzione e al consumo di informazioni sulle vulnerabilità per l'open source", costruito sullo schema OSV di OpenSSF. Lo schema esiste perché una vulnerabilità possa essere mappata "con precisione su versioni di pacchetti open source o hash di commit" invece che su nomi di prodotto vaghi. La scheda di CISA su OSV è schietta sul costo degli strumenti: "richiede un account Google Cloud Platform e Google Group".

Gli incidenti reali mostrano perché la precisione a livello di versione conta.

Log4Shell, CVE-2021-44228, ha ottenuto 10.0 su CVSS. Secondo un'analisi di Safeguard sui rischi dell'open source, è stato "sfruttato attivamente da gruppi ransomware e attori sponsorizzati da Stati per più di un anno dopo che esisteva una patch". La backdoor di XZ Utils, CVE-2024-3094, è stata anch'essa valutata 10.0. È stata trovata per caso il 29 marzo 2024, dopo che un contributore con il nome "Jia Tan" aveva passato più di due anni a costruirsi cronologia di commit e fiducia. La backdoor era già arrivata in Debian testing e nelle pre-release di Fedora 40/41. Heartbleed, CVE-2014-0160, ha esposto chiavi private su circa 500.000 server nell'aprile 2014. La violazione di Equifax del 2017 risale a un difetto di Apache Struts non corretto, CVE-2017-5638, ed è costata 1,4 miliardi di dollari tra risarcimenti e bonifiche.

Applicare le patch non è il collo di bottiglia

Il testo di Safeguard fa una distinzione che si perde nelle dashboard di severità: il problema raramente è che non esista una patch. È che le organizzazioni non sanno quali servizi in esecuzione chiamino davvero la funzione vulnerabile. Così l'applicazione delle patch finisce in fondo a una lista in cui tutto sembra ugualmente urgente. Il catalogo delle vulnerabilità note sfruttate di CISA, limitato ai CVE con sfruttamento attivo confermato, ha superato 1.300 voci nel 2025. Una gran parte riguarda componenti open source largamente incorporati come Apache, OpenSSL e Spring.

La profondità delle dipendenze peggiora le cose. Il rapporto State of Open Source Security del 2020 di Synk, citato da Safeguard, ha rilevato che il progetto JavaScript medio tira dentro 683 dipendenze, il 79% delle quali transitive. Il rapporto Open Source Security and Risk Analysis del 2024 di Synopsys ha stimato l'open source al 70%-90% del codice nelle applicazioni moderne. La guida di SentinelOne inquadra lo stesso problema come una questione di governance: i programmi efficaci hanno bisogno di mappatura delle dipendenze, applicazione automatizzata delle policy che segnali o blocchi le build, e punteggi di rischio per decidere cosa correggere per primo quando personale e tempo scarseggiano.

Poi c'è il livello umano. Nel marzo 2016 lo sviluppatore Azer Koçulu ha ritirato left-pad, un pacchetto npm di 11 righe, durante una disputa sul nome. Le build si sono rotte in tutto l'ecosistema JavaScript nel giro di ore, finché npm non l'ha ripristinato. Log4j, pur trovandosi dentro centinaia di migliaia di applicazioni stimate, era mantenuto in gran parte da un piccolo team di volontari. Il manutentore principale Volkan Yazıcı ha dichiarato pubblicamente che il team ha gestito la risposta a Log4Shell senza essere pagato. Non esiste un SLA sul lavoro volontario.

Anche le licenze portano con sé un'esposizione. La Software Freedom Conservancy ha citato in giudizio Vizio nel 2021 per il codice sorgente GPL nei suoi smart TV. Nel febbraio 2024 una corte d'appello della California ha stabilito che i termini della GPL sono applicabili come diritti contrattuali di terzi beneficiari.

Correggere il codice è un lavoro. Trovarlo è un altro

Gli strumenti attorno al livello dei database si stanno consolidando. OSV-Scanner, installato tramite Go, analizza SBOM, lockfile, directory di progetto e immagini container. Distribuisce anche workflow GitHub riutilizzabili, così che le pipeline CI/CD possano controllare le dipendenze appena aggiunte nelle pull request ed eseguire scansioni regolari su un progetto. L'API risponde a query per hash di commit o per versione di pacchetto, con chiamate di esempio per uno SHA di commit o per jinja2 2.4.1 su PyPI. OSV-Scanner offre anche una modalità di correzione con strategie in-place e relock per package-lock.json.

Non ogni progetto insegue la stessa metrica. typed-lm, un progetto Rust pubblicato su GitHub, prende una strada diversa: trasforma modelli decoder densi tra cui Llama, Qwen2, Qwen3, Mistral, Gemma, Gemma2 e Gemma3 in un'API di routing semantico tipizzato, che restituisce booleani, scelte e punteggi invece di testo generato. Il suo README sostiene che un singolo forward pass significa millisecondi invece di secondi, e pubblica tabelle di latenza per una singola RTX 3070 con pesi F16. Su CPU riporta un prefill da 1024 token che scende da 28,23 secondi a 13,13 secondi con CPU flash e MKL abilitati, e consiglia un checkpoint GGUF Q4_K_M con la feature mkl. Sono cifre pubblicate dal progetto, non verificate in modo indipendente.

L'economia che sta sotto a tutto questo è instabile. Scrivendo nell'agosto 2026, lo sviluppatore Debamitro ha raccontato di aver intervistato Christian Hammond, fondatore e CEO di ReviewBoard, e ne ha tratto una conclusione controintuitiva: le aziende pagano per ReviewBoard "non perché è open source, ma nonostante sia open source". I clienti pagano per il supporto, e alcuni pagano per la versione ospitata. Hammond gli ha anche detto che l'uso di ReviewBoard è in calo in alcune aziende che stanno eliminando le revisioni del codice, e ha sostenuto che i linguaggi di programmazione, e in generale il software fondamentale, dovrebbero essere open source.

Il problema delle vulnerabilità resta così dov'era all'inizio: sparso tra più di quaranta database di ecosistemi, la maggior parte dei quali mantenuti dalle stesse persone non pagate o finanziate con pochi mezzi che pubblicano il codice. L'aggregazione aiuta. Non colma il divario tra un avviso pubblicato e un'organizzazione che sa se la funzione interessata è in esecuzione in produzione.