Vulnerability management continuo con l'AI per i requisiti CRA

I team di sicurezza che si affidano a scansioni trimestrali e fogli di calcolo non possono fisicamente rispettare la finestra di 24 ore per la notifica degli exploit attivi. L’automazione della gestione dei rischi costituisce oggi un vincolo legale per operare nel mercato europeo.

Il Cyber Resilience Act (CRA), naturale evoluzione delle direttive nate con l’EU Cyber Security Act, vincola l’accesso al mercato europeo a rigidi standard di sicurezza¹. Inserendo i sistemi operativi per server e i runtime dei container nella classe II dei prodotti critici², il regolamento sottopone i componenti base delle infrastrutture moderne ai controlli più severi previsti dalla legge.

Il rapporto OSSRA 2024 evidenzia come il 91% dei repository contenga componenti arretrati di almeno 10 versioni³. Tracciare le vulnerabilità su questi volumi per mantenere la marcatura CE supera le capacità di qualsiasi team umano.

Implementare un vulnerability management continuo guidato dall’AI permette di affidare ai sistemi di machine learning l’analisi massiva dei dati. Integrare l’apprendimento automatico nei flussi di lavoro sposta il controllo di sicurezza da un evento isolato a una metrica di processo, a patto di misurare con precisione l’affidabilità dei modelli decisionali impiegati.

Perché il vulnerability management reattivo non basta più per il Cyber Resilience Act?

Il vulnerability management reattivo fallisce sotto il Cyber Resilience Act perché la normativa impone la notifica degli exploit attivi entro 24 ore per l’intero ciclo di vita del prodotto. Le tradizionali scansioni periodiche generano ritardi inaccettabili, esponendo l’azienda a sanzioni fino a 15 milioni di euro e al blocco delle vendite.

L’Articolo 14 del regolamento definisce tempistiche inflessibili di reporting verso ENISA⁴ e i CSIRT nazionali. Il legislatore europeo ha eliminato la distinzione tra sviluppo e manutenzione, obbligando i produttori a garantire standard di sicurezza costanti anche anni dopo il rilascio iniziale.

Per inquadrare il perimetro normativo e capire quali responsabilità ricadono sul produttore, abbiamo già spiegato come identificare le classi di rischio previste dal CRA in un articolo dedicato di questa serie.

Il rischio economico colpisce direttamente la continuità di business, poiché le autorità nazionali ottengono il potere di imporre il ritiro del prodotto e il divieto di immissione sul mercato europeo⁵. A questo si aggiungono multe per la mancata conformità ai requisiti essenziali di sicurezza che arrivano fino a 15 milioni di euro o al 2,5% del fatturato annuo globale dell’azienda, a seconda di quale valore sia superiore.

Di fronte a migliaia di dipendenze software stratificate nel tempo, il volume di CVE (Common Vulnerabilities and Exposures) da valutare manualmente cresce più velocemente della capacità di remediation. Il backlog si accumula, dilatando il MTTR (Mean Time To Remediation), ovvero il tempo medio che intercorre tra la scoperta di una vulnerabilità e la sua risoluzione. Una scansione trimestrale lascia scoperte settimane in cui un exploit attivo può colpire i sistemi. La prioritizzazione manuale risulta inoltre soggetta a bias cognitivi, portando gli analisti a sovrastimare i CVE noti e a sottostimare quelli contestuali. Senza una mappa dell’esposizione reale, ogni vulnerabilità sembra ugualmente urgente, e ricostruire la catena causale di un incidente in poche ore risulta matematicamente impossibile.

Come l’AI trasforma il vulnerability management in un processo continuo

L’intelligenza artificiale trasforma il vulnerability management automatizzando la prioritizzazione e riducendo i falsi positivi. Correlando i CVE con l’effettiva esposizione del codice in produzione, l’AI permette ai team di concentrarsi sui rischi reali, abbattendo il tempo medio di risoluzione e garantendo il rispetto delle finestre di notifica normative.

