Blog
NIS2Vulnerabilità NoteENISA Threat LandscapeEvidenze Audit

Audit NIS2 al 30 giugno: il 21,3% di vulnerabilità note diventa una constatazione

Il 30 giugno 2026 chiude il primo ciclo di audit NIS2. Il 21,3% di intrusioni via vulnerabilità note rilevato da ENISA smette di essere uno slide e diventa un finding.

Zero Hunt Research··8 min di lettura

Tra cinque settimane si chiude il primo ciclo di audit NIS2. In tutta l'Unione, le autorità di vigilanza inizieranno a valutare i soggetti essenziali e importanti non sui PDF di policy ma sulla capacità di produrre evidenze firmate, datate al momento in cui sono state generate, che dimostrino che le misure di gestione del rischio cibernetico hanno effettivamente operato durante il periodo di riferimento. La prima constatazione che la maggior parte di loro si vedrà recapitare è già mappata nell'ENISA Threat Landscape 2025: il 21,3% delle intrusioni contro organizzazioni europee continua a sfruttare vulnerabilità note e non patchate. È la seconda categoria di accesso iniziale dopo il phishing, ed è quella in cui la distanza tra policy e realtà operativa è ora giuridicamente misurabile.

Il dato ENISA, nel contesto

Il 21,3% deriva dall'analisi ENISA di 4.875 incidenti osservati tra il 1° luglio 2024 e il 30 giugno 2025. Phishing e varianti coprono circa il 60% degli accessi iniziali. Compromissione della supply chain è al 10,6%. La pubblica amministrazione è il settore più colpito (38% degli incidenti mappati), seguita dal trasporto — in particolare marittimo e logistico. Come Security Affairs sintetizza il report, lo sfruttamento di vulnerabilità "resta un pilastro dell'accesso iniziale, con avversari che spesso weaponizzano falle appena divulgate nel giro di pochi giorni".

L'ultima clausola è il problema operativo. Il 21,3% non è fatto di CVE oscuri. È fatto di CVE che avevano una patch, un bollettino del regolatore e una voce in CISA KEV — e che il programma di vulnerability management della vittima non aveva chiuso, o aveva chiuso troppo lentamente.

Tre esempi concreti degli ultimi sette giorni illustrano la cadenza:

  • Il 20 maggio 2026 CISA ha aggiunto sette CVE a KEV in un singolo batch, tra cui CVE-2026-41091 (elevazione di privilegi in Microsoft Defender) e una serie di CVE Microsoft e Adobe vintage 2008–2010 ancora weaponizzati nel 2026.
  • Il 21 maggio CISA ha aggiunto due ulteriori voci a KEV, inclusa CVE-2026-34926 in Trend Micro Apex One — un directory traversal nel medesimo EDR che molti soggetti usano per soddisfare l'art. 21 NIS2.
  • Nella stessa settimana il bollettino ACN ha segnalato sfruttamento attivo di CVE-2026-20127, un authentication bypass in Cisco Catalyst SD-WAN, sopra il chain CVE-2026-20182 divulgato in apertura di maggio.

Ognuna di queste ha una patch. Ognuna, il 30 giugno, sarà esaminata da un auditor come una domanda aperta: stavi scansionando entro poche ore dalla divulgazione, e che cosa hai prodotto come prova?

Perché "patch entro 30 giorni" non sopravvive più a un audit

L'impegno più comune di vulnerability management nei documenti di policy recita qualche variazione di i CVE critici vengono patchati entro 30 giorni, gli alti entro 60. Le leggi di recepimento NIS2 in ogni Stato membro che le ha finalizzate convertono questo da bersaglio auto-dichiarato a bersaglio vigilato. L'autorità di vigilanza è legittimata a chiedere:

  1. Come hai saputo del CVE entro 24 ore dalla divulgazione? — ossia mostra il feed, il timestamp, il ticket aperto.
  2. Dove era l'asset interessato nel tuo inventario? — ossia mostra il record CMDB e il suo campo versione al momento.
  3. La patch è atterrata? — ossia mostra la scansione che prova che il binario o l'immagine container non è più vulnerabile, datata dopo la patch.
  4. Hai validato l'exploitability dopo la patch? — ossia mostra il test, datato dopo la patch, che conferma che un PoC funzionante non riesce più.

Tre domande su quattro sono di inventario e ticketing e la maggior parte dei programmi maturi sa risponderle. La quarta è dove vive il 21,3%. Quasi nessuna organizzazione ri-testa di routine l'exploitability post-patch al di fuori della finestra del pentest esterno annuale o trimestrale, e quella finestra è ormai del tutto fuori cadenza rispetto alla velocità con cui gli avversari weaponizzano.

Auditor in una revisione NIS2 nel Q3 2026: "Hai patchato CVE-2026-XXXX al giorno 9. Bene. Cosa hai fatto al giorno 10 per verificare che la patch funzionasse in produzione, sull'asset reale, contro la exploit chain reale?"

Se la risposta è "ci siamo fidati del bollettino del vendor e abbiamo aspettato il prossimo pentest trimestrale", quello entra nella colonna dei finding. Il bollettino non è la prova; il secondo test sì.

Cosa gli auditor vogliono effettivamente vedere

Diversi regolatori di Stato membro hanno iniziato a pubblicare cosa considerano evidenza accettabile sotto la propria legge di recepimento NIS2, e il pattern converge fra NBB belga, BSI tedesca, DNB olandese e ACN italiana. L'avviso AFM di maggio 2026 sull'incident reporting DORA — regolamento sorella, ma stessa cultura di vigilanza — telegrafa lo spostamento più ampio: il clock parte alla consapevolezza, non alla certezza forense, e "stiamo indagando" non è una difesa.

