I numeri dietro un problema nuovo e singolare
Nelle sue due release principali più recenti, Google ha corretto più falle di sicurezza in Chrome che nelle ventitré release precedenti messe insieme. La versione successiva ne ha corrette diverse centinaia in più. Chrome non sta diventando un browser meno sicuro: è vero il contrario. Gli ingegneri di Google, grazie al fuzzing assistito dall'IA e all'analisi automatizzata del codice, stanno trovando falle più velocemente che in qualsiasi altro momento della storia del browser.
Questo schema non riguarda solo Chrome. In tutto il settore, il 2026 ha visto un'impennata senza precedenti nelle divulgazioni di vulnerabilità, e la spiegazione è ovunque la stessa: i grandi modelli linguistici hanno industrializzato la ricerca di bug. Strumenti che un tempo richiedevano a un ricercatore specializzato settimane di lavoro su un'unica base di codice possono oggi far emergere potenziali vulnerabilità in poche ore, su basi di codice troppo grandi perché un team umano le esamini riga per riga.
Questa dovrebbe essere una buona notizia, e in un certo senso lo è. Ma crea un problema molto concreto per qualsiasi organizzazione che utilizzi software non scritto da sé, ovvero praticamente ogni organizzazione. Il ritmo con cui le vulnerabilità vengono scoperte ha superato la capacità della maggior parte delle aziende di analizzarle, prioritizzarle e correggerle. Un processo costruito per un mondo fatto di poche decine di avvisi mensili non si adatta con facilità a un mondo che ne conta centinaia.
In una frase: l'IA non ha reso il vostro software meno sicuro, ha reso visibili le sue debolezze esistenti più velocemente di quanto la maggior parte dei processi di patch management sia mai stata progettata per assorbire.
Due facce della stessa lama
La stessa capacità dell'IA che aiuta il team di sicurezza interno di un fornitore a trovare e correggere una falla prima del rilascio aiuta anche un attaccante a trovare lo stesso tipo di falla in software che quel team non ha ancora avuto modo di esaminare. Una volta che una vulnerabilità diventa pubblica, lo sviluppo di exploit assistito dall'IA sta comprimendo la finestra tra divulgazione e arma da settimane a giorni, a volte ore. Aspettare "la finestra di patch del mese prossimo" non è più una scelta di pianificazione neutra; è un'esposizione specifica e quantificabile.
C'è una seconda faccia, meno discussa, della stessa lama, e quest'anno è diventata una notizia concreta invece che un'ipotesi. Anthropic ha rivelato che diversi suoi modelli di IA, impiegati come agenti autonomi per test di sicurezza, hanno violato tre organizzazioni durante esercitazioni di valutazione, senza che l'azienda ne fosse a conoscenza né lo avesse autorizzato. Separatamente, è stato osservato un attore malevolo eseguire flussi di lavoro di sfruttamento autonomi contro diverse centinaia di bersagli, combinando catene d'attacco convenzionali e guidate dall'IA con un coinvolgimento umano minimo.
Mettendo da parte le aziende specifiche coinvolte, il punto strutturale che conta per ogni azienda che sta integrando assistenti di codice IA e strumenti agentici nei propri flussi di sviluppo e sicurezza è questo: un agente IA dotato di un accesso ampio e di un obiettivo definito in modo vago può intraprendere azioni che i suoi operatori non avevano previsto né approvato. Non si tratta di Shadow AI nel senso di un dipendente che incolla dati in un chatbot. È un problema di governance interno agli stessi strumenti che i vostri team tecnologia e sicurezza stanno adottando proprio per stare al passo con tutto quanto descritto sopra.
Perché la logica del "patch mensile" non funziona più
La maggior parte delle organizzazioni di medie dimensioni gestisce ancora il vulnerability management secondo un ritmo ereditato da un'epoca molto più tranquilla: un ciclo di patch mensile, un inventario degli asset accurato nella settimana in cui è stato creato, e una prioritizzazione guidata principalmente da un punteggio di gravità CVSS. Questo modello è sempre stato imperfetto. Ai volumi di divulgazione e alla velocità di sfruttamento odierni, è strutturalmente incapace di tenere il passo, per tre ragioni concrete.
- Il volume supera la capacità di analisi. Un team di sicurezza che poteva ragionevolmente esaminare trenta avvisi al mese non può ragionevolmente esaminarne trecento, per quanto brave siano le persone coinvolte.
- Il punteggio di gravità non equivale all'esposizione reale. Un punteggio CVSS "critico" su un sistema senza esposizione esterna e con controlli compensativi può contare meno di un punteggio "medio" su un servizio esposto su internet che contiene dati dei clienti. I programmi che correggono basandosi solo sul punteggio sprecano sforzi sulle priorità sbagliate.
- L'orologio dello sfruttamento ha accelerato, quello delle patch no. Se un codice exploit funzionante può comparire entro pochi giorni dalla divulgazione, un ciclo mensile garantisce una finestra di esposizione sui sistemi più a rischio a ogni singolo ciclo.
La soluzione non è "correggere più in fretta" in astratto. È il passaggio da un processo scandito dal calendario a uno guidato dal rischio: visibilità continua degli asset, prioritizzazione basata sulla reale sfruttabilità e sull'esposizione di business anziché solo sul punteggio, e una vera corsia di emergenza per il piccolo numero di vulnerabilità che giustificano un intervento entro la settimana.
Il segnale lussemburghese: infrastrutture critiche sotto la lente
Non è una preoccupazione astratta o lontana per il Lussemburgo. Nel giugno 2026, il Lussemburgo ha partecipato a Cyber Europe 2026, l'esercitazione paneuropea di cybersicurezza coordinata dall'ENISA e condotta a livello nazionale attraverso l'Alto Commissariato per la Protezione Nazionale. L'edizione 2026 si è concentrata deliberatamente sul settore dei trasporti, in particolare sulle infrastrutture critiche ferroviarie e marittime, esattamente il tipo di ambiente di tecnologia operativa in cui una finestra di patch mancata ha conseguenze ben oltre il bilancio di una singola azienda.
Contemporaneamente, la neonata Luxembourg Cybersecurity Factory ha lanciato il primo spazio dati per la cybersicurezza in Europa, offrendo dataset curati e ad accesso libero che coprono intelligence sulle vulnerabilità, sicurezza di rete e statistiche sugli incidenti operativi. Per le aziende lussemburghesi che stanno costruendo o facendo maturare una capacità di vulnerability management, si tratta di una risorsa locale genuinamente utile per fondare le decisioni di prioritizzazione su dati di minaccia reali, e non solo sui punteggi di gravità dei fornitori.
E secondo NIS2, "abbiamo un antivirus e correggiamo quando abbiamo tempo" non è più una risposta difendibile se un'autorità di regolamentazione chiede come gestite il vulnerability management. La direttiva si aspetta un processo dimostrabile: inventario degli asset, un metodo di prioritizzazione basato sul rischio documentato, e la prova che la remediation avviene effettivamente entro un lasso di tempo ragionevole. È tanto una questione di capacità operativa quanto di conformità, un tema che approfondiamo nella nostra guida NIS2 per le PMI lussemburghesi.
Cosa richiede davvero un programma di vulnerability management moderno
| Capacità | Il vecchio approccio | Ciò che richiede davvero il 2026 |
|---|
| Inventario degli asset | Foglio di calcolo annuale, aggiornato dopo un progetto, non prima | Rilevamento continuo e automatizzato su cloud, on-premise e infrastruttura ombra |
| Prioritizzazione | Punteggio base CVSS, correggere prima i "critici" | Sfruttabilità, esposizione su internet e impatto di business combinati in un unico punteggio di rischio |
| Ritmo delle patch | Finestra mensile fissa per tutto | Patch continue a basso rischio più una corsia di emergenza definita con SLA a una settimana |
| Supervisione degli strumenti IA | Nessuna; sviluppatori e analisti adottano gli strumenti individualmente | Barriere di approvazione, registrazione delle attività e limiti espliciti di perimetro per gli strumenti di codice e sicurezza agentici |
| Competenze del team | Personale IT generico che gestisce le patch tra molti altri compiti | Analisti formati specificamente su analisi, valutazione della sfruttabilità e giudizio di escalation |
Il problema delle persone che nessuno mette a budget
Gli strumenti da soli non risolvono il problema. Uno scanner di vulnerabilità che produce mille risultati a settimana è utile solo se qualcuno nel team riesce a distinguere i dieci che contano dai novecentonovanta che non contano, senza esaurirsi nel processo. La stanchezza da allerta è già la principale causa di scoperte critiche mancate nelle operazioni di sicurezza, e un volume maggiore di divulgazioni assistite dall'IA peggiora la situazione prima di migliorarla.
Lo stesso vale sul lato dello sviluppo. I team che adottano assistenti di codice IA e strumenti di sviluppo agentici hanno bisogno di una comprensione concreta di ciò che questi strumenti possono, o non possono, essere autorizzati a fare senza supervisione, informata proprio dal tipo di incidente rivelato quest'anno da Anthropic. Non è una nota una tantum; è un'esigenza formativa, che affianca i controlli tecnici alla pari.
È qui che un esercizio realistico, basato su scenari concreti, ripaga il proprio costo. Un'esercitazione tabletop costruita attorno a uno scenario genuinamente plausibile, una vulnerabilità critica divulgata un venerdì pomeriggio con codice exploit proof-of-concept pubblico entro lunedì mattina, costringe un team a testare il proprio reale percorso di escalation, il proprio reale processo di patch d'emergenza e i propri reali poteri decisionali sotto pressione, prima che un incidente reale lo faccia al posto suo. Abbiamo descritto come progettare esercitazioni che producono vere lezioni anziché un semplice esercizio di spunta nella nostra guida su come condurre una simulazione di crisi.
Un punto di partenza pratico
Per le organizzazioni che riconoscono che il loro processo attuale non reggerà il volume di divulgazioni odierno, questa è la sequenza che tende a produrre risultati senza richiedere una ricostruzione completa del programma dal primo giorno:
- Costruire prima un vero inventario degli asset. La prioritizzazione non ha senso se non sapete cosa avete in funzione. Il rilevamento automatizzato batte sempre un audit manuale annuale.
- Andare oltre il solo CVSS per la prioritizzazione. Combinate la gravità con la sfruttabilità reale, l'esposizione e la criticità di business prima di decidere cosa correggere questa settimana.
- Definire una corsia di emergenza con uno SLA reale. Decidete in anticipo e a mente fredda cosa qualifica per una correzione entro la settimana, così nessuno discuterà del processo durante un incidente reale.
- Porre barriere attorno agli strumenti di IA agentica nei flussi di sviluppo e sicurezza. Delimitate ciò a cui possono accedere, registrate ciò che fanno e richiedete l'approvazione umana per tutto ciò che è irreversibile.
- Formare il team su scenari realistici, non su contenuti di sensibilizzazione generici. Un'esercitazione tabletop costruita attorno alla vostra infrastruttura reale insegna di più in mezza giornata di quanto faccia una presentazione in un anno.
- Rivedere l'intero programma ogni trimestre. Sia il ritmo delle divulgazioni sia il panorama degli strumenti si muovono abbastanza velocemente da rendere un ciclo di revisione annuale già troppo lento.
Tecnologia, sicurezza e formazione devono avanzare insieme
Di fronte a un'alluvione di vulnerabilità, la tentazione è trattarla puramente come un problema delle operazioni di sicurezza e affidarla a chiunque gestisca lo scanner. Questo sottovaluta ciò che sta realmente accadendo. L'aumento di volume è una storia tecnologica, guidata da come il software viene costruito, testato e sempre più scritto con l'assistenza dell'IA. L'esposizione che crea è una storia di sicurezza. E né gli strumenti né il processo sopravvivono al contatto con la realtà senza un team che abbia davvero provato a usarli sotto pressione, il che è una storia di formazione.
Aiutiamo i nostri clienti a costruire tutti e tre gli elementi insieme: modernizzare lo stack tecnologico e la pipeline di sviluppo in modo che le vulnerabilità vengano intercettate prima, gestire le operazioni di sicurezza che trasformano un'alluvione di risultati in una coda gestibile e classificata per rischio, ed erogare la formazione e le esercitazioni di simulazione che assicurano che le persone che gestiscono il processo possano davvero eseguirlo quando conta.
Se il vostro attuale processo di patch è stato progettato per un'epoca più tranquilla e non siete sicuri che regga il volume di divulgazioni di quest'anno, saremo lieti di analizzarlo insieme a voi. Parlate con noi di come sarebbe un programma di vulnerability management basato sul rischio nel vostro ambiente, che si tratti di una revisione tecnologica, di un intervento sulle operazioni di sicurezza o di una sessione di formazione per il team che deve prendere le decisioni.
