Crisi del sistema CVE un anno dopo: cosa è cambiato per la cybersecurity delle PMI nel 2026 e come ridurre la dipendenza da MITRE

Il 15 aprile 2025, alle 21:30 ora italiana, ho ricevuto una telefonata dal CTO di un cliente che gestisce un'infrastruttura SaaS B2B in produzione su Hetzner. Era atterrato un thread interno dal team di security operations: "Domani il programma CVE potrebbe smettere di pubblicare nuovi identificativi. Cosa facciamo con i nostri scanner di vulnerabilità?". Per le 22:00 stavamo già scrivendo un piano di emergenza: cosa significa per il loro stack Laravel/Symfony se Trivy, Snyk e composer audit perdessero la loro fonte primaria di dati. Cinque ore dopo, CISA annunciò l'estensione di 11 mesi del contratto con MITRE e il panico rientrò. Il giorno successivo, ho passato due ore al telefono con il CTO a spiegare perché avere panicato non era stato un errore - era il segnale che la loro pipeline di vulnerability management si appoggiava interamente a un sistema con una single point of failure governativa, e quel sistema aveva appena dimostrato di essere meno robusto di quanto pensavano.

Un anno dopo, scrivo questo aggiornamento da una posizione di hindsight molto diversa rispetto al panico di aprile 2025. Il finanziamento è stato rinnovato, EUVD è stato lanciato, la CVE Foundation è stata creata e poi parzialmente disinnescata. Ma per una PMI italiana che opera sotto NIS2 nel 2026, la lezione operativa è esattamente quella di un anno fa: non basare la tua security su una sola fonte. Vediamo cosa è cambiato e cosa fare concretamente.

Aprile 2025 → aprile 2026: cosa è successo davvero al programma CVE

Il 15 aprile 2025, MITRE comunicò al CVE board che il contratto Department of Homeland Security che finanzia il programma CVE/CWE sarebbe scaduto il 16 aprile senza rinnovo. La sera del 15 aprile, CISA esercitò un'opzione contrattuale che estese il finanziamento di 11 mesi, portando la deadline a marzo 2026. Nel frattempo, un gruppo di membri del CVE board (che lavoravano in segreto da circa un anno su un piano alternativo) annunciò la nascita della CVE Foundation, un'organizzazione no-profit pensata per separare il programma CVE dal singolo finanziatore governativo. Il 13 maggio 2025 ENISA lanciò ufficialmente l'European Vulnerability Database (EUVD) - tecnicamente in beta ma dichiarato "operativo" - come parte degli obblighi della Direttiva NIS2.

Tra fine 2025 e inizio 2026, CISA e MITRE hanno rinegoziato il contratto eliminando la scadenza che aveva scatenato la crisi del 2025. Il programma è "pienamente finanziato" secondo le dichiarazioni ufficiali, e Pete Allor - membro del CVE board e cofondatore della CVE Foundation - ha riassunto il cambio di scenario con una frase memorabile: "Why wrestle the horse to the ground when I can use it bridled?". La CVE Foundation, nata come piano B di emergenza, sta riconsiderando il proprio ruolo proprio perché l'urgenza è rientrata. Ma rientrata non significa risolta.

Tre cose, lette a un anno di distanza, dovrebbero preoccupare chi gestisce vulnerability management per una PMI:

1. Il contratto MITRE-CISA resta opaco. Membri stessi del CVE board hanno chiesto ripetutamente accesso al testo del contratto rinnovato; MITRE ha rifiutato citando protezioni legali, e una richiesta FOIA separata è rimasta senza risposta. La fonte primaria di dati per la security globale è governata da un accordo che nemmeno chi siede nel board può leggere. Questo è strutturalmente fragile.
2. CISA stessa è in turbolenza. Il budget federale FY2026 prevede un taglio di circa 1.000 posizioni a CISA (un terzo della forza lavoro) e diversi milioni di dollari sulle attività di risk management e stakeholder engagement. L'agenzia opera senza un direttore confermato dal Senato da oltre un anno. Non è la condizione ideale per un partner di un programma critico globale.
3. La governance non è mai stata "globale". Il CVE board è stato espanso a 24 membri ma resta un organo consultivo: MITRE conserva l'autorità decisionale finale. Questo è il punto che la crisi del 2025 ha reso visibile a tutti - la "comunità CVE" non ha potere reale quando il finanziatore governativo decide diversamente.

Il programma CVE non è morto, ma è esposto. La differenza fra "esposto" e "in crisi acuta" è la presenza di un piano di rientro. Per una PMI il piano di rientro deve essere il tuo, non quello di MITRE.

EUVD: cosa è davvero, e perché non sostituisce CVE oggi

Il 13 maggio 2025 ENISA ha annunciato il lancio operativo di EUVD, il database europeo delle vulnerabilità previsto dalla Direttiva NIS2. La buona notizia: esiste, è gratuito, ha API pubbliche, ed è gestito da un'agenzia europea (non da un appaltatore privato di un governo extra-UE). Per un consulente che lavora con clienti soggetti a NIS2, è un riferimento istituzionale concreto da citare nei documenti di compliance, non più una promessa futura.

