ENISA e l'IA di frontiera: 5 conseguenze per il CRA

Nel gennaio 2026 curl ha chiuso il proprio programma di divulgazione coordinata delle vulnerabilità. Le segnalazioni generate dall’IA avevano sommerso i manutentori, e il progetto ha deciso che l’intake costava più di quanto rendesse. ENISA cita ora quella chiusura in una pubblicazione ufficiale. Ecco la parte che la riguarda: un fabbricante CRA non può fare la stessa scelta. Il Cyber Resilience Act rende obbligatorio per legge un intake di divulgazione delle vulnerabilità dall’11 dicembre 2027. curl ha scelto un’uscita. Lei non ne avrà una.

Questa è una delle cinque collisioni tra il nuovo position paper di ENISA e i suoi obblighi CRA. ENISA ha pubblicato la propria posizione sulla cibersicurezza nell’era dell’IA di frontiera nel luglio 2026. Le 16 pagine si rivolgono alle autorità nazionali, ai policymaker UE, ai difensori e ai fornitori di servizi. Nessuna sezione è scritta per i fabbricanti di prodotti. Le conseguenze arrivano comunque sulla sua scrivania.

Cosa ha pubblicato ENISA

Il rapporto è una nota di posizione di 16 pagine, sviluppata con la Rete dei CSIRT UE e EU-CyCLONe tra maggio e giugno 2026. Il suo avviso legale dichiara che non crea alcun obbligo normativo. Lo tratti come un segnale della direzione verso cui si muove la guida operativa di ENISA, e lo legga insieme agli obblighi CRA che già la vincolano.

La tesi centrale è misurabile. La finestra tra scoperta e sfruttamento di una vulnerabilità è passata da anni a mesi a minuti. I dati citati da ENISA collocano la trasformazione in arma a 15 minuti dopo la divulgazione e l’esfiltrazione mediana a 72 minuti dopo l’accesso iniziale. NCSC-NL aggiunge che gli agenti autonomi eliminano il vantaggio del difensore legato alla scoperta privata. Una volta che un agente IA trova una vulnerabilità, costruire l’exploit è un calcolo, non un progetto di ingegneria. Alcuni exploit esistono ormai prima della correzione, ciò che il rapporto chiama tempo di sfruttamento negativo.

ENISA è schietta sull’altro lato dell’equazione. Il rapporto afferma che la capacità di ENISA stessa, insieme a quella dei fabbricanti e dei CSIRT nazionali, necessita di rafforzamento o revisione per gestire la prossima ondata di vulnerabilità scoperte. L’agenzia responsabile della Piattaforma Unica di Segnalazione le sta dicendo, per iscritto, che i volumi metteranno sotto pressione tutti.

Le cinque sezioni seguenti prendono ciascuna un dato del rapporto e lo seguono fino a un obbligo CRA.

1. curl ha chiuso l’intake delle vulnerabilità. Lei non può

Già all’inizio del 2026, le segnalazioni di vulnerabilità generate dall’IA avevano iniziato a sommergere parti della pipeline di divulgazione open source. Il rapporto nomina il danno: una piattaforma globale di bug bounty ha sospeso le nuove candidature all’Internet Bug Bounty dopo un’ondata di segnalazioni assistite dall’IA di qualità mista, e curl ha chiuso il proprio programma CVD nel gennaio 2026 perché i manutentori non riuscivano ad assorbire il volume e il rumore. Il problema è la diluizione del segnale. I revisori umani spendono il loro tempo a separare i risultati reali dalle segnalazioni ripetitive, superficiali o non validate.

Un progetto open source può chiudere la porta. Sotto il CRA Lei non può. Il Regolamento la obbliga a gestire e applicare una politica di divulgazione coordinata delle vulnerabilità, e a pubblicare un indirizzo di contatto per segnalare le vulnerabilità nel suo prodotto. Entrambi gli obblighi si applicano dall’11 dicembre 2027. Ecco la verità scomoda: il CRA è stato scritto assumendo che le segnalazioni fossero scarse e preziose. Il rapporto documenta un mondo in cui arrivano a centinaia, scritte da macchine e non verificate. L’obbligo resta. L’assunzione alla sua base è sparita.

La sua politica CVD ha quindi bisogno di una clausola per l’era dell’IA. Tre elementi devono farne parte:

