Vulnerabilità segnalata vs sfruttata: la differenza da 15 milioni
Il preallarme di 24 ore non è dovuta per ogni vulnerabilità che arriva nella casella. È dovuta solo quando esistono prove attendibili che qualcuno l'abbia sfruttata, senza autorizzazione, in un sistema reale. Tutto ruota attorno a una riga scritta: la qualificazione dell'evento.
Dove nasce davvero l'obbligo
Il Cyber Resilience Act non ti chiede di segnalare le vulnerabilità. Ti chiede di segnalare le vulnerabilità attivamente sfruttate. La distinzione non è retorica: è scritta nella definizione stessa all'Art. 3(42), e da essa dipende l'intero orologio delle 24 ore dell'Art. 14.
Il presupposto non è l'esistenza di un difetto, né il fatto che qualcuno te ne abbia parlato. Il presupposto è la prova attendibile che un soggetto malintenzionato l'abbia usata, in un sistema, senza autorizzazione del proprietario. La divulgazione responsabile di un ricercatore, un paper accademico, una scansione automatica che segnala una libreria obsoleta: nessuno di questi, da solo, avvia l'orologio.
Il rischio corre nei due sensi
Notifichi troppo poco e violi l'obbligo. Notifichi tutto, indiscriminatamente, e paghi un prezzo diverso: perdi credibilità presso il CSIRT, sommergi il tuo team di depositi e bruci le ore che ti servirebbero sull'unica segnalazione che conta. Sovra-notificare non è la scelta prudente che sembra. È un modo più lento di sbagliare.
L'uscita da entrambi i rischi è la stessa, e non è glamour: una qualificazione motivata, decisa in fretta e messa per iscritto. Un «no» documentato è una difesa che puoi consegnare a un ispettore. Un «no» implicito — la segnalazione che hai deciso in silenzio di non depositare — è indistinguibile dalla negligenza quando qualcuno, mesi dopo, chiede perché non è partito nulla.
Tre casi, e la riga che scriveresti per ciascuno
La qualificazione si insegna meglio con gli esempi che con le definizioni. Eccone tre ricorrenti, con il ragionamento esatto che scriveremmo nel registro — non un verdetto, ma la prova e la conclusione che se ne trae.
Caso 1 — Email di un ricercatore con PoC
Un ricercatore di sicurezza scrive al tuo indirizzo di divulgazione. In allegato c'è un proof-of-concept che innesca in modo affidabile un buffer overflow sul firmware corrente. Non c'è alcuna affermazione, né alcuna prova, che qualcuno l'abbia usato contro un dispositivo reale di un cliente.
Segnalata, non sfruttata. Riga di registro: «Vulnerabilità confermata, PoC funzionante ricevuto da ricercatore esterno il [data]. Nessuna prova di sfruttamento in alcun sistema senza autorizzazione. Art. 3(42) non integrato → nessun preallarme Art. 14. Gestita nel processo di divulgazione coordinata; avviata la tempistica di correzione.»
Caso 2 — Prove da honeypot e log
Il tuo honeypot cattura un payload che sfrutta lo stesso overflow, e i log di produzione di due installazioni cliente mostrano il pattern di richiesta identico seguito da una connessione in uscita verso un host sconosciuto. Il comportamento corrisponde a uno sfruttamento attivo reale, contro sistemi che nessuno ha autorizzato.
Sfruttata. Deposita il preallarme. Riga di registro: «Prova attendibile di sfruttamento senza autorizzazione: payload honeypot + log di produzione corrispondenti su due siti, [timestamp]. Art. 3(42) integrato → preallarme Art. 14 depositata al CSIRT entro 24h da [ora della consapevolezza]. Programmate la notifica delle vulnerabilità a 72h e la relazione finale.»
Caso 3 — Lo scanner segnala una dipendenza obsoleta
Uno scanner notturno delle dipendenze segnala una CVE in una vecchia versione di una libreria inclusa nel tuo prodotto. Non c'è alcuna segnalazione di vulnerabilità nel tuo prodotto, nessun PoC contro la tua build, nessun segno di sfruttamento da nessuna parte. Solo un numero di versione sotto una soglia.
Nessuno dei due — ma documentalo. Riga di registro: «Segnalazione scanner sulla libreria [nome/versione], CVE [id]. Non ancora confermata come vulnerabilità sfruttabile nel nostro prodotto; nessuna prova di sfruttamento. Art. 3(42) non integrato → nessun obbligo Art. 14 oggi. Aperto il triage per confermare la raggiungibilità; se riguarda un componente di terzi, da valutare la segnalazione a monte ex Art. 13(6).»
Perché nel titolo c'è «15 milioni»
Gli obblighi di segnalazione degli Art. 13 e Art. 14 si collocano nella fascia sanzionatoria più alta del regolamento: fino a 15 milioni di euro, o al 2,5% del fatturato mondiale annuo totale dell'esercizio precedente, se superiore. La cifra non è un espediente per spaventare. È il tetto che il legislatore ha agganciato proprio ai doveri di gestione e notifica delle vulnerabilità.
Ciò che un'autorità valuta, in concreto, non è se hai indovinato. È se avevi un processo e l'hai applicato. Due aziende possono arrivare allo stesso «no» — una per silenzio, una con una voce di registro datata che cita l'Art. 3(42). Solo la seconda può dimostrarlo. La qualificazione non è la burocrazia attorno alla decisione; la qualificazione è la decisione.
Il test in una riga Esistono prove attendibili che un soggetto malintenzionato l'abbia sfruttata, in un sistema, senza autorizzazione? Se sì → preallarme 24h. Se no → un «no» scritto e motivato.
Questo articolo descrive la nostra lettura del testo normativo e non costituisce parere legale.
Classe di rischio