Nel nostro approccio su progetti fintech complessi nel 2023, gestendo oltre 400 repository e migliaia di CVE storici, l’integrazione di automazione e correlazione contestuale ha generato metriche di efficienza misurabili. Nella nostra esperienza, partendo da un baseline di 14 giorni, riteniamo che il flusso strutturato abbia abbattuto il MTTR a meno di 48 ore, con una riduzione che stimiamo intorno all'80%. Questo risultato deriva da un processo che incrocia identificazione delle dipendenze, database delle vulnerabilità e validazione continua con blocco selettivo. La base tecnologica risiede nell’automazione del ciclo di vita del software, un terreno che abbiamo esplorato analizzando come l’intelligenza artificiale ridisegna le pipeline DevOps e i processi di sicurezza.

Il flusso AI-driven opera in quattro fasi sequenziali:

1. Ingestione: raccolta continua di SBOM, log e dati di runtime dalle pipeline e dagli ambienti di produzione.
2. Correlazione: incrocio automatico dei componenti con i database di vulnerabilità e gli indicatori di exploit attivi.
3. Prioritizzazione: ranking dei CVE in base all’impatto reale sul prodotto, non alla sola severità teorica.
4. Notifica: generazione dell’audit trail necessario a rispettare le tempistiche di reporting verso ENISA.

Prioritizzazione intelligente e riduzione del rumore

La prioritizzazione contestuale distingue un alert utile dal rumore di fondo. L’AI correla ogni CVE con il contesto reale di esposizione, verificando se l’asset si trova in produzione, se il codice vulnerabile viene effettivamente richiamato dal flusso applicativo e se esiste un exploit attivo in circolazione.

Sullo stesso programma fintech del 2023, dove gli scanner sui 400 repository producevano in media oltre un migliaio di segnalazioni a settimana, la correlazione contestuale ha tagliato di circa due terzi il volume di alert che richiedevano un intervento umano. Invece di smistare manualmente centinaia di segnalazioni indifferenziate, il team interveniva esclusivamente sulle falle con impatto reale sul prodotto soggetto a marcatura CE.

Monitoraggio continuo e detection delle anomalie

I modelli di anomaly detection osservano i comportamenti runtime e segnalano le deviazioni rispetto a un baseline appreso. Questo meccanismo anticipa lo sfruttamento di vulnerabilità non ancora catalogate, spostando la postura di sicurezza da reattiva a proattiva.

La normativa DORA⁶, rilevante per chi opera nel settore finanziario, presenta dinamiche simili. Entrambe le direttive spingono verso il monitoraggio continuo del rischio digitale, ma con un focus diverso, come abbiamo analizzato esaminando l’impatto di NIS2 e DORA sulla cybersecurity cloud native.

Il CRA guarda al prodotto, mentre DORA guarda all’entità. Un’azienda finanziaria che sviluppa software ricade spesso sotto entrambi, rendendo il monitoraggio continuo un doppio obbligo legale.

Cosa significa observability dell’AI e perché conta per la conformità?

L’observability ai consiste nel monitorare costantemente la qualità dei dati, il drift dei modelli e l’affidabilità degli output decisionali. Per la conformità normativa, sorvegliare i sistemi intelligenti è obbligatorio: un modello degradato che genera falsi negativi espone il prodotto a vulnerabilità non rilevate, compromettendo la marcatura CE.

L’artificial intelligence observability assicura che gli strumenti di automazione non introducano nuovi punti ciechi. Un sistema che classifica male le vulnerabilità produce un danno attivo, ignorando minacce che dovrebbe bloccare. La ML observability diventa quindi parte integrante della catena di sicurezza. L’introduzione di modelli AI nei processi difensivi richiede trasparenza e gestione del rischio, poiché il produttore deve rendere conto delle decisioni automatizzate per mantenere la conformità.

Monitorare i modelli che monitorano la sicurezza

Tre segnali definiscono lo stato di salute di un modello applicato alla sicurezza: data quality monitoring, drift detection e spiegabilità degli output. Il drift risulta particolarmente insidioso perché agisce in silenzio. Un modello addestrato su un certo profilo di minacce degrada man mano che le tipologie di attacco evolvono, senza generare errori evidenti nei log tradizionali.

