Il volume dei CVE aumenta del 49%, la validazione delle vulnerabilità diventa prioritaria

Un diluvio di nuovi identificatori di vulnerabilità sta costringendo i team di sicurezza a mettere la validazione delle vulnerabilità al centro delle loro decisioni su cosa correggere per primo. Nella prima metà del 2026 sono state pubblicate 35.853 CVE, circa il 49% in più rispetto all'anno precedente, secondo un articolo di sicurezza contribuito da Picus Security pubblicato su The Hacker News. Nello stesso periodo, solo 495 di queste CVE sono state catalogate come sfruttate in natura, e 116 erano già sotto attacco il giorno in cui sono apparsi i loro identificatori pubblici. Le cifre, presentate dalla ricercatrice di Picus Security Sila Ozeren Hacioglu, descrivono un divario crescente tra la velocità e la scala della scoperta di vulnerabilità e l'insieme molto più ristretto di falle che gli attaccanti effettivamente usano. I dati sulla divulgazione di Anthropic sottolineano il problema della scala: i suoi modelli di intelligenza artificiale (IA) di classe Mythos hanno fatto emergere 26.153 candidate vulnerabilità nel software open source, mentre solo 421 di queste candidate hanno ricevuto patch upstream.

Il Common Vulnerability Scoring System, o CVSS, assegna a ciascuna CVE una baseline di gravità, ma non può dire a un'organizzazione cosa significhi la falla nel proprio ambiente. La stessa CVE può apparire su centinaia di asset, ma il suo impatto è raramente uguale perché alcune istanze sono irraggiungibili, alcune si trovano dietro controlli che interrompono le tecniche di cui un attaccante avrebbe bisogno, e altre risiedono su sistemi critici per il business dove un'intrusione sarebbe grave. Ecco perché i difensori hanno bisogno di prove dai propri sistemi per determinare tre cose: se l'esposizione è effettivamente sfruttabile, quali asset colpisce e se quegli asset sono raggiungibili e importanti per il business. Un punteggio CVSS Alto o Critico di per sé non è un ordine di emergenza. Trattare ogni valutazione di questo tipo come urgente non è solo impossibile quando arrivano migliaia di CVE ogni anno; è anche il modello sbagliato per la prioritizzazione.

Il penetration testing automatizzato, comunemente chiamato pentesting automatizzato, fornisce alcune delle prove più solide disponibili perché può eseguire exploit reali, dimostrare che un'esposizione è sfruttabile in un ambiente live e concatenare vulnerabilità, credenziali e misconfigurazioni in percorsi di attacco che mostrano quanto lontano potrebbe arrivare un attaccante. Ma la sua copertura rimane limitata nella pratica. La ricerca di Omdia ha rilevato che, sebbene il 95% delle organizzazioni classifichi il pentesting come priorità massima o alta, solo il 32% della loro superficie di attacco media viene testata ogni anno. Gli approcci agentici e automatizzati possono ampliare quella copertura, ma non eliminano ogni vincolo dello sfruttamento live. Per lo sfruttamento basato su CVE, deve esistere un exploit funzionante e il target deve essere sicuro da testare. Le CVE appena divulgate potrebbero non avere ancora un exploit funzionante, mentre gli asset critici per il business, limitati e air-gapped spesso non possono essere testati affatto con un exploit live. Quelle esposizioni hanno comunque bisogno di un verdetto di sfruttabilità, anche quando non c'è nulla che un pentest automatizzato possa eseguire in sicurezza.

Picus sostiene che la risposta è combinare tre metodi di validazione e lasciare che alimentino un unico processo decisionale. La validazione della sfruttabilità determina se un'esposizione è effettivamente sfruttabile nel tuo ambiente, incluse le CVE senza exploit funzionante e gli asset che lo sfruttamento live non può raggiungere in sicurezza. La validazione dei controlli di sicurezza verifica se i tuoi controlli di prevenzione e rilevamento bloccano, rilevano o mancano effettivamente l'attacco. Il pentesting agentico esegue in sicurezza exploit reali e concatena le esposizioni per mostrare quanto lontano può arrivare un attaccante nel tuo ambiente specifico. Questi metodi rispondono a domande diverse in condizioni di esposizione diverse, e Picus afferma che la preparazione a Mythos richiede tutte e tre le capacità in un'unica piattaforma. Ciò non significa che ogni esposizione debba passare attraverso tutti e tre i metodi; l'obiettivo è applicare ciascun metodo dove si adatta meglio e lasciare che le prove contribuiscano allo stesso processo decisionale. Quando i tre pezzi operano come un unico programma, un risultato può innescare il passo di validazione di cui ha effettivamente bisogno, nuove prove possono cambiare la priorità di remediation e le correzioni possono essere rivalidate invece di scomparire in un ticket chiuso. La nota di ricerca di Gartner di maggio punta nella stessa direzione, verso percorsi di attacco validati, risposta guidata dalle decisioni e riduzione dell'esposizione integrata nei flussi di lavoro operativi.

Per i proprietari di siti web e i team IT più piccoli, la lezione pratica è non ignorare gli avvisi di vulnerabilità ma trattare la gravità come punto di partenza piuttosto che come ordine di emergenza. Una CVE con punteggio alto in un plugin che non usi, su un asset che non è esposto a Internet, non dovrebbe innescare la stessa risposta di una falla in un componente core che viene attivamente sfruttata. Verificare se esiste un exploit funzionante, se il tuo stack di controlli bloccherebbe l'attacco e se il sistema interessato è effettivamente raggiungibile sono tutti passi di validazione che possono essere fatti prima della manutenzione di emergenza. Questo è particolarmente rilevante per i clienti di hosting gestito, che spesso si affidano al loro provider per distinguere quali falle note si applicano al loro sito e quali no.

Picus dimostrerà questo modello di lavoro al suo Validation Summit il 14 e 15 ottobre. L'evento si apre con Mikko Hyppönen che spiega perché questo cambiamento è diverso da quelli passati. Il CTO di Picus Volkan Ertürk illustrerà poi come deve apparire la validazione della sicurezza quando gli attaccanti potenziano i loro attacchi con l'IA, e perché la validazione della sfruttabilità, la validazione dei controlli di sicurezza e il pentesting agentico funzionano meglio insieme che da soli. Il team di Picus mostrerà un flusso di validazione live con una vulnerabilità appena divulgata: inizia senza patch e senza exploit funzionante, passa attraverso la validazione prima che esista una proof of concept, testa l'exploit contro i controlli live una volta che appare, e poi rivalida dopo la correzione. Leader della sicurezza di Chanel, Atlassian e NFL discuteranno di come i team di sicurezza maturi stanno adattando i loro programmi di validazione, cosa hanno cambiato e i successi e i fallimenti che hanno sperimentato. Per i team che non gestiscono un programma di validazione completo internamente, un partner IT e di consulenza security-first come AEU-I può aiutare a rivedere le priorità di sicurezza e decidere quali esposizioni meritano attenzione per prime.