Tradotto in vulnerability management NIS2, i regolatori chiedono:

  • Scansione esterna continua di tutti gli asset esposti, con il flusso di evidenze dello scanner (non la sua dashboard) come artefatto di audit.
  • Validazione, non solo detection. Uno scanner che riporta "CVE-X è presente" è ormai considerato il minimo. Un tentativo di exploit — riuscito o no — contro l'asset patchato è ciò che chiude il loop.
  • Evidenze firmate crittograficamente del momento in cui ogni scansione è girata, di cosa ha prodotto e chi l'ha vista. Export CSV auto-asseriti non sono più sufficienti su finding contestati.
  • Tracciabilità cross-framework. La stessa evidenza deve essere riutilizzabile per ISO 27001 Annex A.8.8 (gestione delle vulnerabilità), SOC 2 CC7.1 e — per i soggetti finanziari in-scope — DORA art. 6. Un auditor che deve leggere tre report diversi per un singolo finding scriverà un'osservazione.

La sintesi è che la classe documentale di evidenza (PDF firmati di un pentest trimestrale) viene superata dalla classe operativa (un flusso continuo di eventi firmati).

Dove si concentra il 21,3%

Il 21,3% non è distribuito uniformemente. Tre concentrazioni contano per i soggetti NIS2:

Settore Pattern di attacco primario NIS2 Annex
Pubblica amministrazione CVE su appliance perimetrali e identity esposti Annex I
Trasporto (marittimo, logistico, freight) CVE Office e document-handling in spear-phishing chain Annex I
Sanità Software clinico legacy e CVE EDR Annex I
Manifatturiero OT/ICS CVE su HMI e engineering station su reti piatte Annex II
Infrastruttura digitale (cloud, DNS) Effetto a cascata — footprint piccolo, blast radius grande Annex I

ENISA ha esplicitamente segnalato intrusion set di matrice russa, in particolare APT28, concentrati su trasporto aereo, logistica e freight, soprattutto in Germania, Francia e Belgio. L'analisi Trellix di gennaio 2026 documenta l'actor che weaponizza CVE-2026-21509 entro 24 ore dalla divulgazione pubblica e mescola il traffico di command-and-control in storage cloud legittimo (filen.io). È il pattern manuale del 21,3%: CVE noto, patch pubblica disponibile, sfruttato su scala prima che la finestra di patch chiuda.

Quando un auditor guarderà un operatore di trasporto il 1° luglio, la domanda non sarà teorica. Sarà: mostrami cosa hai fatto fra il 28 e il 31 gennaio 2026.

Validazione continua come evidenza audit-grade

Il mismatch fra cadenza dell'avversario (ore) e cadenza dell'assessment (trimestrale o annuale) non è più una preferenza di tooling. L'art. 21(2)(g) NIS2 richiede "politiche e procedure relative all'uso della crittografia" insieme alla gestione e divulgazione delle vulnerabilità, e gli atti di esecuzione di diversi Stati membri sono sempre più espliciti sul fatto che il pentest periodico da solo non assolve l'obbligo quando il threat landscape si muove più velocemente della cadenza.

Ciò che lo assolve, per consenso emergente fra le guide dei regolatori:

  • Ricognizione automatizzata continua e validazione di tutti gli asset in-scope, non solo uno snapshot al momento dell'audit.
  • Ri-validazione triggherata dal change: un nuovo asset sul perimetro o un cambio configurazione deve scatenare un tentativo di exploit fresco entro ore, non settimane.
  • Un flusso di evidenze firmato al momento della scrittura, in modo che la chain of custody sia verificabile da un auditor o, nel caso peggiore, da un tribunale.
  • Mapping cross-framework, così che lo stesso finding soddisfi NIS2, ISO 27001, SOC 2 e DORA simultaneamente, anziché produrre tre set di evidenze paralleli.

La domanda giuridica che NIS2 pone a un CISO non è più avevi un pentest report?. È puoi ricostruire, in evidenze, cosa sapevi, quando lo sapevi e cosa hai testato?. Il 21,3% è la sacca che la maggior parte dei programmi sta per scoprire di non poter ricostruire.

Dove si inserisce Zero Hunt

Zero Hunt è stato costruito specificamente contro questa sacca. Il motore di compliance mappa continuativamente ogni scansione, finding e remediation contro 32 framework regolatori, inclusi NIS2 e gli obblighi del Titolo 13, con report firmati ECDSA e chain of custody by construction — la classe operativa di evidenza verso cui i regolatori stanno convergendo. Lo scoring pesato per severità e il mapping cross-framework dei controlli fanno sì che un singolo finding validato soddisfi l'obbligo dell'art. 21 NIS2, il controllo ISO 27001 Annex A.8.8 e, per i soggetti finanziari in-scope, DORA art. 6 in un solo bundle, non tre.

Quel flusso di evidenze è alimentato dallo swarm generativo di 10 agenti AI di Zero Hunt, che gira continuativamente on-prem contro il perimetro del cliente. Quando un nuovo CVE atterra su CISA KEV, la exploit chain dello swarm viene riscritta da un LLM locale e testata contro l'asset reale, in una sandbox effimera, entro l'ora — chiudendo la sacca del 21,3% con un tentativo di exploit datato che l'auditor può verificare, non solo un risultato di scanner. Trust Center esporta il bundle on demand per il ciclo di audit del 30 giugno. I deployment air-gap producono le stesse evidenze senza alcun callback al cloud, dettaglio che pesa per gli operatori di pubblica amministrazione e difesa più esposti al 21,3%.

La scadenza del 30 giugno è un forcing function. È anche la prima volta nella regolazione cyber dell'UE che l'evidenza operativa supera per legge l'evidenza documentale. Per i programmi ancora architettati intorno al pentest report annuale, le prossime cinque settimane sono brevi.