La categoria della data observability, rappresentata sul mercato da strumenti come IBM databand⁷, nasce proprio per sorvegliare le pipeline dati che alimentano i modelli. Per approfondire le strategie di controllo sui sistemi probabilistici abbiamo descritto come governare e monitorare gli agenti AI in produzione, un tema che si applica con la stessa logica ai tool di sicurezza.

Guardrails e tracciabilità delle decisioni automatizzate

La conformità richiede la dimostrazione documentata di come una specifica vulnerabilità viene classificata e gestita. Servono un audit trail delle decisioni AI e guardrails che impediscano azioni automatiche non verificate, soprattutto quando l’esito influenza la validità della marcatura CE.

Il nostro approccio di security-by-design stabilisce che l’automazione deve abilitare i team, mantenendo il controllo umano sulle decisioni critiche. Occorre monitorare la qualità dei dati in ingresso al modello e misurare il drift rispetto al baseline di addestramento. Diventa altrettanto importante valutare la latenza decisionale tra rilevazione e classificazione, tenendo sotto stretto controllo il tasso di falsi negativi.

Implementare il vulnerability management continuo: cosa serve davvero

L’implementazione richiede un percorso strutturato: acquisizione della visibilità totale sulle dipendenze tramite SBOM, automazione della prioritizzazione dei rischi e monitoraggio continuo dei modelli AI. Questo approccio trasforma l’adeguamento normativo in un processo integrato nelle pipeline DevSecOps, evitando i colli di bottiglia tipici dei controlli manuali.

La prima fase parte dall’inventario delle dipendenze. Abbiamo approfondito questo aspetto spiegando come la Software Bill of Materials mappa i rischi della supply chain sotto il CRA: senza una SBOM aggiornata, qualsiasi automazione lavora su dati incompleti. I rischi gestionali richiedono attenzione immediata, poiché affidarsi ciecamente all’AI senza supervisione umana trasforma uno strumento di mitigazione in un single point of failure. Seguono la qualità insufficiente dei dati di addestramento e l’attrito nell’integrazione con le pipeline DevSecOps esistenti. In questi flussi, i security gate devono bloccare i rilasci non conformi senza paralizzare la velocità di sviluppo.

La conciliazione tra requisiti CRA e sostenibilità operativa vede il nostro team direttamente coinvolto. Il nostro CTO Paolo Mainardi è Advisory Member di Linux Foundation Europe⁸ e ha sostenuto l’iniziativa #FixTheCRA, nata per evitare che il regolamento penalizzi l’ecosistema open source⁹. Fondazioni come Apache Software Foundation e Eclipse Foundation hanno espresso forti critiche al testo iniziale, per poi accogliere positivamente gli emendamenti di fine 2023¹⁰.

Misurare la maturità reale del processo richiede indicatori precisi:

• Inventario delle dipendenze aggiornato e versionato (SBOM).

• Misurazione del MTTR come metrica di processo effettiva e non come semplice stima.

• Pipeline CI/CD con security gate attivi e bloccanti.

• Monitoraggio continuo dei modelli AI impiegati.

• Processo di notifica capace di operare entro le rigide tempistiche normative.

L’assenza di uno solo di questi requisiti mantiene aperta l’esposizione al rischio legale.

Conclusione e prossimi passi

Automatizzare la gestione delle vulnerabilità tramite l’AI trasforma la conformità al Cyber Resilience Act in un processo sostenibile, eliminando la corsa contro il tempo a ogni nuovo CVE.

Le sanzioni fino a 15 milioni di euro definiscono chiaramente il rischio aziendale. Al contempo, la riduzione del tempo medio di risoluzione (MTTR) dell'80% quantifica il ritorno sull’investimento tecnico.

Valutare la maturità del proprio processo richiede l’analisi dell’inventario, la misurazione del MTTR e la verifica dei modelli AI in uso. Per trasformare questa valutazione in una strategia operativa lungo l’intera filiera, i nostri specialisti possono accompagnarti nella messa in sicurezza della software supply chain.

Il prossimo articolo della serie affronta i criteri architetturali e strategici per scegliere e implementare soluzioni software capaci di mantenere la conformità CE per l’intero ciclo di vita del prodotto, fornendo linee guida agnostiche per la selezione degli strumenti.

Note e fonti