Nel 2025 sono stati pubblicati oltre 48.000 Common Vulnerabilities and Exposures, noti CVE, ma solo 58 di questi hanno rappresentato una minaccia reale, effettivamente sfruttabile per le catene di approvvigionamento enterprise, secondo un nuovo rapporto della società di intelligence cybersicurezza Black Kite.
Questa scoperta pone le organizzazioni di fronte a una realtà che richiede un cambio di approccio radicale. Secondo Black Kite, la sfida non si limita più al numero di exploit, ma ai rischi legati ad esse.
Il documento pubblicato svela come il volume delle vulnerabilità sta crescendo rapidamente, spinto dall’adozione accelerata dell’Intelligenza Artificiale. Questa nuova tecnologia viene utilizzata sia per produrre malware che per scoprire nuove falle nei software.
Allo stesso tempo, i cybercriminali stanno sfruttando le vulnerabilità più velocemente che mai, con una media di sfruttamento che avviene sette giorni prima della divulgazione pubblica. Con queste premesse e con il progredire delle tecnologie AI, i malintenzionati non sembrano avere il proposito di rallentare il ritmo.
Il rapporto consiglia di applicare patch con tempestività, ma la rapidità d’azione da sola non basta: a volte, i danni maggiori, non sono causati dai famigerati CVE.
EPSS e OSINT: i parametri più importanti per valutare le vulnerabilità
In questo contesto così difficile, la chiave per alzare il livello di sicurezza risiede nei team di cybersecurity.
Secondo Ferhat Dikbiyik, Chief research and intelligence officer di Black Kite, fermarsi ai freddi numeri relativi alla diffusione dei CVE e CVSS (Common Vulnerability Scoring System) è un errore.
Quel rapporto di 58 su 48.000 dimostra che i team devono filtrare il rumore di fondo, analizzando il livello di “sfruttabilità” nel mondo reale. In tal senso, i professionisti possono affidarsi come le previsioni EPSS (Exploit Prediction Scoring System) dinamiche o la “discoverability” OSINT (Open‑Source Intelligence). In poche parole, se un exploit non è facile da sfruttare e/o difficile da individuare, questa dovrebbe avere priorità minore rispetto ad altre falle più accessibili.
Tim Mackey, responsabile della software supply chain risk strategy presso Black Duck Software, ha affermato che affrontare l’inondazione di CVE richiede un’attenta gestione delle priorità.
Il primo passo, secondo l’esperto, è determinare se la libreria o il software colpiti dal CVE in questione sono effettivamente utilizzati nei prodotti o nell’ambiente IT gestito dall’organizzazione. Il passo successivo è determinare quali CVE hanno un vettore noto. Quelli che ne hanno uno, sono da considerarsi come prioritari.
Dal canto suo Derek Fisher, executive director di product security presso JPMorgan Chase & Co., ha dichiarato che le scoperte di Black Kite confermano ciò che la maggior parte dei team di sicurezza aveva già compreso da anni. Esiste un rumore di fondo nella gestione delle falle che gioca in favore dei cybercriminali.
In questo senso, il Known Exploited Vulnerability Catalog della CISA, noto come KEV, potrebbe essere un buon punto di partenza, secondo Roger Grimes, CISO advisor presso KnowBe4.
Tuttavia, Brian English, product security lead presso SAS, ha obiettato che per le organizzazioni che gestiscono grandi ambienti enterprise, è spesso più efficiente agire in modo preventivo e aggressivo, senza soffermarsi troppo su aspetti pur importanti come sfruttabilità e discoverability.
Dalla prospettiva della product security, è spesso più sicuro e responsabile affrontare le vulnerabilità note piuttosto che impegnarsi in quelle che non rappresentano un rischio pratico, ha affermato English.
CVE e Intelligenza Artificiale
Il rapporto Black Kite ha anche notato come l’Intelligenza Artificiale sta ampliando il divario tra organizzazioni che possono permettersi le sue capacità avanzate di sicurezza e quelle che non possono. Mentre i gap di risorse sono sempre esistiti, oggi l’AI rende la divisione ancora più evidente e più concentrata, ha dichiarato Dikbiyik.
Anthropic Claude Mythos, ad esempio, offre l’opportunità di ridurre il tempo di rilevamento delle vulnerabilità in media da 197 giorni a soli 14 giorni ma, almeno al momento, questo strumento è riservato a pochi eletti.
Non solo: gli attaccanti, compresi come alcuni obiettivi siano ora protetti in modo più solido, si stanno concentrando su chi è già in una posizione di svantaggio. Dikbiyik ha sottolineato che l’82% delle corrispondenze azienda-CVE coinvolge exploit provenienti da fuori i top 20 produttori di software a livello mondiale. Per i team di sicurezza software questo significa che non è possibile assicurare un chiaro perimetro semplicemente monitorando una manciata di grandi provider tecnologici.
Il già citato Derek Fisher ha dichiarato che i team di sicurezza software sono consapevoli da anni che le vulnerabilità di sicurezza open-source sono un grosso problema e hanno ampiamente distribuito strumenti come SCA (Software Composition Analysis) che possono individuarle.
Tuttavia, questi team non hanno bisogno di più modi per trovare falle nelle dipendenze. La priorità è l’adozione di tecniche pratiche per identificare vulnerabilità che hanno impatto attraverso metriche di exploitability come CISA KEV, EPSS o OSINT.
Dikbiyik ha illustrato la corsa contro il tempo che affrontano i difensori della supply chain security: il tempo mediano dall’accesso iniziale di un attaccante alla consegna a un cybercriminale secondario, come un gruppo ransomware, è crollato da oltre 8 ore nel 2022 a sorprendenti 22 secondi di oggi.
Combinando questi dati con la finestra di exploitation di sette giorni, lo scenario è chiaro: una volta che un fornitore in una supply chain è compromesso, l’escalation è quasi istantanea, ha dichiarato Dikbiyik. Tutto questo sta accadendo mentre la prossima generazione di AI come il già citato Claude Mythos è pronta a portare il rumore CVE a livelli estremi.
Il problema della sicurezza basata solo sui CVE non è che applicare le patch alle vulnerabilità note sia sbagliato, tutt’altro. Ma Brian English ha ragione: per le grandi aziende una remediation di massa può essere più praticabile rispetto all’analisi dettagliata caso per caso.
Tuttavia, questo approccio resta carente. L’incompletezza diventa più costosa perché gli attaccanti stanno sempre più aggirando il processo tradizionale di divulgazione delle falle. Gli attacchi alla supply chain sono l’esempio più chiaro di questo divario.
Il caso Red Hat
Il primo giugno, i ricercatori di ReversingLabs hanno rivelato che un attaccante ha pubblicato versioni maligne di 31 pacchetti sotto lo scope npm @redhat-cloud-services in un’operazione automatizzata durata 72 secondi.
Il payload veniva eseguito non appena uno sviluppatore lanciava npm install. Non è stato assegnato alcun CVE, non è stato pubblicato alcun punteggio CVSS e non è stata generata una previsione EPSS. La minaccia era già attiva e raccoglieva credenziali negli ambienti di build prima che i vulnerability scanner potessero rilevarla.
Questo tipo di attacco non è gestibile dai tradizionali framework che amministrano la priorità delle vulnerabilità: quei sistemi si basano su difetti divulgati, non su malware inserito direttamente nel codice. Gli attacchi a SolarWinds, 3CX e XZ Utils hanno seguito lo stesso schema: la compromissione non è passata attraverso un exploit noto, ma attraverso l’introduzione diretta di codice malevolo nel software.
I team di sicurezza hanno bisogno di uno strumento che catturi ciò che i classici scanner di vulnerabilità non individuano, che si tratti di malware inserito nei pacchetti software prima della pubblicazione, modifiche non autorizzate dopo la compilazione, credenziali esposte nei file eseguibili e codice dannoso introdotto attraverso librerie open-source compromesse.
L’analisi dei file binari affronta il problema alla radice: invece di confrontare il software con un elenco di difetti già noti, esamina il prodotto finale cercando segnali concreti di attività malevola.