• Requisiti di validazione: indichi cosa deve contenere una segnalazione per entrare in triage. Prodotto e versione interessati, passaggi di riproduzione o una proof of concept, e l’impatto osservato. Una segnalazione priva di questi elementi riceve una richiesta di completamento, non uno slot di triage.
• Deduplicazione prima del triage: gli strumenti IA ripresentano la stessa debolezza in molte formulazioni diverse. Raggruppi prima le segnalazioni in arrivo rispetto ai risultati già noti, e conti i cluster, non le email.
• Impegni di triage per gravità: pubblichi tempi di risposta che può mantenere a 10 volte il volume attuale. Uno SLA di conferma di ricezione che infrange ogni settimana è una prova peggiore di uno SLA modesto che rispetta.

Un’ultima sfumatura dal rapporto: ENISA nota che gli ultimi mesi hanno portato un aumento reale nella qualità delle segnalazioni generate dall’IA, quindi una regola generale «no segnalazioni IA» butta via segnale utile. Filtri per completezza e riproducibilità, non per autore. Pubblicare la meccanica dell’intake tramite security.txt mantiene verificabile il dovere di punto di contatto.

2. L’IA sta gonfiando il significato di «nota e sfruttabile»

Il rapporto riporta un dato che cambia l’ingegneria dei rilasci. Un’organizzazione di settore ha riferito a ENISA di essere passata da circa 80 CVE nel primo trimestre 2025 a quasi 500 nel primo trimestre 2026, e poi a circa 500 al giorno una volta adottati strumenti abilitati dall’IA di frontiera. ENISA chiama questo fenomeno la svalutazione economica della scoperta. Trovare falle sta diventando industrializzato, quindi il volume di divulgazione cresce più velocemente di quanto chiunque possa rimediare.

Il CRA vieta di immettere sul mercato un prodotto con vulnerabilità note e sfruttabili. Due parole reggono questa regola. L’IA espande nota meccanicamente. Ogni scansione eseguita sul suo SBOM fa emergere più risultati, ogni trimestre. Ciò che l’IA non cambia è sfruttabile, ed è qui che vive ora la sua prova di conformità. Il lavoro di punteggio di gravità che separa la gravità intrinseca dalla probabilità di sfruttamento smette di essere un’ottimizzazione e diventa il gate di rilascio stesso.

Il punto della concatenazione taglia in entrambe le direzioni. ENISA avverte che le vulnerabilità a basso rischio non possono più essere liquidate come innocue, perché i modelli le concatenano in exploit funzionanti. Quindi «CVSS basso, ignorare» è morta come regola di triage. Ma anche un gate in CI basato sul semplice conteggio delle CVE muore: a 500 risultati al giorno blocca ogni rilascio per sempre. Ciò che sopravvive è la sfruttabilità documentata per ciascun risultato. Il rapporto nomina i due strumenti: EPSS di FIRST per la probabilità di sfruttamento, e VEX per registrare se il suo prodotto sia affetto o meno.

3. Ogni patch che rilascia mappa il buco nelle sue versioni precedenti

La sezione del rapporto sulla trasformazione in arma degli N-day afferma che i diff delle patch e le modifiche ai binari hanno storicamente alimentato il reverse engineering e lo sviluppo di exploit, e che la finestra di sfruttamento si apre prima del rilascio della patch. L’IA di frontiera comprime quel reverse engineering da giorni di lavoro specialistico a un calcolo. Il rapporto nota inoltre che l’analisi assistita dall’IA accelera la comprensione del codice nei sistemi legacy.

Ora inserisca la sua linea di prodotti in questo quadro. Rilascia una correzione di sicurezza per la versione N. Il diff descrive la vulnerabilità con precisione. Se la versione N-1 condivide il codice interessato ed è oltre la fine del proprio supporto, la sua stessa patch è la migliore guida di sfruttamento disponibile contro la sua base installata. A velocità umana questo era un rischio noto ma lento. A velocità macchina è un rischio dello stesso giorno.

Questo cambia il significato di due decisioni CRA:

• Il periodo di supporto, cinque anni minimo nella maggior parte dei casi, definisce quali versioni ricevono ancora correzioni. Le versioni al di fuori di esso non spariscono dal campo. Restano raggiungibili, e ogni correzione che pubblica per le versioni supportate insegna qualcosa agli attaccanti anche su di loro. La proliferazione delle versioni è ormai superficie di attacco, quindi poche versioni supportate più longeve battono molte versioni di breve durata. Veda periodo di supporto per come viene fissata la durata.
• La divulgazione di fine supporto che deve agli acquirenti prima dell’acquisto diventa informazione operativa, non semplice documentazione da scaffale. Un acquirente che opera oltre la data che ha divulgato sta utilizzando un prodotto che il suo stesso flusso di patch descrive agli attaccanti. Lo dichiari nella divulgazione. La pagina divulgazione di fine supporto copre dove deve comparire la data.

