Gli avvisi di vulnerabilità open source sono triplicati in un anno, e uno su dieci non ha alcun CVE

Axis Intelligence Research ha pubblicato i dati il 4 settembre, partendo da un clone locale completo del GitHub Advisory Database. Il conteggio include ogni avviso non ritirato e revisionato manualmente, pubblicato tra il 1° settembre 2025 e il 31 agosto 2026. Nella stessa finestra temporale, un anno prima, erano 3.191. Il volume è quindi 3,36 volte superiore, con una crescita del 236,4%.

La svolta avviene a marzo 2026. Il volume mensile è raddoppiato rispetto a febbraio e non è più tornato alla vecchia base.

La spiegazione ovvia, che i ricercatori stiano recuperando bug vecchi, non regge. Dei 9.393 avvisi pubblicati da gennaio ad agosto 2026, 8.005 riportano un identificativo CVE del 2026 e 1.150 non hanno alcun CVE. Meno del 4% risale a un identificativo precedente al 2026. L'impennata non è nemmeno opera di un solo progetto. Il pacchetto npm openclaw da solo vale 590 avvisi, ma togliendolo restano 10.144 per l'anno, comunque 3,18 volte il totale precedente.

Marcus Chen, nello stesso report di Axis, sostiene che il motore sia la capacità di scoperta, non l'attività degli attaccanti. L'analisi automatizzata ha raggiunto la coda lunga di pacchetti che nessun ricercatore umano avrebbe mai controllato. I bug erano già negli alberi delle dipendenze; quello che è cambiato è che qualcuno finalmente ha guardato. La conseguenza operativa, scrive, è che una coda di triage dimensionata per i 369 avvisi di dicembre 2025 si è trovata davanti 1.661 avvisi a maggio 2026, senza un aumento corrispondente di organico nel frattempo.

Dove sono i punti ciechi

Il divario CVE è la parte che colpisce gli strumenti basati su chiavi CVE. Axis lo quantifica in 1.273 avvisi su 10.734, l'11,9%: uno scanner che ingerisce solo i feed CVE perde circa un avviso su otto. I feed nativi dei singoli ecosistemi coprono la differenza. crates.io segna 46,9 sull'indice di pressione di Axis nonostante un volume modesto, perché il 39,8% dei suoi avvisi non ottiene mai un CVE.

Axis ha anche costruito un Open Source Ecosystem Pressure Index, che pesa il volume degli avvisi al 35%, il carico di severità al 25%, il divario di copertura al 20% e la densità di sfruttamento al 20%, con ogni componente riscalato al massimo su otto ecosistemi. Al 4 settembre le letture erano npm 70,0, PyPI 59,2, Go 55,8, NuGet 51,1, Maven 48,3, Packagist 47,2, crates.io 46,9 e RubyGems 33,8.

Lo sfruttamento resta raro rispetto al volume. Delle 1.694 voci nel catalogo Known Exploited Vulnerabilities di CISA, 131 (7,7%) corrispondono a un avviso su un pacchetto open source. Tra le aggiunte del 2026 la quota sale all'11,9%, 25 su 210. E 10 di quelle 25, il 40,0%, riguardano pacchetti di AI o ML: Langflow, LiteLLM, MLflow, Ray e Marimo. Sommando tutti gli anni precedenti la cifra era 3 su 106, cioè il 2,8%.

Le scansioni di codebase commerciali indicano la stessa direzione. Il report Open Source Security and Risk Analysis 2026 di Black Duck, pubblicato il 25 febbraio e basato su 947 codebase commerciali in 17 settori, ha rilevato che il numero medio di vulnerabilità open source per codebase è più che raddoppiato, con un aumento del 107% fino a 581. L'87% delle codebase esaminate conteneva almeno una vulnerabilità e il 78% presentava problemi ad alto rischio, con il 44% che riportava riscontri di rischio critico.

Lo stesso report collega l'aumento allo sviluppo assistito dall'AI. Il numero medio di file per codebase è cresciuto del 74% su base annua e i componenti open source per codebase sono saliti del 30%. Circa l'85% delle organizzazioni usa assistenti di programmazione basati sull'AI, e il 76% delle aziende che vietano esplicitamente questi strumenti dichiara che gli sviluppatori li usano comunque. Black Duck segnala anche il debito di manutenzione: il 93% delle codebase contiene componenti senza attività di sviluppo negli ultimi due anni, e il 92% contiene componenti vecchi di quattro anni o più.

Correggere, non solo trovare

CISA elenca OSV, il database di vulnerabilità di Google con l'infrastruttura di triage per l'open source, tra i suoi strumenti di cybersicurezza gratuiti, osservando che richiede un account Google Cloud Platform e un account Google Group. OSV aggrega database che hanno adottato lo schema OSV, tra cui GitHub Security Advisories, PyPA, RustSec e il Global Security Database, ed espone un'API per interrogare per hash di commit o versione del pacchetto.

OWASP sta provando ad attaccare il lato della remediation. Ha annunciato la Open Automated Security Initiative for Software, OASIS, il 26 agosto 2026 a San Francisco, secondo Cyber Security News. L'iniziativa affianca candidati di correzione generati dall'AI a una validazione umana da parte di professionisti AppSec, poi invia le patch verificate upstream. Gli sponsor fondatori sono AppSecAI, Intigriti e DryRun Security. Il report cita il dato OSSRA 2026 di Black Duck secondo cui l'open source è alla base di circa il 98% delle codebase commerciali.

L'iniziativa è presentata come complementare agli sforzi guidati dalle aziende, tra cui Patch the Planet di OpenAI, Akrites della Linux Foundation e Project Glasswing di Anthropic, che concentrano team di ricerca d'élite su sistemi operativi e browser. OASIS punta invece su revisori volontari per coprire la coda lunga delle librerie. David Kosorok, director of product security di ACV Auctions, viene citato mentre definisce questo il lavoro a più alto leverage nella sicurezza applicativa, con l'argomento che una sola correzione validata upstream può mettere in sicurezza migliaia di applicazioni a valle.

Quello che nulla di tutto questo cambia è l'aritmetica davanti a un team di sicurezza. Il volume degli avvisi è cresciuto di 3,36 volte in un anno. L'organico no.