La cattiva notizia richiede un po' di sfumatura, e va detta. EUVD ha un proprio sistema di numerazione (EUVD-YYYY-NNNNN), ma le entry includono il CVE equivalente quando esiste - questo perché EUVD non è un sistema indipendente, è un downstream consumer del programma CVE per la maggior parte dei record (più i contributi dei CSIRT europei). Se MITRE smettesse domani di assegnare CVE ID, EUVD perderebbe la fonte di gran parte delle sue entry. I limiti operativi attuali, ben documentati nell'analisi di VulnCheck e nei comment di Bugcrowd su SecurityWeek, sono rilevanti per chi vuole automatizzare un workflow:

• L'API ha vincoli di performance e supporta male l'uso ad alto volume o automatizzato.
• Mancano metadati importanti: CWE, CPE, CVSS Source non sono ancora popolati per molti record.
• L'implementazione di EPSS (Exploit Prediction Scoring System) include modifiche di scoring che possono fuorviare i consumer downstream.

Aggiungiamo una distinzione che genera regolarmente confusione nei clienti: EUVD non è la stessa cosa del Single Reporting Platform (SRP) del Cyber Resilience Act, che diventerà obbligatorio per i manufacturer a settembre 2026 per la notifica di vulnerabilità attivamente sfruttate. Sono due piattaforme distinte: EUVD è un database di intelligence sotto NIS2, SRP è un canale di reporting obbligatorio sotto CRA. Se la tua PMI produce hardware o software con elementi digitali, da settembre 2026 dovrai usare SRP per notificare le vulnerabilità attivamente sfruttate sui tuoi prodotti. È un obbligo che entra nel piano di compliance NIS2/CRA che ho coperto nella mia guida ai rischi di non-compliance GDPR e NIS2 per le PMI italiane.

Conclusione operativa: EUVD oggi è un buon riferimento istituzionale per la documentazione di compliance, ma non è ancora una fonte primaria di vulnerability data per gli scanner automatici. Trattalo come una seconda fonte da incrociare con NVD/CVE, non come il sostituto.

Cosa cambia per la pipeline di vulnerability management di una PMI Laravel/Symfony

Per le PMI italiane su cui lavoro - tipicamente stack Laravel/Symfony, MySQL/PostgreSQL, infrastruttura su VPS unmanaged Hetzner/OVH/Aruba, deploy con Docker - la dipendenza dal sistema CVE è raramente diretta. È mediata da tool: composer audit, npm audit, Trivy per le immagini Docker, Dependabot/Renovate per le pull request, e talvolta Snyk o Mend per chi ha budget. Tutti questi tool si appoggiano in qualche misura a NVD (che a sua volta dipende da CVE), e quindi tutti hanno la stessa fragilità strutturale.

Il pattern operativo che ho consolidato negli ultimi 12 mesi sui clienti PMI è basato su tre principi: multipli source, fingerprinting locale, e separazione fra inventario e scanning. Quattro comandi diventano lo zoccolo duro: composer audit per le dipendenze PHP (Friends of PHP + GHSA + OSV.dev), osv-scanner per il cross-source su OSV.dev e deps.dev, trivy image con output CycloneDX per le immagini Docker, e un diff finale per misurare il drift fra build successive del SBOM.

composer audit --format=json > .security/composer-audit.json
osv-scanner scan source --recursive --format=sarif . > .security/osv.sarif
trivy image --format=cyclonedx my-app:latest > .security/sbom.cdx.json
diff -u .security/last-sbom.cdx.json .security/sbom.cdx.json | head -100

I quattro comandi insieme producono un quadro di vulnerabilità che incrocia almeno tre database diversi (OSV, GHSA, NVD), e costruiscono un SBOM in CycloneDX che diventa il tuo inventario locale. Il punto chiave è il SBOM: una volta che hai un Software Bill of Materials versionato in repo, sei in grado di rispondere a "quali dipendenze ho in produzione adesso?" senza dipendere da nessun database esterno. Quando un nuovo CVE/EUVD/GHSA esce, il tuo SBOM ti dice in 30 secondi se sei impattato, anche se la fonte primaria del CVE è temporaneamente irraggiungibile. Questo è il tipo di resilienza che una pipeline di DevSecOps integrata nel ciclo di sviluppo Laravel/Symfony deve garantire.

Tre cose pratiche da configurare in un repo Laravel "tipo" PMI:

1. Pin di tutte le dipendenze in composer.lock e attivazione di Dependabot/Renovate. Senza il lock file fisso e le PR automatiche di aggiornamento, ogni "controllo manuale" diventa cargo cult.
2. Composer audit obbligatorio in CI come quality gate. Una pull request che introduce una dipendenza vulnerabile nota viene bloccata. Il pattern di hardening completo lo trovi nella mia checklist di hardening Laravel/Symfony per NIS2 in 14 giorni.
3. SBOM versionato e committato. Sembra over-engineering per una PMI, costa 5 minuti di configurazione, e diventa la tua source of truth quando NVD/CVE è giù.

NIS2 art. 21 e la documentazione di vulnerability management

