ESTRATTO
Le prove di settembre 2025 confermano che l’Italia è entrata nel tessuto di governance globale delle vulnerabilità zero-day attraverso la designazione formale di Leonardo SpA e Almaviva SpA come CVE Numbering Authority (CNA) , con avvisi ufficiali pubblicati dal Programma CVE rispettivamente il 23 settembre 2025 e il 30 settembre 2025 , che definiscono le responsabilità di prodotto per l’assegnazione degli identificatori CVE e la pubblicazione di record convalidati nell’ambito del regime di enumerazione internazionale guidato dal MITRE e arricchito dal National Vulnerability Database (NVD) del NIST . La notizia del Programma CVE per Leonardo cita specificamente l’ambito di ” Leonardo SC2″, mentre l’ avviso di Almaviva fa riferimento a “soluzioni software proprietarie come Joshua”, entrambi pubblicati sul sito web ufficiale CVE alle seguenti date: Leonardo aggiunta come CVE Numbering Authority (CNA), 23 settembre 2025 e Almaviva aggiunta come CVE Numbering Authority (CNA), 30 settembre 2025 . Le basi della politica e del processo per questi ruoli sono documentate nelle pagine organizzative e di processo del Programma CVE , che definiscono la funzione CNA , i livelli di governance e il ciclo di vita dei record end-to-end, inclusa la manutenzione dell’elenco CVE da parte dei partner accreditati e la pipeline di pubblicazione verso repository downstream come NVD ; vedere Programma CVE — Informazioni/Panoramica , Programma CVE — Organizzazione/Struttura del programma e Programma CVE — Processo: Ciclo di vita dei record CVE .
All’interno dell’infrastruttura di dati sulle vulnerabilità degli Stati Uniti , la descrizione autorevole di NVD come repository del governo statunitense per i dati di gestione delle vulnerabilità basati su standard e l’arricchimento basato su CVSS è gestita dal NIST nelle sezioni NVD – Home , NVD – General , NVD – CVE Process e Understanding Vulnerability Detail Pages , che spiegano collettivamente che NVD acquisisce record CVE pubblicati , esegue l’arricchimento, espone feed di dati ed endpoint API e fornisce metriche e visualizzazioni per la valutazione del rischio; vedere anche NVD – Data Feeds e NVD – Vulnerability Visualizations . Parallelamente, l’ Unione Europea ha lanciato un repository sovrano per migliorare la resilienza e la trasparenza nell’ambito del quadro giuridico NIS2 : l’ European Vulnerability Database (EUVD) , sviluppato e gestito dall’ENISA ai sensi della Direttiva (UE) 2022/2555 .
Il mandato legale è esplicito nelle disposizioni e nei considerando dell’articolo NIS2 , accessibili su EUR-Lex alla Direttiva (UE) 2022/2555 (consolidata), 27 dicembre 2022 e nel PDF ufficiale su EUR-Lex CELEX:32022L2555 . L’ENISA ha reso operativo il database con comunicati pubblici e un portale dedicato, inclusi strumenti di query e un indice di endpoint aperto, disponibili su EUVD — Portale , EUVD — Elenco delle vulnerabilità , EUVD — FAQ , EUVD — Documentazione API e il comunicato stampa Consulta il database europeo delle vulnerabilità per migliorare la tua sicurezza digitale! 13 maggio 2025. Le pagine complementari sulla politica ENISA chiariscono le aspettative CVD , l’instradamento attraverso i CSIRT nazionali nell’ambito di NIS2 , come dettagliato su ENISA — Divulgazione delle vulnerabilità e la nota di supporto Un altro passo avanti verso una divulgazione responsabile delle vulnerabilità in Europa, 12 giugno 2024 .
Il cambiamento strategico in Italia è in linea con il rafforzamento della governance nazionale sotto l’egida dell’Agenzia per la Cybersicurezza Nazionale (ACN) , la cui documentazione strategica e operativa sottolinea la spinta istituzionale verso la maturità, la verifica e il coordinamento settoriale del processo di disclosure. Fonti ufficiali dell’ACN segnalano il rafforzamento delle capacità, le attività relative alla disclosure e il supporto di CSIRT Italia , nonché la necessità di stabilire una linea politica nazionale in materia di CVD . Questi elementi sono rintracciabili nei documenti strategici e nelle revisioni annuali dell’ACN, tra cui la Strategia Italiana per la Cybersicurezza 2022-2026 (versione inglese, PDF) , la Relazione Annuale 2023 (15 maggio 2024, PDF) e il quadro di attuazione che elenca esplicitamente la politica nazionale in materia di CVD tra i risultati del Piano di Implementazione — ACN (PDF) . I briefing operativi e le dichiarazioni di servizio di CSIRT Italia dimostrano il ruolo funzionale nel monitoraggio delle vulnerabilità e nell’allerta precoce, ad esempio CSIRT Italia – Profilo RFC2350 (8 maggio 2023) e Direzione Operazioni e Gestione Crisi – Sintesi Operativa TLP:CLEAR (maggio 2025) . In questo contesto normativo e istituzionale, l’emergere di Leonardo e Almaviva come CNA fornisce punti di ancoraggio concreti per la divulgazione guidata dall’industria in Italia , creando punti di rilascio nazionali per gli identificatori CVE , riducendo la latenza tra la scoperta e l’enumerazione e incorporando routine CVD in linea con gli standard ISO/IEC e le best practice FIRST .
I fondamenti normativi per la gestione delle vulnerabilità e del CVD sono codificati nelle norme ISO/IEC 29147:2018 e ISO/IEC 30111:2019 , che forniscono requisiti e raccomandazioni standardizzati per la ricezione di segnalazioni, il coordinamento delle azioni correttive e la pubblicazione di avvisi, come descritto nelle pagine ufficiali ISO ISO/IEC 29147:2018 — Divulgazione delle vulnerabilità e ISO/IEC 30111:2019 — Processi di gestione delle vulnerabilità . Le linee guida per il coordinamento multilaterale sono elaborate nella norma ISO/IEC TR 5895:2022 — Divulgazione e gestione coordinate multilaterali delle vulnerabilità . FIRST gestisce linee guida pratiche e manuali dell’ecosistema , in particolare le Linee guida e le pratiche per il coordinamento delle vulnerabilità multipartitiche (v1.1) e i framework PSIRT in PSIRT Maturity e PSIRT Services Framework 1.1 , che specificano i processi per l’assunzione sicura, il triage, le tempistiche coordinate e l’accreditamento dei ricercatori, procedure che le organizzazioni CNA in genere istituzionalizzano attraverso team formali di sicurezza dei prodotti e delle politiche.
La dimensione geopolitica più ampia riguarda la continua centralità delle piattaforme statunitensi ( CVE , NVD ) nell’enumerazione globale rispetto agli sforzi per istituzionalizzare l’autonomia dell’UE . NIS2 riconosce esplicitamente che i repository esistenti “sono ospitati e gestiti da entità che non sono stabilite nell’Unione “ e incarica l’ENISA di sviluppare e gestire un database europeo per migliorare la trasparenza e la resilienza prima degli eventi di divulgazione pubblica, una logica affermata nel testo giuridico in EUR-Lex CELEX:32022L2555 (PDF) e riassunta sui portali della Commissione europea in Cybersecurity of network and information systems — NIS2 summary . A partire dal 2025 , EUVD è attivo, esponendo interfacce di ricerca ed endpoint API e riflettendo un modello progettato per integrare, non necessariamente sostituire, le pipeline CVE / NVD , consentendo al contempo una governance incentrata sull’UE , lo scambio di dati strutturati ( CSAF ) e l’integrazione con i CSIRT ; vedere EUVD — Portale , EUVD — Documentazione API e ENISA — Divulgazione delle vulnerabilità .
Riferimenti comparativi a repository nazionali non UE indicano che esistono modelli di governance alternativi al quadro statunitense . L’ ecosistema cinese gestisce repository di vulnerabilità gestiti dallo Stato, tra cui il China National Vulnerability Database of Information Security (CNNVD) e il China National Vulnerability Database (CNVD) . Senza attribuire motivazioni o avanzare affermazioni che vadano oltre le dichiarazioni di intenti pubblicate ufficialmente, è possibile dimostrare l’esistenza e la posizione operativa del CNNVD tramite pagine autorevoli su CNNVD — Informazioni/Contatti/Programma e CNNVD — Programma dell’Unità di Supporto Tecnico , e la presenza del CNVD come piattaforma separata per la condivisione delle vulnerabilità gestita da CNCERT/CC su CNVD — Portale Principale . Questi repository differiscono in termini di governance, tempistiche di divulgazione e interfacce pubbliche da CVE / NVD , a dimostrazione del fatto che le architetture di enumerazione e divulgazione sono contingenti a livello politico e istituzionale. Questa prospettiva comparativa è rilevante per il dibattito sull’autonomia dell’Europa perché sottolinea la fattibilità di repository sovrani in grado di integrare l’enumerazione, la caratterizzazione del rischio e il coordinamento nazionale, capacità che NIS2 assegna all’ENISA tramite EUVD .
Per l’Italia , l’aggiunta di Leonardo e Almaviva come CNA ha implicazioni operative immediate.
- In primo luogo, l’enumerazione dell’ambito del prodotto può essere avviata a livello nazionale, consentendo cicli più rapidi di prenotazione, convalida e pubblicazione CVE che alimentano i registri globali e l’arricchimento NVD , riducendo il periodo durante il quale i difetti non documentati rimangono non gestiti.
- In secondo luogo, i canali CVD nazionali vengono rafforzati perché i team CNA in genere mantengono processi di assunzione coerenti con ISO/IEC 29147/30111 e i framework PSIRT di FIRST , migliorando il coinvolgimento dei segnalatori, il triage, la sincronia delle misure di rimedio e l’accredito consultivo, fattori noti per ridurre il vantaggio dell’avversario durante l’intervallo pre-patch.
- In terzo luogo, migliora la segnalazione del settore: quando i principali integratori e fornitori di tecnologia formalizzano le responsabilità CNA , le aziende peer sono incentivate a maturare politiche CVD , adottare tempi strutturati e convergere verso schemi interoperabili ( CSAF ), migliorando in definitiva l’affidabilità della gestione del rischio settoriale e la credibilità delle dichiarazioni di garanzia dei fornitori.
Questi effetti sono coerenti con la logica di governance di NIS2 e con il percorso di rafforzamento delle capacità delineato dalla strategia, dai piani di implementazione e dalle operazioni CSIRT di ACN , come citato sopra.
A valle, l’architettura di EUVD e l’impalcatura legale di NIS2 creano un meccanismo affinché i risultati delle CNA italiane possano coesistere con i repository UE , pur essendovi referenziati , consentendo la convalida incrociata, la correlazione dello stato di sfruttamento e l’allineamento con i CSIRT per avvisi coordinati. Poiché NVD rimane di fatto un livello di arricchimento globale, fornendo punteggi, mappature di configurazione e feed programmatici, i record CNA dall’Italia continueranno ad apparire in NVD entro i tempi di acquisizione tipici descritti nelle linee guida NIST , facilitando la mappatura dell’inventario delle risorse e l’orchestrazione delle patch tra le impronte multinazionali che operano in ambienti di conformità sia UE che USA . Allo stesso tempo, gli endpoint aperti di EUVD e le pagine di processo di ENISA indicano una traiettoria verso metadati più ricchi e incentrati sull’UE , che potenzialmente includono la registrazione prima della divulgazione e lo scambio strutturato di avvisi per supportare la bonifica sincronizzata tra gli Stati membri ; vedere NVD — Processo CVE , EUVD — Documentazione API e ENISA — Divulgazione delle vulnerabilità .
Il risultato combinato è un passaggio strutturale dalla “sicurezza tramite oscurità” a un’enumerazione e una divulgazione responsabili all’interno dell’ecosistema tecnologico italiano, ora ancorato a CNA nominate con ambito di applicazione pubblicato nell’ambito del Programma CVE . La disponibilità di avvisi CVE ufficiali per Leonardo e Almaviva a partire da fine settembre 2025 è il segnale verificabile di questo passaggio. Un’infrastruttura complementare a livello UE attraverso EUVD , fondata sul diritto vincolante dell’UE ( NIS2 ), costruisce un archivio continentale di interesse pubblico per integrare l’enumerazione globale, preservando al contempo l’interoperabilità con le pipeline esistenti. La strategia e il quadro di attuazione ACN stabiliscono il vettore di governance nazionale necessario per istituzionalizzare la CVD e i relativi test, mentre gli standard ISO/IEC e i framework FIRST offrono modelli operativi maturi per lo sviluppo del PSIRT . Questi elementi sono pienamente evidenziati nelle principali fonti istituzionali: pagine di notizie e procedure del programma CVE , documentazione NIST NVD , portali e comunicati stampa ENISA EUVD , testi giuridici EUR-Lex , documenti strategici ACN e standard e linee guida ISO/IEC / FIRST , tutti pubblicati su domini ufficiali e accessibili tramite i collegamenti ipertestuali incorporati sopra.
INDICE DEI CAPITOLI
1. Pre-CNA Italia: Baseline istituzionale, lacune informative ed esternalità del rischio
2. Onboarding e ambito di applicazione della CNA nella pratica: Leonardo e Almaviva all’interno del programma CVE
3. Operazioni coordinate di divulgazione delle vulnerabilità: ISO/IEC 29147/30111, FIRST PSIRT e coinvolgimento dei segnalatori
4. Governance italiana e prontezza del settore: ACN, CSIRT Italia e allineamento con i controlli NIS2
5. Architettura continentale e autonomia strategica: EUVD sotto ENISA rispetto all’arricchimento globale NVD
6. Prospettive e rischi di implementazione: metriche, interoperabilità e garanzia della catena di fornitura
Italia pre-CNA: situazione istituzionale di base, lacune informative ed esternalità del rischio
Prima del riconoscimento formale di Leonardo e Almaviva come CNA , il contesto italiano di gestione delle vulnerabilità presentava lacune sistemiche e norme di informativa deboli, con conseguenti esposizioni strutturali al rischio. Questo capitolo documenta la situazione istituzionale di base, la scarsità di pratiche di enumerazione nazionali, la persistenza della “sicurezza per oscurità” e le esternalità create da tali omissioni, il tutto supportato da fonti verificate.
Storicamente, l’Italia non ha mai avuto un’autorità di numerazione CVE (CNA) . L’ elenco pubblico delle organizzazioni partner del Programma CVE non includeva alcuna azienda o istituzione italiana prima di settembre 2025 , e importanti elenchi di CNA globali (ad esempio, l'”Elenco dei partner” del Programma CVE) non mostravano alcuna affiliazione italiana. L’annuncio “Leonardo aggiunto come autorità di numerazione CVE (CNA)” riporta la data del 23 settembre 2025 come prima voce italiana di CNA. ( cve.org ) Il successivo avviso “Almaviva aggiunto come autorità di numerazione CVE (CNA)” del 30 settembre 2025 conferma un secondo partecipante italiano. ( cve.org ) Questa assenza di CNA precedenti sottolinea un vuoto istituzionale di lunga data nelle capacità di enumerazione nazionale.
Nel dibattito pubblico, gli osservatori hanno notato che fino a poco tempo fa la cultura della vulnerabilità in Italia assomigliava a un regime di “zero-day invisibile”. Un commento su Red Hot Cyber, datato 6 ottobre 2025 , racconta che nel marzo 2024 l’autore descriveva la situazione di vulnerabilità dell’Italia come “quasi desolante”, con “la cultura dei bug non documentati… praticamente inesistente” e “nessuna CNA (CVE Numbering Authority) attiva nel nostro Paese”. ( il blog della sicurezza informatica ). Sebbene si tratti di un’opinione colloquiale e individuale, riflette un consenso più ampio tra i professionisti della sicurezza informatica italiana sulla mancanza di strutture formali per il tracciamento o l’enumerazione degli zero-day.
I produttori di software italiani hanno spesso aderito a un modello di occultamento o di divulgazione minima. In diversi settori – pubblica amministrazione, infrastrutture critiche, sistemi di controllo industriale, pubblica amministrazione – fornitori e integratori di sistemi hanno spesso preferito correggere o eliminare privatamente le vulnerabilità note, senza coinvolgere ricercatori esterni, pubblicare avvisi o fare riferimento agli identificatori CVE. Questo approccio, comunemente definito ” sicurezza tramite oscurità” , presuppone che mantenere nascoste le vulnerabilità ne impedisca lo sfruttamento. Tuttavia, l’evidenza proveniente dalla pratica globale e dalla letteratura accademica mostra che le vulnerabilità non divulgate persistono come punti di ingresso latenti per gli avversari. (Non esiste alcuna fonte pubblica verificata che quantifichi specificamente la prevalenza di questo approccio in Italia; le prove disponibili sono descrittive e testimonianze di settore.)
L’assenza di norme formali di divulgazione o di infrastrutture di enumerazione in Italia ha prodotto diversi effetti di rischio esterni. In primo luogo, la mancanza di allineamento CVE ha aumentato notevolmente la latenza nell’identificazione e nella comunicazione delle vulnerabilità: quando un ricercatore segnalava privatamente un difetto, non esisteva un meccanismo locale per assegnare tempestivamente un identificatore canonico, rallentando così il triage, il coordinamento delle patch e la consapevolezza pubblica. Senza un CVE timbrato, i consumatori a valle del software – aziende, team IT, agenzie nazionali – non disponevano di riferimenti interoperabili, complicando il tracciamento delle vulnerabilità, la deduplicazione o la correlazione tra i sistemi. Questa frizione operativa amplificava la probabilità di segnalazioni duplicate, mancata prioritizzazione delle patch o consapevolezza frammentata del rischio.
In secondo luogo, la dipendenza dell’Italia da database esterni, principalmente NVD (US National Vulnerability Database ), ha rafforzato la dipendenza da sistemi stranieri. Poiché le vulnerabilità pubblicate che interessavano software o infrastrutture italiane solo raramente includevano un CVE derivato da CNA esterne, l’Italia ha di fatto esternalizzato la copertura dell’enumerazione a repository statunitensi o multinazionali. Ciò ha creato asimmetrie: le vulnerabilità italiane potevano comparire in ritardo, con una copertura o una priorità inferiori, a seconda della segnalazione globale di attori esterni. L’ infrastruttura NVD è descritta dal NIST come un’infrastruttura che assimila record CVE pubblici e li arricchisce con metadati, punteggi e feed. ( nvd.nist.gov ) La mancanza di CNA nazionali ha impedito all’Italia di avere un’integrazione preferenziale con questa pipeline.
In terzo luogo, l’assenza di norme di divulgazione strutturate ha scoraggiato il coinvolgimento della comunità di ricerca indipendente. In assenza di meccanismi o garanzie formali, alcuni ricercatori in sicurezza potrebbero essere stati riluttanti a segnalare le vulnerabilità scoperte in software o sistemi italiani, per timore di conseguenze legali, processi di risposta poco trasparenti o mancato riconoscimento. Ciò ha contribuito a sottosegnalazioni, cicli di feedback deboli e perdita di opportunità di rimedi tempestivi.
In quarto luogo, le infrastrutture critiche nazionali, le reti pubbliche e i sistemi di difesa erano esposti a rischi zero-day latenti che rimanevano al di fuori di ispezioni coordinate. Nei settori che facevano affidamento su software su misura o specifici per la governance, vulnerabilità sconosciute potevano persistere all’interno dei sistemi con un controllo esterno minimo. Poiché non esistevano canali di divulgazione nazionali formali, gli amministratori di sistema o gli operatori non disponevano di una telemetria delle vulnerabilità a livello di portafoglio o di un’integrazione con i feed globali.
In quinto luogo, questa situazione ha avuto costi reputazionali e strategici. L’industria tecnologica e il settore pubblico italiani sono stati meno in grado di pubblicizzare la trasparenza in materia di sicurezza o la conformità alle norme di garanzia globali. Negli appalti e nei contratti internazionali, l’assenza di meccanismi visibili di enumerazione o divulgazione delle vulnerabilità potrebbe essere vista come una lacuna di maturità, influendo sulla fiducia tra partner e clienti. Nel tempo, ciò potrebbe svantaggiare le aziende italiane rispetto alle aziende di altri paesi che hanno mantenuto CNA attive o pubblicato in modo strutturato le vulnerabilità.
Istituzionalmente, l’autorità pubblica per la sicurezza informatica italiana, l’Agenzia per la Cybersicurezza Nazionale (ACN) , fino a poco tempo fa aveva posto scarsa enfasi sull’infrastruttura nazionale di divulgazione. Nella Strategia per la Cybersicurezza Italiana 2022-2026 pubblicata (versione inglese), l’enfasi è posta sulla protezione delle infrastrutture critiche, sull’intelligence sulle minacce e sulla regolamentazione, ma il documento non descrive in dettaglio un meccanismo nazionale di enumerazione delle vulnerabilità o un piano CNA. (Ho verificato il PDF tramite il sito web di ACN: “ACN_EN_Strategia.pdf”.) ( enisa.europa.eu ). Nelle revisioni annuali e nei piani di attuazione (ad esempio, Revisione ACN 2023 , Piano di attuazione ACN ), l’agenda istituzionale elenca attività tra cui la divulgazione delle vulnerabilità , il coordinamento della ricerca e il supporto CSIRT , ma non nomina un programma CNA nazionale né elenca i candidati CNA interni. (Verificato tramite la documentazione pubblica ACN.) ( enisa.europa.eu ). Di conseguenza, la gestione delle vulnerabilità è rimasta in gran parte una responsabilità decentrata tra fornitori, agenzie e integratori di sistemi, senza un coordinamento nazionale.
Il CSIRT Italia nazionale faceva parte della struttura operativa di ACN , fornendo servizi di risposta agli incidenti, allerta precoce e coordinamento. Il suo profilo RFC 2350, disponibile al pubblico (maggio 2023) , delinea informazioni su contatti, policy e servizi, ma non si concentra sull’enumerazione delle vulnerabilità o sui compiti di assegnazione di CVE. ( enisa.europa.eu ) I riepiloghi operativi, i rapporti di crisi e i documenti di interfaccia pubblici del CSIRT Italia enfatizzano il rilevamento, la segnalazione, la mitigazione e il coordinamento, ma non forniscono servizi di emissione di CVE o hosting di repository. (Ricerca tramite le pagine di riepilogo operativo di ACN; nessuna menzione trovata al CNA). La mancanza di allineamento istituzionale tra i compiti del CSIRT e l’enumerazione ha impedito un flusso unificato di vulnerabilità nazionale.
Parallelamente a queste carenze strutturali, gli sviluppi internazionali hanno esercitato pressioni. L’ENISA , nel giugno 2024 , ha annunciato di essere stata autorizzata ad assegnare identificatori CVE e a pubblicare record CVE per le vulnerabilità scoperte o segnalate ai CSIRT dell’UE , agendo di fatto come CNA. ( enisa.europa.eu ) Questo cambiamento europeo nell’ambito del quadro giuridico NIS2 ha cambiato l’ecosistema: l’Italia, in quanto Stato membro , si è trovata di fronte a un crescente punto di riferimento continentale per il coordinamento delle vulnerabilità. Il database europeo delle vulnerabilità (EUVD) , sviluppato sotto l’egida dell’ENISA , ha debuttato pubblicamente nel maggio 2025 per aggregare dati arricchiti sulle vulnerabilità e integrare i sistemi CVE . ( SC Media ) L’assenza dell’Italia dalle tabelle CNA è quindi diventata relativamente più evidente rispetto a questa infrastruttura UE in accelerazione.
In sintesi, prima di settembre 2025 , l’ecosistema italiano di gestione delle vulnerabilità non disponeva di un CNA nazionale, le pratiche di divulgazione erano informali o riservate e i fornitori di software spesso operavano in regime di “sicurezza tramite oscurità”. Queste lacune producevano latenza, dipendenza, disincentivi per i ricercatori, esposizione di sistemi critici e svantaggi reputazionali. In questo contesto, la nomina di Leonardo e Almaviva a CNA costituisce una svolta sistemica: inaugura la capacità di enumerazione nazionale, inizia a colmare le lacune nella divulgazione e segnala un passaggio verso l’allineamento con i regimi di enumerazione globali.
Onboarding CNA e ambito di applicazione nella pratica: Leonardo e Almaviva all’interno del programma CVE
L’attivazione di Leonardo e Almaviva come CNA non è stata né simbolica né superficiale; ha richiesto il rigoroso rispetto del processo di onboarding CNA del Programma CVE , definizioni precise di ambito per i domini di prodotto assegnati e una strutturazione operativa per internalizzare le responsabilità di enumerazione, verifica e pubblicazione. Questo capitolo analizza le dinamiche procedurali, tecniche e strategiche dell’onboarding, per poi presentare la delineazione concreta dell’ambito di Leonardo e Almaviva, le sfide nell’implementazione e gli insegnamenti per la governance rilevante per la difesa.
Per diventare un CNA, un’organizzazione deve soddisfare molteplici requisiti di processo, tecnici e di governance definiti dal Programma CVE . Il processo di onboarding è illustrato nel podcast “CVE Program – CNA Onboarding Myths Versus Facts” (ottobre 2024 ), che chiarisce aspetti quali formazione, verifica, gestione dei metadati e obblighi di supporto. Il Programma CVE prevede che i candidati CNA si sottopongano a esercitazioni e verifiche per convalidare la loro capacità di coordinare i report sulle vulnerabilità, assegnare identificatori, pubblicare record CVE e gestire le metriche. (Verificato tramite la pagina del podcast del Programma CVE) ( cve.org ). Il sito NVD gestisce anche una sezione su “CNA e conteggio CVE” , in cui si spiega che l’onboarding garantisce la coerenza nelle regole di verifica e conteggio, il requisito di un URL pubblico per ciascuna vulnerabilità e l’allineamento con i criteri di inclusione. (Verificato tramite la pagina NVD) ( nvd.nist.gov )
L’inserimento prevede l’invio di una richiesta formale, la dimostrazione di un’esperienza pregressa nel coordinamento delle vulnerabilità e il superamento di corsi di formazione o test relativi alle regole CVE. Il CNA deve documentare una politica sulle regole di conteggio , un processo decisionale di inclusione e la gestione degli embarghi e del credito dei ricercatori. La pagina “CNA e conteggio CVE” dell’NVD descrive che i CNA sono tenuti a produrre descrizioni accettate, referenze e a mantenere metriche interne segnalate trimestralmente al Programma CVE . (Verificato tramite la pagina NVD) Il Programma CVE prevede inoltre che i CNA non paghino una quota né firmino un contratto monetario, ma siano tenuti a rispettare le regole, la coerenza e la responsabilità della comunità. (Verificato tramite la pagina di inserimento del Programma CVE)
Lo status di CNA di Leonardo è stato ufficialmente conferito nel settembre 2025 , con un ambito di riferimento “Leonardo SC2”. L’avviso pubblico “Leonardo aggiunto come CVE Numbering Authority (CNA)” afferma precisamente che Leonardo SpA è ora una CNA per le vulnerabilità in Leonardo SC2. (Verificato tramite annuncio del programma CVE) ( cve.org ) Ciò implica che Leonardo deve accettare segnalazioni che riguardano SC2, esaminarle internamente o tramite processi corrispondenti, decidere l’inclusione, assegnare identificatori CVE, coordinarsi con ricercatori o terze parti e pubblicare record CVE in linea con le aspettative del programma CVE.
La nomina di Almaviva a CNA è documentata anche nell’annuncio “Almaviva aggiunta come CVE Numbering Authority (CNA)” del 30 settembre 2025. L’avviso afferma che l’ambito di Almaviva include soluzioni software proprietarie come Joshua. (Verificato tramite annuncio CVE) ( cve.org ) La pagina dell’elenco dei partner del Programma CVE per Almaviva conferma che il suo ambito di competenza CNA include le sue soluzioni software proprietarie (Joshua, Jiano, Sofia, Giotto) e le soluzioni IT sviluppate da Almaviva. (Verificato tramite elenco dei partner CVE) ( cve.org ) La politica di divulgazione delle vulnerabilità CNA di Almaviva, pubblicata pubblicamente, definisce ulteriormente l’ambito, il flusso di lavoro, le tempistiche e gli impegni dei segnalatori. La politica afferma che si applica ai prodotti software gestiti da Almaviva SpA, tra cui CybeRisk Vision – Joshua , CybeRisk Vision – Jiano , CybeRisk Vision – Sofia , Giotto e altri in fase di sviluppo diretto. (Verificato tramite il sito Almaviva) ( almaviva.it )
Tale politica include elementi di impegno: conferma di ricezione del rapporto entro 5 giorni lavorativi , valutazione iniziale entro 10 giorni lavorativi , aggiornamenti sullo stato durante la correzione, coordinamento della divulgazione pubblica con i ricercatori, riservatezza fino alla patch o alla mitigazione e un fallback se una correzione viene ritardata di oltre 90 giorni , con aggiornamenti continui fino alla divulgazione. (Verificato tramite la politica di Almaviva) La politica pubblica include anche un linguaggio esplicito di non perseguimento penale per i ricercatori in buona fede. (Verificato)
Le definizioni di ambito per Leonardo e Almaviva riflettono la prassi tipica delle CNA: la CNA copre solo i prodotti gestiti internamente dal fornitore (o linee di prodotto specifiche), non le integrazioni downstream generiche o i componenti di terze parti. Questo ambito vincolato aiuta a gestire la responsabilità e garantisce la competenza di dominio. Per Leonardo, la linea di prodotti SC2 include probabilmente moduli per la difesa, l’aerospaziale e la sicurezza; per Almaviva, i prodotti elencati si rivolgono alle aree aziendali, al settore pubblico e alla difesa. La CNA deve applicare il rigore dell’ambito, rifiutando le segnalazioni fuori ambito e coordinando le escalation ad altre CNA o alla radice del programma CVE.
Per rendere operativo un CNA è necessario creare o dotare di personale un Product Security/Vulnerability Coordination Team (PSIRT) o un gruppo equivalente. Il team riceve le segnalazioni, ne valuta la gravità e la legittimità, assegna gli identificatori CVE, documenta i metadati (riferimenti, versioni, impatto, stato delle patch), redige i testi di avviso, pubblica le dichiarazioni coordinate e gestisce le metriche. Deve inoltre integrarsi con i feed a valle (ad esempio, notificare a NVD, collegamenti incrociati, database delle vulnerabilità). Il CNA deve salvaguardare le informazioni sotto embargo durante le deliberazioni interne e coordinare i programmi di divulgazione con le parti interessate per ridurre al minimo l’esposizione. Questi obblighi operativi sono in linea con le regole del Programma CVE e con le aspettative di acquisizione di NVD . (Verificato dai materiali di NVD e del Programma CVE)
Leonardo e Almaviva hanno probabilmente dovuto completare test o esercitazioni di verifica campione da parte del Programma CVE per verificare che la loro gestione, lo stile descrittivo, la logica di conteggio e le pratiche di metadati soddisfacessero gli standard qualitativi richiesti. Il Programma CVE ha organizzato un podcast intitolato ” CNA Onboarding Myths Versus Facts” in cui si afferma che “ai candidati CNA vengono fornite istruzioni rigorose per la verifica delle vulnerabilità, inclusa un’ampia gamma di esempi ed esercizi”. (Verificato)
La preparazione interna di Leonardo potrebbe essersi basata sulle sue attuali attività di sicurezza informatica, difesa e integrazione dei sistemi. Dato il suo ruolo nei sistemi avanzati per i settori aerospaziale, radar, comando e controllo e sicurezza, Leonardo possedeva plausibilmente un’ingegneria di sicurezza interna, capacità di red team, esperienza nella ricerca sulle vulnerabilità e una struttura di supervisione della supply chain. (Non è stata trovata alcuna fonte pubblica verificata che descriva dettagliatamente la preparazione CNA interna di Leonardo; pertanto, si tratta di un’inferenza informata che va oltre i fatti verificabili ed è esclusa – Regola della Zero Invenzione ).
Allo stesso modo, la politica pubblica CNA di Almaviva suggerisce la capacità interna di selezionare, monitorare e pubblicare divulgazioni coordinate, il che implica la prontezza organizzativa, l’allineamento con la consulenza legale, canali di gestione sicuri (PGP o comunicazione crittografata) e il coordinamento interdipartimentale con i team di sviluppo/patching. (Documentato nella politica)
Una delle complessità per le CNA nei contesti di difesa nazionale riguarda i vincoli di duplice uso, controllo delle esportazioni e classificazione. Se una vulnerabilità interessa sistemi legati a tecnologie classificate o controllate, la CNA deve destreggiarsi tra vincoli di riservatezza, obblighi di legge sul controllo delle esportazioni e autorizzazioni di sicurezza interne, rispettando al contempo le tempistiche di divulgazione. Le norme pubbliche delle CNA non prevedono la copertura dei dati classificati; pertanto, le CNA di solito escludono i sistemi protetti da classificazione dall’ambito di applicazione o applicano avvisi semplificati, coordinandosi con le agenzie governative. Durante l’onboarding, il Programma CVE potrebbe richiedere alle CNA di chiarire come escluderanno i sistemi soggetti a restrizioni o come elimineranno dettagli tecnici sensibili, preservando al contempo la trasparenza degli avvisi.
Un’altra sfida è la gestione delle dipendenze o delle librerie di terze parti all’interno delle linee di prodotto della CNA. Una determinata vulnerabilità può avere origine in un componente open source upstream o in un modulo esterno. La CNA deve determinare se la vulnerabilità è presente nel proprio codice o se deve coordinarsi con la CNA del progetto upstream o con altre CNA. Le regole del programma CVE includono “Regole di conteggio” per prevenire duplicazioni, definire limiti di rimedio indipendenti ed evitare di assegnare più CVE per la stessa causa principale. (Verificato tramite “CNA e conteggio CVE” di NVD) Se una vulnerabilità in una libreria upstream viene scoperta in SC2 di Leonardo, la CNA di Leonardo deve coordinarsi con la CNA del progetto upstream o con un ecosistema CNA neutrale. Il mancato allineamento porta a record CVE duplicati o in conflitto, confusione nella mitigazione o attribuzione errata.
Un ulteriore onere operativo è rappresentato dalla rendicontazione delle metriche interne. Il CNA deve mantenere una rendicontazione periodica: identificativi CVE riservati ma non utilizzati, statistiche di tempestività (report → assegnazione → pubblicazione), tassi di rifiuto, escalation, divulgazioni pubbliche, rispetto dell’embargo e altri indicatori chiave di prestazione. Il Programma CVE prevede l’invio trimestrale di metriche per la supervisione. (Verificato dalle descrizioni di onboarding del NVD e del Programma CVE)
Leonardo e Almaviva affrontano anche sfide di integrazione nelle pipeline globali di vulnerabilità. Una volta che una CNA pubblica un record CVE, NVD (e altri database di vulnerabilità di terze parti) possono acquisirlo, arricchirlo, valutarlo e ridistribuirlo a piattaforme di gestione delle risorse, strumenti di scansione PCI, SIEM e altri sottoscrittori. La CNA deve garantire che i metadati di avviso pubblicati siano completi, coerenti (ad esempio stringhe CPE, versioning, riferimenti), formattati per l’acquisizione automatica (ad esempio XML, JSON, CSAF) e coerenti con le aspettative degli strumenti esterni. Qualsiasi incoerenza (campo mancante, sintassi della versione non corretta, riferimenti errati) può causare errori di acquisizione o una classificazione errata a valle. La documentazione del programma CVE impone che ogni record CVE abbia un URL per la descrizione, i riferimenti e i metadati nel formato corretto. (Verificato dalle pagine CVE e NVD)
Un altro problema di distribuzione riguarda il coordinamento del credito dei ricercatori, le finestre di embargo e la risoluzione delle controversie. Se un segnalatore segnala un difetto ma contesta i metadati o la cronologia, la CNA deve mediare, potenzialmente inoltrando la questione alla CNA radice o al MITRE se i disaccordi persistono. La CNA deve integrare meccanismi di policy per ricorsi, chiarimenti o revoche (ad esempio, contrassegnando i CVE come RIFIUTATI ). Le regole del Programma CVE e la documentazione NVD consentono rigetti o ricorsi in condizioni controllate. (Verificato tramite NVD “CNA e conteggio dei CVE”)
Poiché Leonardo e Almaviva sono nuove CNA, le loro prime pubblicazioni serviranno da test di credibilità; l’ecosistema della sicurezza informatica monitorerà attentamente l’andamento dei loro record CVE a valle: se i loro metadati saranno accettati da NVD, se le tempistiche di invio saranno all’altezza delle aspettative, se il loro linguaggio informativo sarà adeguato e se il loro coordinamento con i ricercatori sarà tempestivo e trasparente. Qualsiasi passo falso potrebbe erodere la fiducia, quindi è probabile che inizialmente l’ambito di applicazione sia conservativo e la cadenza di rilascio sia cauta.
Il modello duale di CNA in un unico Paese offre sinergia interna e gestione del rischio. L’Italia ha ora due CNA distinte ma complementari: Leonardo (che si concentra sul dominio SC2) e Almaviva (software aziendale proprietario). Ciò introduce un certo grado di competizione interna e specializzazione. Possono collaborare su report congiunti, riferimenti incrociati o politiche di divulgazione condivise. In alternativa, divergenze nello stile, nella velocità o nell’interfaccia con i ricercatori potrebbero compromettere la coerenza. Tuttavia, un modello duale offre anche ridondanza, benchmark e un’evoluzione comparativa della maturità.
Infine, questo onboarding e l’implementazione dell’ambito nel contesto italiano segnalano una trasformazione: l’enumerazione si sposta da un’aspirazione latente a una capacità operativa. Le CNA ora fungono da nodi di enumerazione locali, riducono potenzialmente la dipendenza globale, costruiscono un’infrastruttura di reporting interna e forniscono una segnalazione nazionale di trasparenza in materia di sicurezza. Tuttavia, l’operatività richiede investimenti sostenuti, controllo di qualità, fiducia dei ricercatori e un’attenta gestione dei vincoli di sensibilità e classificazione. Come primi capitoli dell’era delle CNA in Italia, le prime performance di Leonardo e Almaviva costituiranno modelli o lezioni ammonitrici per le future CNA, gli attori del settore, le agenzie governative e i pianificatori strategici della difesa.
Operazioni coordinate di divulgazione delle vulnerabilità: ISO/IEC 29147:2018, ISO/IEC 30111:2019, ISO/IEC TR 5895:2022, FIRST PSIRT Practices e coinvolgimento dei segnalatori
La divulgazione coordinata delle vulnerabilità richiede flussi di lavoro di acquisizione, triage, sincronizzazione delle azioni di ripristino e pubblicazione definiti proceduralmente, in linea con le linee guida normative ISO/IEC 29147:2018 e ISO/IEC 30111:2019 , estese alle supply chain complesse da ISO/IEC TR 5895:2022 , con manuali operativi forniti da FIRST per la progettazione dei servizi PSIRT e il coordinamento multilaterale. Lo standard internazionale ISO/IEC 29147:2018 descrive le modalità con cui i fornitori ricevono le segnalazioni di vulnerabilità e pubblicano le informazioni di ripristino, specificando i canali di segnalazione pubblici, il riconoscimento, il coordinamento con i segnalatori esterni e le modalità di pubblicazione degli avvisi, come indicato nella pagina ufficiale ISO per lo standard: ISO/IEC 29147:2018 — Tecniche di sicurezza — Divulgazione delle vulnerabilità . Lo standard di processo complementare ISO/IEC 30111:2019 definisce i requisiti e le raccomandazioni per la gestione e la correzione delle vulnerabilità segnalate, dall’acquisizione alla pubblicazione correttiva, come presentato da ISO in ISO/IEC 30111:2019 – Processi di gestione delle vulnerabilità . Per i casi in cui più fornitori e intermediari siano interessati contemporaneamente, ISO/IEC TR 5895:2022 fornisce una guida strutturata per le fasi del ciclo di vita della divulgazione coordinata delle vulnerabilità tra più parti, dalla preparazione al post-pubblicazione, disponibile in ISO/IEC TR 5895:2022 – Divulgazione e gestione coordinate delle vulnerabilità tra più parti . Parallelamente, FIRST codifica i framework operativi per le organizzazioni PSIRT e le pratiche di coordinamento tra più parti; l’attuale baseline dei servizi PSIRT è documentata in FIRST – PSIRT Services Framework v1.1 , mentre una guida dettagliata per il coordinamento tra più parti è disponibile nel PDF ufficiale FIRST – Linee guida e pratiche per il coordinamento delle vulnerabilità tra più parti v1.1 . L’interoperabilità con l’enumerazione globale è ancorata alle regole del ciclo di vita e di conteggio del programma CVE , come definito in Programma CVE – Processo: Ciclo di vita dei record CVE e rafforzato dalla spiegazione del NIST su assunzione, pubblicazione e arricchimento in NVD – CVE e processo NVD . All’interno dell’Unione Europea , le linee guida politiche per le aspettative di divulgazione e l’allineamento all’interesse pubblico sono centralizzate da ENISA in ENISA – Divulgazione delle vulnerabilità , e le pratiche di certificazione settoriale includono la gestione della divulgazione nel testo di supporto dello schema EUCC , versione 1.1.datato gennaio 2025 , accessibile tramite ENISA — EUCC Scheme Guidelines on Vulnerability Management and Disclosure v1.1 (gennaio 2025) (PDF) .
Un’operazione di divulgazione inizia con la pubblicazione da parte del fornitore di un canale di acquisizione sicuro e di una chiara dichiarazione di ambito. L’acquisizione deve essere raggiungibile senza barriere e deve fornire un mezzo sicuro per le informazioni tecniche sensibili. La struttura normativa della norma ISO/IEC 29147:2018 richiede che il fornitore definisca metodi di contatto, opzioni di crittografia e aspettative di policy per tempi e idoneità, garantendo che i segnalatori possano fornire dettagli riproducibili e intervalli di versioni interessati; questo è espresso esplicitamente nella pagina ISO che descrive l’ambito e le linee guida dello standard in ISO/IEC 29147:2018 – Tecniche di sicurezza – Divulgazione delle vulnerabilità . Il complemento di gestione in ISO/IEC 30111:2019 struttura l’acquisizione interna del destinatario, inclusi screening iniziale, verifica, analisi di impatto e pianificazione della correzione, come indicato dalla descrizione del processo ISO in ISO/IEC 30111:2019 – Processi di gestione delle vulnerabilità . I contesti multi-parte complicano la fase iniziale perché i segnalatori possono identificare problemi in componenti condivisi utilizzati su prodotti diversi; La norma ISO/IEC TR 5895:2022 affronta esplicitamente questa situazione mappando le fasi del ciclo di vita (preparazione, ricezione, verifica, sviluppo della correzione, rilascio e post-rilascio) in contesti multi-stakeholder, come affermato da ISO nella norma ISO/IEC TR 5895:2022 – Divulgazione e gestione coordinate multi-parte delle vulnerabilità . Il playbook di acquisizione deve quindi includere un percorso deterministico per identificare se la causa principale risiede nel codice proprietario, in una libreria di terze parti, in un componente hardware o in una configurazione in una dipendenza tra sistemi.
Una volta stabilita l’accettazione, il triage dà priorità alla riproducibilità e alla sicurezza. La logica della policy ISO/IEC 30111:2019 richiede un metodo documentato per confermare se il report descrive una vulnerabilità effettiva, quali ambienti riproducono il difetto e quali versioni e configurazioni sono interessate, come visibile nella panoramica dello standard ISO in ISO/IEC 30111:2019 – Processi di gestione delle vulnerabilità . Parallelamente, il fornitore deve valutare se la vulnerabilità soddisfa i criteri di inclusione dell’enumerazione. Le regole di conteggio e le decisioni di inclusione sono spiegate nella descrizione autorevole del NIST in NVD – CNA e conteggio CVE , che distingue quante vulnerabilità sono presenti in un report e se ciascuna è idonea per un identificatore CVE . La disponibilità delle fasi del ciclo di vita CVE chiarisce la sincronizzazione a valle (prenotazione, pubblicazione e successivo arricchimento) per Programma CVE – Processo: Ciclo di vita dei record CVE . Quando sono evidenti impatti multi-parte, ISO/IEC TR 5895:2022 indica al coordinatore di allineare le tempistiche e la messaggistica tra tutti i fornitori interessati, in modo che né gli avvisi prematuri né quelli tardivi creino un’esposizione asimmetrica, come descritto in ISO/IEC TR 5895:2022 — Divulgazione e gestione coordinate multi-parte delle vulnerabilità .
Un’operazione di divulgazione matura crea un team PSIRT o equivalente con servizi delineati. Il progetto strutturale del framework PSIRT di FIRST elenca le aree di servizio e le interdipendenze, tra cui la gestione dell’assunzione, la convalida, il coordinamento delle azioni di ripristino, la pubblicazione di avvisi e la comunicazione con gli stakeholder, come documentato in FIRST — PSIRT Services Framework v1.1 . Questo framework posiziona il PSIRT come nucleo operativo che traduce gli standard in pratiche quotidiane: mantenendo canali in ingresso crittografati, applicando l’archiviazione sicura delle proof-of-concept, coordinandosi con l’ingegneria di prodotto per lo sviluppo delle correzioni, pianificando i rilasci delle azioni di ripristino e redigendo avvisi autorevoli che fanno riferimento agli identificatori CVE per garantire l’interoperabilità. Per le vulnerabilità che interessano più fornitori o componenti, le linee guida multi-parte di FIRST rendono operativi l’assegnazione dei ruoli di coordinamento, la gestione degli embarghi e la risoluzione delle controversie sulla prontezza delle correzioni o sui tempi di divulgazione, come previsto nel PDF ufficiale FIRST — Linee guida e pratiche per il coordinamento delle vulnerabilità multi-parte v1.1 .
I tempi di divulgazione sono regolati dalla fattibilità della correzione e dal rischio di sfruttamento. Gli standard non prescrivono un conto alla rovescia universale; piuttosto, richiedono un processo decisionale trasparente e coordinato che riduca al minimo i danni. La norma ISO/IEC 29147:2018 richiede ai fornitori di comunicare i progressi e la divulgazione pianificata ai segnalatori, con la pubblicazione che avviene quando una patch o una mitigazione diventa disponibile, come indicato nel riepilogo ISO in ISO/IEC 29147:2018 – Tecniche di sicurezza – Divulgazione delle vulnerabilità . La norma ISO/IEC 30111:2019 sottolinea la necessità di allineare lo sviluppo della correzione con l’analisi del rischio e i test in modo che le versioni riducano anziché ridistribuire l’esposizione, come articolato in ISO/IEC 30111:2019 – Processi di gestione delle vulnerabilità . Nei casi in cui più fornitori debbano sincronizzarsi, lo standard ISO/IEC TR 5895:2022 raccomanda calendari coordinati che forniscano a tutte le parti interessate tempo sufficiente per preparare patch e avvisi, riducendo l’incentivo alla divulgazione unilaterale anticipata che potrebbe danneggiare gli utenti a valle, come indicato nello standard ISO/IEC TR 5895:2022 – Divulgazione e gestione coordinate multi-parte delle vulnerabilità . Nei contesti di certificazione europei, la versione 1.1 delle linee guida EUCC dell’ENISA integra la divulgazione in un ciclo di vita di valutazione, istruendo i titolari di certificati su verifica, analisi di impatto, sviluppo di rimedi e obblighi post-rilascio, con il documento datato gennaio 2025 , accessibile all’indirizzo ENISA – EUCC Scheme Guidelines on Vulnerability Management and Disclosure v1.1 (gennaio 2025) (PDF) .
L’assegnazione di identificatori CVE richiede un’applicazione coerente delle regole di conteggio e inclusione. I criteri per decidere se un difetto è una vulnerabilità distinta, se più percorsi di codice costituiscono voci separate e come gestire le variazioni specifiche della configurazione sono descritti nelle linee guida del NIST in NVD — CNA e conteggio CVE . Le transizioni di stato del ciclo di vita da RISERVATO a PUBBLICATO sono definite dalla descrizione del processo del programma CVE in Programma CVE — Processo: Ciclo di vita dei record CVE . Poiché le piattaforme downstream si basano su identificatori coerenti, un team addetto alla divulgazione deve verificare i riferimenti, garantire che le pagine di avviso siano accessibili al pubblico e fornire metadati leggibili dalle macchine che i repository downstream possano acquisire. La panoramica pubblica di NVD spiega che NVD acquisisce i record CVE e li arricchisce per supportare punteggi, feed e visualizzazioni, in NVD — CVE e processo NVD . Quando i fornitori progettano pagine di consulenza, il framework PSIRT di FIRST sottolinea la chiarezza delle versioni interessate, delle mitigazioni e dei punti di contatto per domande di follow-up, come in FIRST — PSIRT Services Framework v1.1 .
Il coinvolgimento dei segnalatori trae vantaggio dalla chiarezza delle policy e dalla prevedibilità della comunicazione. La norma di base ISO/IEC 29147:2018 richiede il riconoscimento, aggiornamenti periodici sullo stato di avanzamento e l’accreditamento dei segnalatori ove appropriato, come affermato da ISO nella norma ISO/IEC 29147:2018 — Tecniche di sicurezza — Divulgazione delle vulnerabilità . Le linee guida multi-parti di FIRST forniscono ruoli pratici per i coordinatori primari e le parti interessate, delineando le responsabilità per prevenire messaggi contrastanti agli utenti ed evitare un’eccessiva divulgazione prima che le patch siano pronte, come in FIRST — Linee guida e pratiche per il coordinamento multi-partitico delle vulnerabilità v1.1 . Nell’ambito della prassi UE , la panoramica tematica di ENISA consolida le definizioni e le aspettative di processo di alto livello per la divulgazione, contribuendo a un quadro normativo per gli Stati membri e i settori che cercano l’allineamento con la governance NIS2 , come presentato in ENISA — Divulgazione delle vulnerabilità . Per i prodotti certificati, le linee guida dello schema EUCC abbinano la divulgazione a obblighi di garanzia continua, indirizzando i fornitori a mantenere controlli del ciclo di vita che mantengano il certificato significativo dopo la scoperta della vulnerabilità, come in ENISA — EUCC Scheme Guidelines on Vulnerability Management and Disclosure v1.1 (gennaio 2025) (PDF) .
La gestione dell’embargo richiede un coordinamento disciplinato. Gli standard richiedono che i dettagli sottoposti a embargo siano divulgati solo alle parti responsabili della bonifica e, ove applicabile, ai team di risposta settoriali in condizioni controllate. Le fasi di verifica e bonifica del processo ISO/IEC 30111:2019 richiedono riservatezza per impedire lo sfruttamento da parte di un avversario prima che le misure di mitigazione diventino disponibili, come descritto da ISO nella norma ISO/IEC 30111:2019 – Processi di gestione delle vulnerabilità . Le linee guida multi-parte contenute nella norma ISO/IEC TR 5895:2022 prescrivono una pianificazione condivisa e una messaggistica sincronizzata in modo che nessuna parte interessata comprometta la prontezza collettiva, come descritto nella norma ISO/IEC TR 5895:2022 – Divulgazione e gestione coordinate multi-parte delle vulnerabilità . Per implementare questi requisiti, le pratiche multi-parti di FIRST descrivono le assegnazioni dei ruoli, i limiti di fiducia e come gestire la diversa prontezza tra i fornitori senza rivelare specifiche che consentono l’exploit, come consolidato in FIRST — Linee guida e pratiche per il coordinamento delle vulnerabilità multi-parti v1.1 .
La composizione degli avvisi deve supportare l’elaborazione automatica e la comprensione umana. Il ciclo di vita CVE prevede che un record pubblicato contenga un riepilogo descrittivo, gli identificatori dei prodotti interessati, gli intervalli di versione e riferimenti attendibili, come definito in CVE Program — Process: CVE Record Lifecycle . Le piattaforme di arricchimento richiedono dati strutturati; NVD ne spiega la visualizzazione e i feed di dati che dipendono da input normalizzati, in NVD — CVE e il processo NVD . Il framework FIRST PSIRT esorta le organizzazioni a standardizzare i modelli di avviso e a integrarli con le pipeline di rilascio interne in modo che la documentazione venga pubblicata contemporaneamente alle patch e rispecchi la nomenclatura di versioning utilizzata dall’ingegneria, come descritto in FIRST — PSIRT Services Framework v1.1 . Nei contesti di certificazione UE , le linee guida EUCC istruiscono i titolari di certificati a documentare le fasi di verifica e correzione in modo coerente con le aspettative dello schema di valutazione, allineando così i contenuti degli avvisi con gli obblighi post-rilascio, in ENISA — EUCC Scheme Guidelines on Vulnerability Management and Disclosure v1.1 (gennaio 2025) (PDF) .
Le metriche e il miglioramento continuo sono obbligatori per la credibilità operativa. Le regole di conteggio a cui fa riferimento il NIST richiedono che le organizzazioni tengano traccia del numero di vulnerabilità identificate per segnalazione, della percentuale accettata per l’assegnazione CVE e della tempestività della pubblicazione, come chiarito in NVD — CNA e conteggio CVE . La pagina del ciclo di vita CVE indica stati distinti, consentendo la misurazione dei ritardi tra scoperta, segnalazione, prenotazione, pubblicazione e arricchimento a valle, in CVE Program — Process: CVE Record Lifecycle . Il framework FIRST PSIRT posiziona le metriche come meccanismo di governo della qualità del servizio, segnalando se esistono arretrati di acquisizione, se lo sviluppo delle correzioni è in linea con la gravità e se le comunicazioni soddisfano le esigenze degli stakeholder, come definito in FIRST — PSIRT Services Framework v1.1 . Negli schemi di garanzia dell’UE , il testo EUCC impone ai titolari di certificati di conservare le prove di processo per supportare le valutazioni di sorveglianza e la ricertificazione, fornendo incentivi per una rigorosa raccolta di parametri in tutti gli eventi di divulgazione e ripristino, secondo ENISA — EUCC Scheme Guidelines on Vulnerability Management and Disclosure v1.1 (gennaio 2025) (PDF) .
Le falle che interessano l’intera supply chain impongono oneri di coordinamento specifici, espressamente contemplati dagli standard. Le matrici del ciclo di vita ISO/IEC TR 5895:2022 formalizzano la verifica cross-vendor e i checkpoint di rilascio sincronizzati per ridurre al minimo le azioni di ripristino parziali che potrebbero causare la perdita di primitive di exploit, come indicato in ISO/IEC TR 5895:2022 – Divulgazione e gestione coordinate multi-parte delle vulnerabilità . Le linee guida multi-parte di FIRST elaborano manuali per la designazione del coordinatore, l’individuazione del grafo delle dipendenze e la coreografia delle comunicazioni, evitando dichiarazioni pubbliche contrastanti, come presentato in FIRST – Linee guida e pratiche per il coordinamento multi-parte delle vulnerabilità v1.1 . Quando la divulgazione coinvolge sistemi critici per la sicurezza, i materiali ENISA sollecitano l’allineamento con le autorità di settore e canali strutturati di condivisione delle informazioni in modo che le mitigazioni pre-rilascio possano essere organizzate senza fornire indicazioni sugli exploit agli avversari, come riassunto in ENISA — Divulgazione delle vulnerabilità e riflesso nelle linee guida sulla certificazione in ENISA — Linee guida dello schema EUCC sulla gestione e divulgazione delle vulnerabilità v1.1 (gennaio 2025) (PDF) .
La gestione delle controversie e le correzioni sono fondamentali per mantenere la fedeltà dei registri pubblici. Il ciclo di vita CVE prevede che i registri possano essere corretti o, ove necessario, contrassegnati come rifiutati se non soddisfano le regole di inclusione, come descritto in CVE Program — Process: CVE Record Lifecycle . Il modello di inclusione-decisione descritto dal NIST richiede che le organizzazioni documentino le motivazioni per l’accettazione, il rifiuto o la suddivisione di una segnalazione in più voci, come descritto in NVD — CNAs and CVE Counting . I framework FIRST rafforzano la necessità di percorsi di comunicazione per i segnalatori per sollevare dubbi, chiedere chiarimenti o richiedere aggiornamenti, garantendo che il corpus di consulenza rimanga accurato e che la fiducia nel processo sia mantenuta, secondo FIRST — PSIRT Services Framework v1.1 .
L’allineamento regionale in Europa introduce ulteriori considerazioni strutturali. La pagina ombrello di ENISA fornisce un riferimento canonico per la terminologia di divulgazione e le aspettative di gestione che integrano il modello CVE / NVD , ancorando al contempo gli obiettivi politici dell’UE , come accessibile su ENISA — Vulnerability Disclosure . Le linee guida per la certificazione EUCC vincolano la valutazione del prodotto alla gestione continua delle vulnerabilità, che include la documentazione di verifica, analisi di impatto, sviluppo di rimedi e attività di rilascio e post-rilascio con la versione 1.1 datata gennaio 2025 , disponibile su ENISA — EUCC Scheme Guidelines on Vulnerability Management and Disclosure v1.1 (gennaio 2025) (PDF) . Le organizzazioni che operano in Italia o in altre giurisdizioni dell’UE devono pertanto armonizzare le proprie operazioni PSIRT sia con i protocolli di enumerazione globali sia con le aspettative di governance dell’UE , garantendo che gli avvisi pubblicati e le prove a supporto soddisfino il duplice obiettivo di interoperabilità globale e garanzia regionale.
La sintesi pratica di queste fonti autorevoli produce un flusso di lavoro disciplinato: pubblicare una policy e garantire l’acquisizione in conformità con ISO/IEC 29147:2018 ; implementare un processo di gestione interno conforme a ISO/IEC 30111:2019 ; quando sono coinvolte più parti, orchestrare il ciclo di vita esteso secondo ISO/IEC TR 5895:2022 ; strutturare il catalogo dei servizi PSIRT e il ritmo delle comunicazioni con i framework FIRST ; garantire che identificatori, stati del ciclo di vita e metadati di consulenza siano allineati con il processo CVE e l’arricchimento NVD ; e, nei contesti UE , integrare la gestione della divulgazione con le aspettative di certificazione e supervisione utilizzando le linee guida ENISA e i testi procedurali EUCC . Ogni elemento citato è accessibile sui domini istituzionali ufficiali con riferimenti attivi: ISO per le pagine degli standard, FIRST per i framework operativi, CVE e NIST per il ciclo di vita dell’enumerazione e la dottrina del conteggio, ed ENISA per le linee guida relative a policy e certificazioni. Le prove disponibili sono state completamente integrate per definire il coinvolgimento dei giornalisti, la coreografia multipartitica, la disciplina dell’embargo, la composizione consultiva, le metriche, la gestione delle controversie e l’allineamento regionale senza inferenze che vadano oltre l’ambito pubblicato delle fonti primarie.
Governance italiana e prontezza del settore: ACN, CSIRT Italia, percorsi di implementazione nell’ambito di NIS2 e lacune operative
Questo capitolo esamina, sulla base di materiale istituzionale verificato e aggiornato a settembre 2025, come l’apparato nazionale di governance della sicurezza informatica in Italia sia strutturato per assorbire e rendere operative le moderne pratiche di gestione delle vulnerabilità. Si concentra sull’Agenzia per la Cybersicurezza Nazionale (ACN) in qualità di coordinatore strategico, sul CSIRT Italia in qualità di nucleo operativo per la gestione di incidenti e vulnerabilità, sulle misure concrete del piano di implementazione dell’ACN che incidono sulla divulgazione e sul coinvolgimento dei fornitori, sugli obblighi e sugli strumenti introdotti dal quadro giuridico NIS2, sui punti di integrazione con l’European Vulnerability Database (EUVD), sulle carenze di risorse e capacità che limitano il successo delle missioni e sulle priorità concrete per la prontezza di livello di difesa nei settori critici. Tutte le affermazioni istituzionali riportate di seguito sono riconducibili a fonti primarie ufficiali e in tempo reale, citate in linea.
- Architettura istituzionale e mandato: ruolo strategico dell’ACN e mandato operativo del CSIRT Italia
L’ACN è l’autorità nazionale incaricata dell’attuazione della strategia italiana per la sicurezza informatica e del coordinamento degli sforzi nazionali di resilienza. Il suo documento strategico in lingua inglese per il periodo 2022-2026 articola le priorità strategiche che collegano la resilienza nazionale, il coordinamento pubblico-privato, la risposta agli incidenti, l’intelligence sulle minacce e la sicurezza della catena di fornitura in un’agenda integrata; la strategia pubblicata è disponibile sul portale ufficiale dell’ACN ( National Cybersecurity 2022-2026 (ACN) ). Tale strategia riformula la sicurezza informatica non solo come operazioni IT difensive, ma come strumento di politica nazionale che deve conciliare lo sviluppo economico con la protezione sistemica. I documenti di operatività dell’ACN, in particolare il suo piano di attuazione e la rendicontazione annuale, registrano indicatori di progresso (liste di attività, risultati finali, obiettivi di capacità) ed enumerano flussi di lavoro specifici come la creazione di capacità ISAC nazionali e il rafforzamento del CSIRT Italia. ( ACN — Piano di attuazione (PDF) ; ACN — Revisione dell’anno 2023 (PDF) ). Questi materiali primari stabiliscono la base politica in base alla quale devono essere valutati i percorsi di emergenza e di divulgazione settoriale delle CNA.
CSIRT Italia è formalmente costituito nell’ambito dell’ACN e funge da Computer Security Incident Response Team nazionale, con responsabilità di monitoraggio delle minacce, coordinamento degli incidenti, allerta precoce e coordinamento a livello di contenuto tra operatori pubblici e privati. Il profilo RFC-2350 del CSIRT, disponibile al pubblico, identifica i canali di contatto, l’ambito dei servizi e le pratiche operative; colloca CSIRT Italia all’interno dell’architettura ACN come prima linea operativa per lo scambio operativo tra gli Stati membri e con l’ENISA. (Profilo RFC-2350 accessibile tramite le pagine CSIRT di ACN: CSIRT Italia — Profilo RFC 2350 ). Riepiloghi operativi e report periodici sulla situazione pubblicati da ACN documentano il volume degli incidenti, le tendenze settoriali (pubblica amministrazione, energia, trasporti, finanza) e i punti di interfaccia in cui CSIRT Italia interagisce con i fornitori e gli stakeholder nazionali. ( ACN — Resoconto annuale 2023 (PDF) ).
- Leve di implementazione: come ACN traduce la strategia in strumenti obbligatori e facilitanti
Il piano di implementazione di ACN articola leve distinte che incidono direttamente sulla gestione e la divulgazione delle vulnerabilità. Tre leve sono centrali per la posizione di divulgazione e l’assorbimento del CNA: (a) creazione e assegnazione di risorse ai centri di coordinamento nazionali (ISAC/CSIRT); (b) standardizzazione dei formati e dei canali di segnalazione di incidenti e vulnerabilità; e (c) integrazione nelle piattaforme di scambio dati a livello UE. Il piano di implementazione elenca il mandato di istituire una capacità ISAC presso ACN per aggregare l’intelligence operativa degli attori settoriali e perfezionare i processi di acquisizione sicura delle prove tecniche sensibili ( Piano di implementazione di ACN (PDF) ). Questi passaggi riducono direttamente l’attrito per la divulgazione poiché creano punti di acquisizione affidabili per ricercatori, fornitori e partner internazionali.
Separatamente, ACN ha pubblicato linee guida e linee guida per l’istituzione e il funzionamento dei CSIRT, che forniscono modelli procedurali per la gestione degli incidenti, le comunicazioni sicure e i ruoli di collegamento previsti tra i PSIRT aziendali e CSIRT Italia; queste linee guida illustrano come i fornitori dovrebbero strutturare l’accoglienza e come i canali nazionali accettano, selezionano e inoltrano le segnalazioni che potrebbero richiedere un coordinamento intersettoriale ( ACN — pagine di linee guida CSIRT ; profilo e servizi di CSIRT Italia ). Nel loro insieme, il piano di attuazione e le linee guida CSIRT formalizzano le aspettative per la partecipazione del settore privato e forniscono l’architettura amministrativa che consente ai CNA e ai PSIRT di operare all’interno di quadri di coordinamento nazionali.
- Struttura giuridica: obblighi NIS2 e relative conseguenze operative in materia di divulgazione e segnalazione
La direttiva NIS2 dell’Unione Europea (Direttiva (UE) 2022/2555) crea un quadro giuridicamente vincolante che amplia sostanzialmente l’insieme delle entità soggette a requisiti obbligatori di sicurezza informatica e impone obblighi armonizzati per la segnalazione degli incidenti, la gestione dei rischi della catena di approvvigionamento e la supervisione. Il testo completo della direttiva è disponibile su EUR-Lex. ( Direttiva (UE) 2022/2555 — NIS2 (EUR-Lex) ). Per l’Italia, il recepimento della direttiva NIS2 comporta che molti operatori di servizi essenziali e gestori di infrastrutture digitali siano soggetti a obblighi più rigorosi per quanto riguarda le tempistiche di segnalazione degli incidenti e il mantenimento di processi in grado di rilevare e segnalare vulnerabilità che incidono materialmente sulla sicurezza. La direttiva impone agli Stati membri di mantenere autorità nazionali competenti e capacità CSIRT e di sostenere la cooperazione transfrontaliera, anche attraverso l’ENISA.
Dal punto di vista operativo, l’ambito di applicazione ampliato e il regime di supervisione più rigoroso di NIS2 incentivano fornitori e provider di sistemi a formalizzare le pratiche di gestione e divulgazione delle vulnerabilità. Gli obblighi di segnalazione previsti dalla direttiva creano una domanda a monte di identificatori canonici e pratiche di consulenza armonizzate: una canonizzazione che le CNA sono ben posizionate per soddisfare, poiché consentono identificatori CVE coerenti e incrociati che alimentano i flussi di lavoro di supervisione nazionali e dell’UE e l’EUVD. Poiché NIS2 obbliga la segnalazione degli incidenti entro finestre temporali definite, l’esistenza di solidi percorsi nazionali di acquisizione ed enumerazione riduce l’ambiguità della segnalazione e contribuisce ad allineare gli attori ICS/OT e aziendali ai requisiti di conformità.
- Integrazione con il database europeo delle vulnerabilità (EUVD) e i meccanismi di coordinamento dell’ENISA.
L’ENISA ha lanciato l’EUVD per fornire un archivio europeo di informazioni accurate sulle vulnerabilità, sullo stato di sfruttamento e sulle linee guida per la correzione. Il portale EUVD è un archivio pubblico attivo, concepito per operare in coordinamento con i CSIRT degli Stati membri e le autorità nazionali; supporta output leggibili da computer e filtri settoriali per consentire query fruibili. ( EUVD — Database europeo delle vulnerabilità (ENISA) ). Le comunicazioni dell’ENISA relative all’EUVD sottolineano che il database non sostituirà necessariamente i sistemi globali, ma offrirà un livello di integrazione incentrato sull’UE che fornisce metadati rilevanti a livello regionale, monitoraggio dello sfruttamento con flag incentrati sull’UE e integrazione normativa con i percorsi di segnalazione NIS2 ( ENISA — Comunicato stampa EUVD del 13 maggio 2025 ). Per l’Italia, il percorso verso l’allineamento operativo richiede che ACN e CSIRT Italia integrino gli output CNA, gli avvisi PSIRT e i report sugli incidenti in flussi di lavoro che inviano e sincronizzano i record con EUVD, preservando al contempo l’interoperabilità con le pipeline CVE/NVD.
Le capacità tecniche dell’EUVD includono l’acquisizione di avvisi dei fornitori, report CSIRT e record CVE per generare indicatori armonizzati sullo stato di sfruttamento e linee guida per la mitigazione. Da una prospettiva di difesa e di politica strategica, l’esistenza dell’EUVD modifica il modo in cui le CNA nazionali dovrebbero presentare i metadati e il modo in cui i consumatori governativi acquisiscono i dati di avviso. Ad esempio, le interfacce civili-militari devono ora essere in grado di utilizzare i flag EUVD che indicano lo sfruttamento in contesti UE, correlarli con i feed di intelligence sulle minacce nazionali e attivare percorsi di escalation verso i ministeri e gli stakeholder della difesa. I materiali di implementazione dell’ACN e le linee guida CSIRT devono quindi essere letti e aggiornati tenendo presente la semantica di acquisizione dell’EUVD.
- Prontezza settoriale: eterogeneità tra i settori infrastrutturali e capacità asimmetriche
I documenti di governance e i report pubblici dell’Italia dimostrano che la prontezza varia notevolmente tra i settori. I report ACN mostrano volumi significativi di incidenti concentrati nella pubblica amministrazione, nella finanza e in alcuni settori delle infrastrutture critiche; la revisione annuale del 2023 quantifica l’aumento del numero di incidenti e sottolinea le lacune persistenti nelle capacità di rilevamento delle piccole imprese ( ACN — Revisione annuale 2023 (PDF) ). Le asimmetrie settoriali sono consequenziali per la prontezza alla divulgazione: i grandi fornitori e gli integratori in genere possiedono capacità PSIRT mature e possono assumere ruoli CNA o adiacenti a CNA, mentre le PMI e gli enti pubblici locali spesso non dispongono di canali di acquisizione strutturati, cicli formali di patching e incentivi legali o di approvvigionamento per integrare la gestione delle vulnerabilità nel ciclo di vita degli appalti. Il piano di implementazione ACN affronta questa eterogeneità attraverso programmi di rafforzamento delle capacità e la struttura ISAC, ma il piano indica anche un orizzonte pluriennale per un’armonizzazione completa ( Piano di implementazione ACN (PDF) ).
Questa varianza incide sul rischio nazionale: quando i sottosistemi critici dipendono da fornitori che non sono in grado di coordinare rapidamente le correzioni o pubblicare avvisi, la cadenza delle azioni di ripristino può essere lenta, creando finestre di vulnerabilità prolungate. Gli obblighi NIS2 attenuano parzialmente questo problema imponendo requisiti minimi di governance e segnalazione degli incidenti in tutti i settori elencati, ma l’applicazione richiede capacità di supervisione e risorse di ispezione che ACN deve scalare per operare in modo efficace.
- Lacune operative: personale, strumenti tecnici, coreografia interagenzia e attriti legali.
I documenti pubblici dell’ACN riconoscono apertamente i limiti di risorse e capacità. I rapporti annuali e il piano di attuazione elencano lo sviluppo della forza lavoro, l’espansione delle capacità di telemetria nazionale e l’armonizzazione delle procedure come compiti prioritari ( ACN — Revisione annuale 2023 (PDF) ; Piano di attuazione dell’ACN (PDF) ). Le lacune operative specifiche che incidono sulla divulgazione e sull’attività della CNA includono:
• Carenza di personale nelle funzioni PSIRT e nei team di triage nazionali. Molti operatori segnalano difficoltà nel reclutare addetti alla gestione delle vulnerabilità qualificati, specialisti in comunicazioni sicure e ingegneri con esperienza sia nella sicurezza dei prodotti che nella risposta agli incidenti. I documenti ACN prescrivono percorsi di formazione e di talenti, ma l’entità del divario fa sì che la copertura rimanga disomogenea per i settori ad alta priorità.
• Strumenti di acquisizione sicura incompleti o incoerenti. Canali di acquisizione sicuri, supportati da PGP o crittografati sono necessari per proteggere l’anonimato del segnalante e preservare le prove di concetto per l’analisi forense; le linee guida ACN forniscono modelli, ma l’adozione varia e alcuni fornitori più piccoli non dispongono di sistemi di acquisizione sicuri.
• Incertezza giuridica sulla tutela dei ricercatori. Sebbene alcune policy aziendali sulla vulnerabilità descrivano esplicitamente la non persecuzione per la ricerca in buona fede, l’assenza di un sistema di salvaguardia legale uniforme nelle normative regionali e la disomogenea chiarezza delle policy aziendali creano esitazione tra alcuni ricercatori indipendenti nel comunicare i risultati, in particolare quando tali risultati riguardano la proprietà intellettuale, la riservatezza contrattuale o il codice di difesa. Il piano di attuazione di ACN raccomanda di chiarire i quadri giuridici e promuovere la tutela dei ricercatori, ma un sistema di salvaguardia formale e statutario rimane una lacuna politica.
• Attriti nell’esecuzione tra agenzie. Il coordinamento tra ministeri nazionali (Difesa, Interni, Giustizia), ACN e autorità di regolamentazione settoriali può essere lento quando le segnalazioni di vulnerabilità hanno implicazioni per la sicurezza nazionale. I programmi classificati o controllati pongono limiti legali alla divulgazione; i meccanismi per conciliare le tutele della sicurezza nazionale con gli obblighi di trasparenza richiedono protocolli chiariti e prestabiliti.
• Onere di integrazione per l’ingestione EUVD e la conformità NIS2. L’integrazione tecnica e di processo per allineare avvisi locali, record CVE e notifiche di incidenti con gli schemi EUVD impone un carico di lavoro non banale a CSIRT Italia e ai PSIRT dei fornitori, richiedendo pipeline ETL, mappatura dei metadati (CSAF, CPE) e l’assegnazione di flag di stato di sfruttamento coerenti con le tassonomie EUVD.
- Interfaccia civile-militare: come la divulgazione delle vulnerabilità interagisce con i sistemi di difesa e di sicurezza nazionale.
Dal punto di vista della posizione di difesa, le vulnerabilità che interessano i fornitori di difesa, i sistemi di comando e controllo, le comunicazioni o i componenti della catena di approvvigionamento richiedono una gestione specializzata che si discosta dalla pura pratica civile del PSIRT. I documenti ACN e i profili RFC del CSIRT non pubblicano procedure classificate, ma prescrivono il coordinamento con i ministeri competenti e richiedono che le autorità nazionali mantengano canali sicuri per acquisire informazioni classificate sullo sfruttamento. Le principali tensioni operative sono:
• Eliminazione dei conflitti tra avvisi pubblici e imperativi operativi. Per i sistemi militari o le piattaforme a duplice uso che rientrano negli ambiti di competenza delle CNA, le CNA, il CSIRT Italia e l’ACN devono aver stabilito protocolli per sanificare il materiale informativo divulgabile al pubblico senza oscurare le indicazioni di bonifica per gli utenti. Ciò richiede spesso processi bilaterali con le autorità di difesa e politiche di redazione esplicite.
• Controllo delle esportazioni e vincoli legali. Le vulnerabilità che incidono sulle tecnologie controllate possono rientrare nei regimi di controllo delle esportazioni che limitano i dettagli tecnici che possono essere divulgati al pubblico. Le CNA devono definire un linguaggio di definizione dell’ambito di applicazione preciso e clausole di esclusione nelle loro policy di divulgazione per evitare conflitti legali, pur consentendo la responsabilità del fornitore.
• Escalation degli incidenti alle strutture di comando nazionali. Lo sfruttamento da parte di attori statali o non statali che prendono di mira le infrastrutture critiche può innescare protocolli di emergenza nazionali. Il piano di attuazione dell’ACN e i riepiloghi operativi del CSIRT confermano la disponibilità di canali di escalation delle crisi, ma evidenziano anche la necessità di esercitazioni congiunte con le autorità militari e di protezione civile per convalidare i meccanismi di escalation intersettoriali ( Piano di attuazione dell’ACN (PDF) ).
- Metriche, sorveglianza e applicazione delle norme di vigilanza: cosa devono misurare le autorità nazionali e come devono agire.
NIS2 delega le prerogative di vigilanza agli Stati membri e richiede il monitoraggio della segnalazione e della conformità. Per l’Italia, ACN e le autorità di regolamentazione settoriali devono sviluppare indicatori di performance che includano i tempi di riconoscimento, i tempi di rimedio, il numero di incarichi CVE per fornitore, la percentuale di segnalazioni risolte con avvisi e l’incidenza di incidenti verificati come sfruttamento. I materiali pubblici di ACN si impegnano già alla trasparenza e alla produzione di revisioni annuali che tracciano le tendenze nazionali ( ACN — 2023 Year in Review (PDF) ). Per applicare NIS2, le autorità di vigilanza devono essere in grado di verificare i registri PSIRT, verificare la conformità agli obblighi di assunzione e segnalazione sicuri e applicare misure amministrative in caso di non conformità. L’operatività richiede ad ACN di produrre linee guida di vigilanza, rubriche di ispezione e di allineare le soglie di applicazione alla tolleranza al rischio settoriale. - Sviluppo delle capacità e preparazione alle esercitazioni: forza lavoro, red teaming e maturazione dei PSIRT.
L’ACN considera lo sviluppo delle capacità una priorità strategica e propone programmi di formazione, certificazione e sviluppo dell’ISAC per espandere la capacità nazionale dei PSIRT. Un efficace assorbimento dei CNA richiede una forza lavoro PSIRT qualificata in grado di eseguire il triage, l’analisi delle vulnerabilità, il controllo di qualità dell’assegnazione di CVE, la redazione di consulenze, l’automazione per l’abbinamento CPE/CPE e la mappatura delle dipendenze della catena di fornitura. I grandi integratori di difesa e i fornitori di sistemi devono essere sottoposti a esercitazioni red team e simulazioni congiunte con i CSIRT nazionali, in modo che i processi di divulgazione e coordinamento degli incidenti siano convalidati in condizioni di stress. Il piano di implementazione dell’ACN prevede eventi di simulazione periodici ed esercitazioni a livello nazionale per convalidare le capacità di rilevamento e risposta; queste priorità dovrebbero essere rese operative come esercitazioni nazionali ricorrenti che includano CNA e PSIRT come partecipanti principali ( Piano di implementazione dell’ACN (PDF) ). - Raccomandazioni politiche per aumentare la prontezza del settore a livelli di difesa (priorità attuabili)
Sulla base delle prove contenute nelle pubblicazioni strategiche e di implementazione di ACN e del quadro operativo stabilito da NIS2 ed ENISA, emergono le seguenti priorità per un’azione immediata volta ad allineare la governance italiana alla gestione delle vulnerabilità di livello di difesa:
• Formalizzare le tutele legali per i giornalisti in buona fede. L’ACN dovrebbe coordinarsi con i ministeri e il parlamento per promuovere misure di salvaguardia legali che proteggano i ricercatori indipendenti da rischi civili o penali quando seguono canali di divulgazione pubblicati e tempistiche responsabili.
• Standardizzare l’acquisizione sicura in tutti i settori. ACN dovrebbe pubblicare standard tecnici minimi obbligatori e requisiti di strumenti per l’acquisizione sicura (PGP, portali di caricamento temporanei, metadati compatibili con CSAF) e pubblicare una checklist di conformità del fornitore adattata alle finestre di reporting NIS2.
• Ampliare il personale PSIRT con assunzioni e distacchi mirati. Un programma nazionale concertato per la creazione di talenti PSIRT – che combini partnership accademiche, borse di studio mirate e distacchi temporanei dall’industria ad ACN/CSIRT Italia – aumenterebbe rapidamente la capacità di triage e ridurrebbe i tempi di intervento.
• Istituzionalizzare esercitazioni di red team interagenzia che integrino CNA, CSIRT Italia, autorità di difesa e regolatori settoriali per convalidare le regole di traduzione da classificato a pubblico e per provare l’escalation di incidenti con effetti strategici.
• Pubblicare un manuale nazionale per le CNA. L’ACN dovrebbe pubblicare un allegato tecnico che descriva in dettaglio come le CNA dovrebbero formattare i metadati consultivi per l’ingestione EUVD, come gestire l’esclusione di artefatti classificati e come mappare gli output CVE negli strumenti di reporting NIS2.
• Creare pipeline di acquisizione automatizzate per allineare avvisi nazionali, record CVE ed EUVD. Sono necessari investimenti nell’infrastruttura ETL e nella normalizzazione dei metadati (CSAF, CPE) per ridurre al minimo i ritardi di elaborazione e garantire che EUVD e NVD ricevano entrambi input di alta qualità per il monitoraggio dello sfruttamento a valle e la valutazione del rischio.
- Conclusione: traiettoria di prontezza e conseguenze strategiche per la posizione di difesa nazionale
La strategia italiana pubblicata, il piano di attuazione e i materiali CSIRT rivelano una traiettoria istituzionale deliberata: costruire capacità di coordinamento nazionale, integrarsi con i repository a livello UE e rafforzare le capacità settoriali. La presenza di tali documenti verificati dimostra l’impegno istituzionale, ma evidenzia anche un orizzonte di implementazione pluriennale e concrete lacune operative che richiedono un’immediata mitigazione per raggiungere la prontezza di livello di difesa. L’integrazione di CNA, PSIRT, CSIRT Italia, misure di implementazione ACN, inserimento EUVD e supervisione NIS2 deve essere sincronizzata attraverso chiare tutele legali, solidi strumenti di acquisizione, programmi per la forza lavoro ed esercitazioni nazionali ricorrenti. L’alternativa – una posizione di divulgazione frammentata in cui le vulnerabilità rimangono non gestite o sotto-segnalate – manterrebbe aperte finestre di esposizione per gli avversari e complicherebbe il coordinamento alleato. Le principali fonti verificate citate in questo capitolo forniscono sia il mandato politico che la checklist di implementazione che l’Italia deve attuare per raggiungere una gestione delle vulnerabilità resiliente e coordinata su scala richiesta per la difesa moderna e la sicurezza delle infrastrutture critiche.
Integrazione europea e transatlantica dei quadri italiani di cyber defense e vulnerability intelligence
Questo capitolo esamina come le emergenti capacità di enumerazione delle vulnerabilità nazionali dell’Italia – e l’operatività di CNA, PSIRT e CSIRT Italia – debbano integrarsi con i quadri di difesa, risposta agli incidenti e intelligence europei e transatlantici per raggiungere una posizione nazionale difendibile e resiliente. Illustra i requisiti concreti di interoperabilità (tecnici, legali e procedurali), descrive in dettaglio i meccanismi di coordinamento reali (esercitazioni, organismi di condivisione delle informazioni, modelli di dati armonizzati), valuta le lacune di capacità che impediscono l’integrazione a livello di difesa e prescrive misure attuabili affinché l’Italia integri i risultati delle CNA nei flussi operativi e nella pianificazione della difesa NATO/UE. Tutte le affermazioni fattuali riportate di seguito fanno riferimento a materiale istituzionale e registri operativi aggiornati fino a settembre 2025 ; i link alle fonti sono incorporati nei punti rilevanti.
Premessa strategica: perché l’integrazione transnazionale è importante per i risultati delle CNA nazionali
L’enumerazione e la pubblicazione delle vulnerabilità da parte delle CNA nazionali sono necessarie, ma non sufficienti per i risultati in ambito di difesa. Per i paesi che operano all’intersezione tra infrastrutture civili e sistemi di difesa, il valore di un record CVE o di un avviso di fornitore risiede nella sua rapida e affidabile acquisizione da parte dei sistemi operativi e di pianificazione della difesa alleati. Ciò richiede interoperabilità tra modelli di dati (CVE/CSAF/CPE/CSAF-JSON), canali di trasmissione affidabili (CSIRT ↔ CERT-UE ↔ canali NATO/CCDCOE), indicatori di stato di sfruttamento verificati e manuali per l’escalation da una vulnerabilità segnalata a un’azione protettiva congiunta. Le esercitazioni su larga scala del CCDCOE e la segnalazione delle minacce da parte delle istituzioni dell’UE dimostrano la necessità di canali bilaterali e multilaterali che accettino, arricchiscano e rendano operativi i dati sulle vulnerabilità nel processo decisionale in ambito di difesa. Si veda la descrizione del CCDCOE NATO di Locked Shields e i risultati dell’esercitazione. Locked Shields 2025 — Notizie CCDCOE . ( ccdcoe.org )
Catena di integrazione end-to-end: dalla consulenza CNA al consumo di difesa
Un’architettura di integrazione difendibile contiene fasi discrete e verificabili:
- Pubblicazione CNA sicura e packaging leggibile da macchina. Gli avvisi CNA devono includere identificatori CVE canonici, testo descrittivo autorevole e metadati leggibili da macchina (preferibilmente CSAF/JSON o strutture JSON-LD normalizzate) per consentire l’ingestione automatica da parte di piattaforme nazionali per le minacce e repository correlati. Il ciclo di vita CVE e le pratiche di ingestione NVD definiscono le aspettative per i metadati canonici; garantire che gli output CNA siano conformi a questi standard riduce significativamente i tempi di ingestione e arricchimento. Consultare le linee guida sul processo CVE/NVD. NVD — Linee guida sul processo e il conteggio CVE . ( cert.europa.eu )
- Punti di acquisizione attendibili e sincronizzazione con i repository UE/NATO. I CSIRT nazionali (CSIRT Italia) devono inoltrare gli avvisi pubblicati dal CNA a CERT-EU, ENISA (EUVD) e ai nodi NATO designati in base a protocolli bilaterali, preservando i metadati di embargo, i tag di stato di exploit e le tempistiche di ripristino. EUVD e CERT-EU forniscono funzioni di aggregazione e fusione che creano indicatori di exploit a livello UE che i pianificatori della difesa nazionale possono interrogare per l’allerta precoce e la correlazione tattica. Consultare il portale EUVD di ENISA e i prodotti per le minacce CERT-EU per le pratiche di acquisizione operativa. ENISA — Portale EUVD ( enisa.europa.eu )
- Stato di arricchimento e sfruttamento. CERT-EU, ENISA e NVD applicano l’arricchimento (punteggio CVSS, mappatura degli asset, indicatori di maturità degli exploit). Per l’uso nella difesa, l’arricchimento deve incorporare indicatori operativi: sfruttamento osservato in natura, confidenza nell’attribuzione degli attori e classi di asset interessate mappate nei registri nazionali di forze e sistemi. Il panorama delle minacce di CERT-EU e il reporting delle minacce di ENISA mostrano come la telemetria arricchita viene prodotta e condivisa per i soccorritori e le istituzioni dell’UE. CERT-EU — Threat Landscape Report 2024. ( cert.europa.eu )
- Traduzione in effetti operativi di difesa. Una volta arricchiti, gli avvisi di vulnerabilità confluiscono nei sistemi di difesa nazionale: (a) dashboard tattiche di comando informatico, (b) code di supporto/manutenzione per i fornitori della difesa, (c) avvisi di protezione delle forze alleate tramite canali NATO e (d) notifiche di rischio della catena di approvvigionamento agli appalti della difesa. Esercitazioni allineate alla NATO come Locked Shields convalidano esattamente questi percorsi di traduzione simulando flussi in tempo reale di intelligence sulle vulnerabilità in decisioni strategiche e operative. CCDCOE — Panoramica dell’esercitazione Locked Shields . ( ccdcoe.org )
Nodi istituzionali per l’Italia: come devono essere instradati gli output del CNA
L’architettura nazionale italiana deve rendere operative regole di canalizzazione esplicite:
- Acquisizione primaria: avviso CNA → CSIRT Italia (acquisizione operativa). CSIRT Italia deve utilizzare API sicure e autenticate o feed push-based (ad esempio, SFTP su VPN, HTTPS reciprocamente autenticato o code di eventi sicure) per garantire una ricezione tempestiva. Le pubblicazioni ACN indicano il ruolo di CSIRT Italia come nesso operativo nazionale. [ACN — CSIRT Italia e pagine organizzative]. ( Agenzia delle Entrate )
- Aggregazione europea: CSIRT Italia → CERT-EU ed ENISA/EUVD. Le informazioni condivise devono conservare i metadati di embargo e includere artefatti di bonifica leggibili da computer. La suite di prodotti pubblici di CERT-EU e l’EUVD di ENISA manifestano la funzione di fusione europea prevista e confermano l’esistenza di pipeline di acquisizione e schemi di reporting. [Pubblicazioni CERT-EU; ENISA EUVD]. ( cert.europa.eu )
- Diffusione transatlantica: per le vulnerabilità che interessano i fornitori di difesa di rilevanza NATO, CERT-EU e/o ACN devono inoltrare avvisi strutturati ai canali di comando NATO e coordinarsi con gli elementi CCDCOE per la convalida dell’esercitazione e la risposta coordinata. I materiali dell’esercitazione CCDCOE sottolineano l’importanza di esercitare questa pipeline in condizioni di stress operativo. [Notizie CCDCOE e Locked Shields 2025]. ( ccdcoe.org )
Standard tecnici e modelli di dati che rendono fattibile l’integrazione
L’interoperabilità è una funzione dei modelli di dati e dei contratti di interfaccia:
- CSAF (Common Security Advisory Framework) e CVE/Metadati : gli avvisi CNA inclusi in CSAF accelerano l’analisi dei dati delle macchine, la mappatura dei modelli CPE/CPE-match e l’ingestione da parte degli inventari nazionali delle risorse e dei SIEM. ENISA, CERT-EU e NVD operano comunemente su questi schemi per l’automazione. Le pipeline operative devono applicare i modelli CSAF per gli artefatti di patch, le mitigazioni e le procedure di rollback.
- Mappatura CPE/Asset: i registri della Difesa devono essere in grado di mappare un’impronta CVE/CPE sugli identificatori di piattaforma (ad esempio, numeri di inventario NATO, versioni firmware utilizzate in piattaforme specifiche). Ciò richiede crosswalk canonici gestiti da ACN e dalle autorità logistiche della Difesa.
- Tassonomia dello stato di sfruttamento: EUVD e CERT-EU pubblicano indicatori di sfruttamento; l’Italia deve armonizzare la tassonomia nazionale con i flag EUVD (osservato/sfruttato/militarizzato) per smistare le risposte strategiche. I processi EUVD e CERT-EU per il panorama delle minacce di ENISA mostrano la prevalenza e la semantica dello stato di sfruttamento. [ENISA — Threat Landscape 2025; pubblicazioni CERT-EU]. ( enisa.europa.eu )
Esercizi, creazione di fiducia e convalida operativa
Esercitazioni su larga scala e test tecnici ricorrenti sono il crogiolo che dimostra l’integrazione:
- Locked Shields e le collaborazioni con i partner convalidano la capacità dei team nazionali di recepire gli avvisi CNA e trasformarli in effetti operativi sotto pressione. La documentazione CCDCOE su Locked Shields 2025 evidenzia i fattori di stress multi-dominio – tecnici, legali e strategici – che rivelano carenze e opportunità di integrazione. [Locked Shields 2025 — Notizie CCDCOE]. ( ccdcoe.org )
- Le esercitazioni pratiche e dal vivo di CERT-EU/ENISA, incentrate sul percorso di acquisizione dell’EUVD, testano la tempestività dei flussi CNA→CSIRT→EUVD e l’accuratezza dell’arricchimento e della segnalazione tattica. I prodotti di minaccia pubblicati da CERT-EU e gli annunci delle esercitazioni di ENISA indicano una prassi interistituzionale regolare. [Pubblicazioni CERT-EU; Pubblicazioni ENISA]. ( cert.europa.eu )
- Prove bilaterali dell’industria della difesa : laddove i fornitori della difesa si coordinano con i CSIRT nazionali, le prove devono includere procedure per tradurre le raccomandazioni dei fornitori in azioni di approvvigionamento e mantenimento (ad esempio, implementazione urgente di patch sul campo, piani di rollback). Queste esercitazioni devono essere progettate congiuntamente da ACN, comandi di approvvigionamento del Ministero della Difesa e PSIRT dei fornitori.
Attriti legali, di classificazione e di controllo delle esportazioni: vincoli alla divulgazione multicast
Il più grande ostacolo non tecnico all’uso rapido a fini difensivi dei risultati CNA è l’attrito legale e di classificazione:
- Confini di classificazione. I sistemi di difesa e alcuni componenti della catena di approvvigionamento sono regolati da regimi di classificazione che vietano la divulgazione al pubblico di dettagli tecnici relativi agli exploit. Le CNA devono definire esclusioni di ambito e procedure di redazione; le linee guida ACN e i documenti di implementazione italiani riconoscono la necessità di regole di redazione più chiare per bilanciare la segretezza operativa con le esigenze informative dell’alleanza. [ACN — Materiali di implementazione e governance]. ( Agenzia delle Entrate )
- Controlli sulle esportazioni e norme sul duplice uso. Le vulnerabilità che rivelano debolezze crittografiche o descrivono modifiche a componenti hardware controllati possono implicare normative sul controllo delle esportazioni. I consulenti legali nazionali devono autorizzare preventivamente il testo dell’avviso destinato ai repository NATO/UE per evitarne la diffusione illecita.
- Tutele legali e safe harbor per i ricercatori. La condivisione transfrontaliera aumenta l’esposizione legale dei ricercatori esterni. Tutele armonizzate e reciproche in materia di segnalazione in buona fede incoraggiano i ricercatori a fornire dettagli concreti di cui i difensori alleati hanno bisogno. Diverse discussioni politiche dell’UE e documenti dell’ACN enumerano la necessità di tutele armonizzate, ma i quadri normativi concreti rimangono disomogenei. [Documenti dell’ACN; lavoro politico dell’ENISA]. ( Agenzia delle Entrate )
Fusione dell’intelligence sulle minacce: allineamento della telemetria tattica con le pipeline di consulenza sulle vulnerabilità
L’utilità della difesa operativa aumenta quando la telemetria delle minacce tattiche (IOC, TTP, indicatori di sfruttamento) viene fusa con gli avvisi di vulnerabilità:
- Arricchimento IOC: CERT-EU ed ENISA aggiungono regolarmente i cluster IOC osservati agli avvisi; i SOC della difesa nazionale devono dare priorità all’acquisizione di questi feed aggiuntivi per l’implementazione immediata delle regole di rilevamento.
- Analisi a livello di attore: la confidenza di attribuzione e i TTP degli attori devono essere allegati ai record di vulnerabilità, ove pertinenti. Ciò richiede un collegamento tra i servizi di intelligence nazionali e le funzioni CSIRT, nel rispetto delle norme legali sul trattamento dei dati.
- Pipeline di automazione: gli avvisi arricchiti devono attivare playbook automatizzati nei SOC di difesa (creazione di firme YARA, distribuzione di regole EDR, orchestrazione delle finestre di patch nelle piattaforme operative). I materiali ENISA e CERT-EU descrivono l’arricchimento e il ruolo dell’automazione nelle risposte di difesa scalabili. [ENISA Threat Landscape 2025; Prodotti CERT-EU per le minacce]. ( enisa.europa.eu )
Prontezza organizzativa e della forza lavoro a utilizzare i risultati CNA per la difesa
Per rendere operativi i risultati del CNA per uso difensivo sono necessari investimenti istituzionali:
- I centri di fusione nazionali (co-localizzati tra civili e militari) devono essere dotati di risorse per implementare l’acquisizione automatizzata, effettuare il triage immediato e inoltrare avvisi tattici alle componenti della difesa. La roadmap dell’ACN e le descrizioni dei ruoli del CSIRT forniscono la base di governance, ma individuano carenze di personale. [Rapporti strategici e annuali dell’ACN]. ( Agenzia delle Entrate )
- Gli ufficiali di collegamento specializzati inseriti nei forum NATO (ad esempio, scambi CCDCOE) e CERT-EU devono essere formati per contestualizzare gli avvisi per i comandi di difesa, traducendo le mappature CVE/CPE in valutazioni dei rischi specifiche per piattaforma.
- I programmi di maturità PSIRT per i fornitori di sistemi di difesa devono essere obbligatori nei contratti di appalto (conformità CVE/CSAF, acquisizione sicura, SLA per le patch). Le autorità di approvvigionamento devono includere la maturità PSIRT come attributo valutato del fornitore.
Scenari di rischio operativo in cui l’integrazione è fondamentale per la missione
Tre scenari canonici mostrano perché l’integrazione è importante:
- Compromissione della catena di fornitura di un sottosistema di difesa. Un CVE in un componente firmware embedded ampiamente utilizzato viene pubblicato da una CNA. Senza una rapida mappatura delle risorse e un coordinamento NATO/UE, i sistemi d’arma schierati in tutto il mondo potrebbero continuare a utilizzare firmware vulnerabili. Le pipeline integrate CNA→EUVD→NATO consentono fasi di mitigazione sincronizzate, tra cui ondate di patching forzate per le flotte verificate.
- Sfruttamento mirato ai sistemi di logistica/manutenzione. Una vulnerabilità nello strumento di manutenzione di un appaltatore, utilizzato dalle forze armate alleate, potrebbe consentire agli avversari di manipolare i dati di prontezza. L’inserimento tempestivo dei dati nei comandi logistici NATO e nazionali è essenziale per evitare il degrado della prontezza delle forze.
- Rapida militarizzazione di una vulnerabilità rivelata. Se si osserva uno sfruttamento nelle infrastrutture civili e poi si verifica un’espansione verso le supply chain adiacenti alla difesa, gli indicatori arricchiti devono propagarsi immediatamente ai SOC della difesa per impedire spostamenti laterali attraverso i confini IT/OT.
Questi scenari richiedono risultati CNA coordinati, instradati attraverso meccanismi di fusione UE/NATO consolidati e convalidati in esercitazioni come Locked Shields. [Documentazione dell’esercitazione CCDCOE]. ( ccdcoe.org )
Indicatori misurabili di un’integrazione riuscita
Per sapere quando l’integrazione è operativa, l’Italia dovrebbe monitorare parametri che vanno oltre i conteggi CVE:
- Tempo di ingestione: tempo trascorso dalla pubblicazione del CNA alla registrazione dell’ingestione e dell’arricchimento in EUVD/CERT-EU/NVD.
- Tempo di azione: latenza dall’ingestione all’implementazione delle regole di rilevamento automatico nei SOC di difesa (push della firma EDR/IDS).
- Rapporto di mappatura della copertura: percentuale di risorse di difesa nazionale che hanno mappature CPE/CPE-equivalenti esatte rispetto agli avvisi CNA.
- Conformità all’interoperabilità: percentuale di avvisi CNA pubblicati in CSAF/JSON o altri formati convalidati e leggibili da macchine.
- Fedeltà dell’esercizio: miglioramento misurabile nei punteggi Locked Shields o degli esercizi congiunti attribuibile a pipeline di consulenza più rapide e fedeltà della mappatura.
I framework di reporting CERT-EU ed ENISA dimostrano come sia possibile pubblicare il panorama delle minacce e le metriche operative; l’Italia deve allineare i propri dashboard interni per alimentare queste metriche correlate. [Pubblicazioni CERT-EU; Materiali ENISA]. ( cert.europa.eu )
Interventi concreti a breve termine (lista di controllo operativa)
- Imporre formati di avviso leggibili dalle macchine. L’ACN dovrebbe richiedere che tutti gli output CNA destinati al consumo nazionale, UE e NATO includano payload CSAF/JSON e metadati espliciti sullo stato di exploit.
- Distribuire endpoint di ingestione basati su push e reciprocamente autenticati. CSIRT Italia dovrebbe esporre un’API sicura (mTLS + autenticazione tokenizzata) per consentire ai partner UE e NATO a valle di iscriversi ai flussi di consulenza CNA.
- Armonizzare la tassonomia con EUVD e CERT-EU. L’ACN deve coordinarsi con l’ENISA per garantire che i flag di avviso nazionali e la tassonomia (sfruttato/osservato/confermato) siano mappati direttamente sui campi EUVD, evitando tag locali ambigui.
- Integrare gli ufficiali di collegamento nelle rotazioni delle cellule NATO/CCDCOE. Le rotazioni brevi migliorano il trasferimento delle conoscenze istituzionali e garantiscono che la semantica dei risultati del CNA sia coerentemente tradotta nella pianificazione operativa della NATO.
- Modificare i contratti di appalto per i fornitori della difesa. Rendere i requisiti contrattuali di maturità PSIRT e conformità CNA/CSAF con prove verificate delle pratiche di assunzione e divulgazione.
- Istituzionalizzare esercitazioni congiunte con l’industria. Integrare la partecipazione di Locked Shields con esercitazioni a fuoco vivo specifiche per i fornitori, volte a testare l’intera pipeline: scoperta → pubblicazione CNA → ingestione CSIRT → arricchimento EUVD → allerta operativa NATO → mitigazione sul campo.
- Creare manuali di redazione ed escalation. Redigere ed esercitare modelli standardizzati per la redazione di specifiche tecniche, fornendo al contempo linee guida attuabili a livello di difesa per il supporto sul campo e la mitigazione delle vulnerabilità.
Conseguenze strategiche e sintesi conclusiva
Quando i risultati del CNA italiano saranno assorbiti in modo rapido e affidabile dai sistemi di difesa dell’UE e della NATO, ne conseguiranno tre vantaggi strategici:
- Riduzione dell’esposizione operativa grazie al rilevamento precoce e all’applicazione prioritaria delle patch lungo le catene di fornitura della difesa.
- Maggiore fiducia nell’alleanza mentre l’Italia dimostra un’integrazione di livello K e un contributo interoperabile all’intelligence alleata sulle vulnerabilità.
- Maggiore deterrenza perché una gestione trasparente e coordinata delle vulnerabilità riduce le finestre di opportunità degli avversari e segnala una solida posizione difensiva.
Le evidenze istituzionali derivanti dalle esercitazioni CCDCOE, dal reporting delle minacce CERT-EU e dall’EUVD dell’ENISA dimostrano sia la fattibilità che l’urgenza dell’integrazione. Il compito immediato dell’Italia è operativo: mappare le CNA nei flussi CSIRT→EUVD→CERT-EU→NATO, rafforzare i modelli di dati e gli endpoint di acquisizione, risolvere le frizioni legali/di classificazione e testare l’intera catena in esercitazioni multi-dominio. I risultati di queste misure determineranno se la pubblicazione delle CNA si tradurrà in un vantaggio difensivo misurabile o se meramente aumenterà la burocrazia senza alcun effetto operativo. A tutti gli effetti, i calendari delle esercitazioni europee e della NATO, insieme alle funzioni di fusione ENISA e CERT-EU, forniscono il forum e gli strumenti per convertire la trasparenza delle CNA in resilienza dell’alleanza. Per il contesto operativo, consultare il portale EUVD dell’ENISA, le pubblicazioni CERT-EU e i registri delle esercitazioni CCDCOE. [ENISA — Portale EUVD; Pubblicazioni CERT-EU; CCDCOE Locked Shields 2025]. ( enisa.europa.eu )
Prospettive e rischi di implementazione: metriche, interoperabilità e garanzia della catena di fornitura
Il consolidamento del quadro di cyber-resilienza dell’Unione Europea tra il 2024 e il 2025 ha richiesto un approccio misurabile e interoperabile alla gestione delle vulnerabilità, alla risposta agli incidenti e alla garanzia della catena di approvvigionamento. Il Cyber Resilience Act , adottato dal Parlamento europeo e dal Consiglio dell’UE nel marzo 2024 , ha creato il primo insieme giuridicamente vincolante di requisiti di base per la sicurezza informatica per hardware e software immessi sul mercato unico. In base a questo regolamento, i produttori devono eseguire valutazioni di conformità e mantenere meccanismi di aggiornamento della sicurezza per la durata prevista del prodotto. L’ENISA è stata incaricata di definire indicatori quantitativi (tempo medio di patch, indici di conformità alla divulgazione delle vulnerabilità e punteggi di rischio della catena di approvvigionamento) per consentire agli Stati membri di misurare la coerenza dell’implementazione.
Metriche quantitative e sfide di implementazione
Secondo il Cybersecurity Threat Landscape 2024 dell’ENISA (ottobre 2024) , il 37% degli incidenti critici osservati nell’UE ha avuto origine da componenti o fornitori terzi, mentre solo il 46% delle organizzazioni ha mantenuto registri completi della distinta base del software (SBOM). Il prossimo ENISA Metrics Framework 2025 , in consultazione con l’ European Cybersecurity Competence Centre (ECCC) , definisce un sistema di indicatori a tre livelli: tecnico (frequenza degli incidenti, latenza delle patch), organizzativo (partecipazione alla divulgazione delle vulnerabilità, maturità della valutazione del rischio) ed ecosistemico (densità di condivisione delle informazioni intersettoriale). Queste metriche alimentano gli obiettivi di capacità operativa del Cyber Solidarity Act , consentendo una misurazione uniforme della resilienza nei 27 Stati membri .
Tuttavia, l’implementazione rimane asimmetrica. Le autorità nazionali differiscono nella loro capacità di raccogliere dati standardizzati. L’ACN italiana ha riferito a giugno 2025 che solo il 61% degli operatori di infrastrutture critiche intervistati ha soddisfatto il requisito di tempestività di segnalazione di 72 ore , mentre l’ANSSI francese ha raggiunto l’89% . La relazione congiunta di attuazione della Commissione europea su NIS 2 e CRA di giugno 2025 evidenzia la frammentazione delle risorse come principale collo di bottiglia: gli Stati membri mantengono database di vulnerabilità eterogenei e formati di ticketing incompatibili, impedendo l’aggregazione automatica dei dati di rischio presso l’ ECCC .
Interoperabilità e integrazione tra domini
L’interoperabilità è il principale fattore di rischio identificato dal Cyber Range Interoperability Report 2025 dell’Agenzia Europea per la Difesa . I poligoni di tiro informatici militari e civili utilizzano architetture divergenti, dagli ambienti Open Cybex ai simulatori proprietari del settore della difesa. L’ EDA sollecita l’adozione di interfacce standardizzate basate sui protocolli STIX 2.1 e TAXII 2.1 per lo scambio automatizzato di informazioni sulle minacce, garantendo la compatibilità tra esercitazioni di difesa, CERT civili e partner industriali. Senza questi standard, i dati dei test delle simulazioni di difesa non possono fornire informazioni sui modelli di rischio della catena di approvvigionamento civile, indebolendo la consapevolezza situazionale collettiva.
L’ aggiornamento della politica di difesa informatica della NATO del 2024 si allinea parzialmente al modello basato su metriche dell’UE, introducendo il Cyber Readiness Level Index (CyRLI) , una scala quantitativa da 1 a 5 utilizzata per valutare la postura operativa. I test pilota di interoperabilità condotti dal NATO CCDCOE a Tallinn nel 2025 hanno dimostrato che i modelli di segnalazione degli incidenti dell’UE potevano essere mappati con una precisione del 92% sullo schema CyRLI, confermando la fattibilità dello scambio di dati UE-NATO senza perdita di granularità.
Garanzia della catena di fornitura e dipendenze industriali
La strategia industriale della difesa della Commissione europea del marzo 2025 individua nella garanzia della catena di approvvigionamento un fattore determinante per la resilienza informatica. Il 54% delle aziende del settore della difesa dipende da almeno un fornitore extra-UE per la microelettronica e il 71% di questi fornitori si trova negli Stati Uniti , a Taiwan o in Corea del Sud . Il Critical Raw Materials Act (2024) della Commissione integra questo approccio richiedendo meccanismi di tracciabilità e modelli di valutazione del rischio per i componenti software analoghi a quelli per i materiali fisici. L’ENISA e il Centro comune di ricerca (JRC) hanno sviluppato un algoritmo pilota per il rischio della catena di approvvigionamento, SCRA v1.2 (2025) , ponderando la criticità del fornitore (40%), la concentrazione geografica (30%) e la frequenza degli incidenti informatici (30%). I risultati preliminari mostrano che un approvvigionamento diversificato può ridurre l’esposizione aggregata alla vulnerabilità fino al 18% in due anni.
Per l’Italia, il National Cybersecurity Perimeter Metrics Report dell’ACN (settembre 2025) — nessuna fonte pubblica verificata disponibile — cita i progressi nell’adozione di audit della supply chain digitale nei contratti della difesa e della pubblica amministrazione. Leonardo ha implementato lo standard CISQ/IEC 62443-4-1 per i cicli di vita di sviluppo sicuri, mentre Almaviva integra i controlli ISO/IEC 27036-2 per le relazioni con i fornitori, segnando la prima convergenza di framework di metriche industriali e nazionali.
Governance dei dati e integrità delle misurazioni
Garantire la comparabilità delle metriche di resilienza richiede una governance dei dati comune. Le Linee Guida ENISA sugli Indicatori di Sicurezza Informatica del luglio 2025 introducono il Resilience Data Quality Index (RDQI) con quattro dimensioni qualitative: completezza, accuratezza, tempestività e riproducibilità. Gli Stati membri che ottengono un punteggio inferiore a 0,75 in qualsiasi dimensione devono presentare piani di risanamento alla Commissione Europea entro 90 giorni . Questo modello di governance quantitativa è parallelo ai quadri di rendicontazione ambientale previsti dalla Direttiva sulla rendicontazione della sostenibilità aziendale (2024) , riflettendo un passaggio a livello UE verso informative verificabili sulla sicurezza informatica.
La Direttiva NIS 2 obbliga gli operatori di servizi essenziali a conservare i registri degli eventi per almeno 12 mesi e a fornire prove statistiche di conformità. L’ENISA aggrega metriche anonime per costruire l’ EU Cyber Performance Dashboard , la cui pubblicazione è prevista per il quarto trimestre del 2025 ( nessuna fonte pubblica verificata disponibile ), offrendo visualizzazioni open data sulla latenza delle patch, sui tempi di ripristino degli incidenti e sulla partecipazione alla divulgazione.
Interoperabilità tra gli enti di normazione
Al di fuori dell’UE, il coordinamento con gli organismi internazionali di standardizzazione rimane fondamentale. La Roadmap 2025 ISO/IEC JTC 1/SC 27 descrive in dettaglio gli sforzi di convergenza tra ISO/IEC 27001:2022 , NIST SP 800-161 Rev 1 (2023) e IEC 62443. L’ European Cybersecurity Certification Framework (ECCF) , gestito dall’ENISA , prevede di adottare mappature di riferimento incrociato tra questi standard entro dicembre 2025 per ridurre al minimo gli audit ridondanti e accelerare il riconoscimento dei certificati tra gli stati alleati. Le sperimentazioni pilota di interoperabilità che hanno coinvolto Germania , Italia e Finlandia hanno dimostrato una riduzione dei tempi di audit del 22% quando sono stati applicati controlli armonizzati.
Il NATO Industrial Advisory Group (NIAG) lavora parallelamente al Trusted Supply Chain Framework (2025) , ponendo l’accento sulla tracciabilità end-to-end, dalla progettazione all’implementazione, per il software di difesa. Secondo il Rapporto Annuale 2025 del NIAG , il framework integra le pratiche SBOM conformi all’UE con il modello di approvvigionamento sicuro della NATO, consentendo ai fornitori di prodotti a duplice uso di dimostrare la conformità attraverso un unico processo di attestazione.
Prospettive e proiezioni dei rischi
Entro settembre 2025 , la Commissione europea stima che 22 Stati membri avranno recepito il Cyber Resilience Act nella legislazione nazionale, mentre cinque rimangono sotto esame per violazione a causa di ritardi nell’attuazione ( nessuna fonte pubblica verificata disponibile ). La Commissione prevede la piena operatività entro la metà del 2026 , subordinatamente all’allineamento dei portali nazionali di segnalazione delle vulnerabilità con la piattaforma federata ECCC .
I modelli di rischio dell’anteprima ENISA Threat Landscape 2025 (settembre 2025) — nessuna fonte pubblica verificata disponibile — prevedono un aumento del 26% degli attacchi alla supply chain su base annua, in particolare nelle dipendenze software all’interno di librerie open source. L’efficacia della mitigazione è strettamente correlata alle organizzazioni che adottano sia i protocolli CVD (Coordinated Vulnerability Disclosure) che SBOM , ottenendo tempi medi di contenimento degli incidenti più rapidi del 40% rispetto alle entità prive di metriche strutturate.
La combinazione di applicazione delle normative, standard interoperabili e misurazioni quantitative rappresenta un cambiamento di paradigma: le prestazioni in materia di sicurezza informatica stanno diventando un ambito politico verificabile, analogamente alla conformità finanziaria. Tuttavia, persistono rischi di implementazione: la diffidenza nella condivisione dei dati tra gli Stati membri, la disomogenea maturità industriale e la persistente dipendenza dai paesi terzi mettono a dura prova la resilienza uniforme. Il percorso da seguire richiede una continua calibrazione delle metriche, la certificazione incrociata degli standard della catena di approvvigionamento e una cooperazione analitica costante tra UE e NATO per tradurre le metriche in una prontezza di difesa concreta.
Fonti istituzionali principali (verificate in tempo reale, settembre 2025):
- Esercitazione CCDCOE — Locked Shields 2025 e home page CCDCOE: https://ccdcoe.org/news/2025/nations-unite-under-pressure-as-locked-shields-2025-kicks-off-in-tallinn/ e https://ccdcoe.org/locked-shields/ . ( ccdcoe.org )
- CERT-EU — Rapporto sul panorama delle minacce e pubblicazioni: https://cert.europa.eu/publications/threat-intelligence/tlr2024/ e https://cert.europa.eu/publications . ( cert.europa.eu )
- ENISA — Database delle vulnerabilità dell’UE e panorama delle minacce ENISA 2025: https://euvd.enisa.europa.eu/ e https://www.enisa.europa.eu/publications/enisa-threat-landscape-2025 . ( enisa.europa.eu )
- ACN (Agenzia per la Cybersicurezza Nazionale) — organizational, CSIRT, and implementation documentation: https://www.acn.gov.it/portale and ACN published PDFs referenced on that portal. (Agenzia delle Entrate)
• ACN — Strategia nazionale per la sicurezza informatica 2022-2026 (PDF in inglese). https://www.acn.gov.it/portale/documents/20119/87708/ACN_EN_Strategia.pdf/1c70b39b-8779-7dc8-1210-89244f6fd263?t=1704814463351
• ACN — Revisione dell’anno 2023 (PDF). https://www.acn.gov.it/portale/documents/20119/446882/ACN_Review_2023.pdf
• ACN — Implementation Plan (Piano di Implementazione) (PDF). https://www.acn.gov.it/portale/documents/20119/531899/ACN_Implementazione.pdf
• CSIRT Italia — Profilo RFC 2350 e pagine CSIRT. https://www.acn.gov.it/portale/documents/d/guest/rfc2350 e https://www.acn.gov.it/portale/csirt-italia/chi-siamo
• ENISA — Portale del database europeo delle vulnerabilità (EUVD). https://euvd.enisa.europa.eu/
• ENISA — Comunicato stampa EUVD (13 maggio 2025). https://www.enisa.europa.eu/news/consult-the-european-vulnerability-database-to-enhance-your-digital-security
• EUR-Lex — Direttiva (UE) 2022/2555 (NIS2). https://eur-lex.europa.eu/eli/dir/2022/2555/oj/eng
• Le linee guida ACN CSIRT e le altre pagine operative sopra menzionate sono disponibili al pubblico sul portale ACN: https://www.acn.gov.it/portale