Il consiglio di NCSC Ireland nel rapporto è diretto: rivedere gli inventari degli asset, dare priorità alla disciplina di patching e valutare l’esposizione ai componenti non supportati. Per un fabbricante, il dovere speculare è impedire che il divario tra «ramo con patch» e «ramo abbandonato» si allarghi silenziosamente.

4. Le patch scritte dall’IA vengono comunque rilasciate sotto la sua marcatura CE

ENISA si aspetta che la rimediazione adotti gli stessi strumenti della scoperta. Il collo di bottiglia della verifica descritto dal rapporto è il risultato. I team tecnici affrontano una sfida di scala nell’auditare e validare le patch generate dall’IA affinché non introducano nuove vulnerabilità nel codice. Il rapporto descrive anche la pressione sull’altro lato, un Authority Gap in cui i comitati umani di change management non riescono ad autorizzare interventi nei minuti disponibili per contrastare exploit autonomi.

Il CRA non ha un’opinione su chi o cosa scrive il suo codice. Ne ha una ferma su chi ne risponde. Il Regolamento richiede test di sicurezza efficaci e regolari sul suo prodotto, e la dichiarazione di conformità che firma in base alla valutazione di conformità copre ogni patch che distribuisce durante il periodo di supporto. Una correzione generata dall’IA che apre un nuovo buco è una sua non conformità, a velocità macchina.

La conseguenza pratica è questa: la sua pipeline di patch ha bisogno di prove di test che scalino con il volume delle patch. La revisione umana di ogni riga scritta dall’IA non scala fino a 500 risultati al giorno. Il test di sicurezza automatizzato e documentato sul percorso delle patch invece scala, e produce gli artefatti di cui il suo fascicolo tecnico ha bisogno. Se adotta la rimediazione assistita dall’IA, registri quali patch sono state generate da una macchina e quale validazione ciascuna ha superato. Quando un’autorità di regolamentazione le chiede come ha mantenuto onesto il suo dovere di test a quella velocità, la risposta è un log, non una dichiarazione di policy.

5. Le sue segnalazioni di vulnerabilità diventano uno storico pubblico

L’ultima conseguenza è la più silenziosa nel rapporto. ENISA scrive che i dati EUVD correlati possono identificare punti caldi della catena di fornitura, debolezze sistemiche e tendenze delle vulnerabilità accelerate dalla scoperta assistita dall’IA. Una frase più avanti: la segnalazione legata al CRA può aiutare a validare le dichiarazioni di hardening dei fornitori a fronte della sfruttabilità reale e degli schemi degli incidenti.

Legga questo come fabbricante. Dall’11 settembre 2026 lei segnala le vulnerabilità attivamente sfruttate e gli incidenti gravi entro 24 ore tramite la Piattaforma Unica di Segnalazione, poi un follow-up entro 72 ore, poi un rapporto finale entro 14 giorni dalla correzione. Ogni segnalazione finisce in un’infrastruttura che ENISA intende correlare. Nel tempo, quella correlazione diventa una storia di sicurezza per ciascun fornitore: quante volte è stato sfruttato, quanto velocemente ha corretto, come il suo storico si confronta con le sue dichiarazioni.

Ne conseguono due comportamenti:

• Scriva dichiarazioni di sicurezza del prodotto che possa difendere con la propria storia di segnalazioni. «Hardened» e «secure by design» su una scheda tecnica finiranno col tempo accanto alla sua riga EUVD. Un marketing che corre più veloce dei dati diventa un argomento di vigilanza del mercato.
• Tratti la qualità della segnalazione come reputazione, non come documentazione burocratica. Una notifica precisa entro 72 ore con misure correttive reali si legge in modo diverso da una minima, e l’obiettivo dichiarato di ENISA è chiudere il divario tra divulgazione e risposta coordinata usando questi dati. La catena di segnalazione stessa è entrata in funzione a tappe quest’anno, con ENISA che integra le sue prime CVE Numbering Authorities nel maggio 2026.

La sintesi esecutiva del rapporto afferma che la SRP deve essere utilizzata, una volta funzionante, per affrontare le sfide dei nuovi sviluppi. ENISA si è impegnata per iscritto in tal senso. Le sue segnalazioni sono l’input.

Questo articolo ha finalità puramente informative e non costituisce consulenza legale. Per una guida specifica alla conformità, si rivolga a un legale qualificato.