Per le PMI italiane che ricadono sotto NIS2 (settori essenziali e importanti elencati negli allegati I e II della direttiva), la gestione delle vulnerabilità non è più una "best practice" - è un obbligo documentato dall'art. 21 della direttiva, recepito in Italia con il D.Lgs. 138/2024. Quello che cambia rispetto al pre-NIS2 non è il fatto di gestire vulnerabilità (le aziende serie lo facevano già), ma la necessità di dimostrare che lo si fa, con processi tracciati, documentazione versionata, e tempi di reazione misurabili.

Per i clienti che mi chiedono "quale documento devo avere?", il pacchetto minimo che produco in fase di consulenza include:

• Policy di vulnerability management (1-2 pagine): definisce le fonti monitorate (NVD, EUVD, GHSA, CVE, vendor advisory specifici), la frequenza di scan, le soglie di severity per intervento e i tempi target di patch.
• Inventario asset e SBOM versionati (file in repo, aggiornati a ogni deploy): dimostra che sai cosa hai in produzione.
• Registro degli interventi su vulnerabilità (CSV o issue tracker dedicato): traccia ogni CVE valutato, l'esito (patch/accept/compensating control), e la motivazione tecnica.
• Piano di incident response (3-5 pagine, testato annualmente): definisce ruoli, escalation, comunicazioni esterne richieste da NIS2 art. 23 (notifica preliminare entro 24h, notifica iniziale entro 72h). Per la parte tecnica del primo intervento, ho costruito un piano di incident response Laravel/Symfony in 72 ore tarato proprio sui requisiti NIS2.

Senza questi documenti, il rischio non è solo la sanzione NIS2 (che può arrivare al 2% del fatturato globale per le entità essenziali). Il rischio operativo concreto è non sapere cosa fare nelle 72 ore successive a un incidente, che è esattamente il momento in cui la documentazione preparata in tempo di pace fa la differenza fra una notifica all'autorità competente fatta bene e una notifica tardiva che peggiora la posizione legale dell'azienda.

Strategia di vulnerability management resiliente: cinque mosse per il 2026

Tirando le somme di un anno di osservazione del sistema CVE post-crisi e dei progetti PMI che ho gestito nel frattempo, queste sono le cinque mosse concrete che applico a chi parte oggi.

1. Inventario prima di tutto. Senza SBOM aggiornato versionato in repo, la migliore intelligence sulle vulnerabilità è inutile. Genera SBOM CycloneDX a ogni deploy, committalo, fai diff fra build successive. Costo: 5 minuti di setup CI. Beneficio: resilienza completa ai disservizi delle fonti CVE.
2. Multi-source scanning, non single source. Configura almeno due tool che usano database diversi: composer audit (Friends of PHP / GHSA / OSV.dev), Trivy (NVD + Aqua), eventualmente osv-scanner (OSV.dev). Se uno è lento o down, gli altri continuano a funzionare.
3. Quality gate in CI. Una PR che introduce una dipendenza con vulnerability nota deve fallire. Senza enforcement automatico, l'audit diventa un report che nessuno legge.
4. Documentazione tracciata di accept/mitigate. Per ogni CVE che decidi di non patchare immediatamente, scrivi la motivazione tecnica e committala. Diventa parte del registro vulnerabilità richiesto da NIS2.
5. Monitoraggio continuo, non scan trimestrale. L'idea che il vulnerability management sia un "audit annuale" è morta. Va integrato nel deploy quotidiano, in pipeline, con alerting su novità rilevanti per il tuo SBOM. Su questo il mio articolo sul monitoraggio IT proattivo per anticipare problemi aziendali copre i pattern di base che applico ai clienti.

La crisi CVE del 16 aprile 2025 non era un evento isolato: era la prima manifestazione visibile di una fragilità strutturale che esiste da quando l'intera infrastruttura di vulnerability intelligence globale dipende da un singolo finanziatore. Un anno dopo, il finanziamento è stato rinnovato e il panico rientrato, ma nessuno dei problemi sottostanti è stato risolto: il contratto resta opaco, CISA è in turbolenza istituzionale, EUVD è promettente ma non pronto come sostituto, e il CVE board non ha potere decisionale reale. Per una PMI italiana sotto NIS2, l'unica risposta tecnicamente onesta è ridurre la dipendenza da una sola fonte e costruire una pipeline di vulnerability management che funzioni anche se domani uno dei pilastri viene a mancare. Se la tua azienda sta ancora gestendo le vulnerabilità con un foglio Excel manuale o con un singolo tool che si appoggia a un solo database, scopri come lavoro con le PMI sui temi di cybersecurity e compliance NIS2 - dieci anni di operations su stack Laravel/Symfony e infrastrutture VPS mi hanno insegnato che la resilienza non è uno slogan, è una pipeline che hai testato in tempo di pace. Se vuoi una valutazione del tuo attuale stato di vulnerability management e un piano di adozione concreto, contattami per una consulenza: in due settimane di lavoro ti consegno SBOM iniziale, configurazione multi-source scanning in CI, policy documentate e registro interventi pronto per un audit NIS2.