CRA Notifica vulnerabilità: ENISA SRP, orologio 24h/72h/14g

Il Regolamento sulla ciberresilienza dell'UE (Regolamento (UE) 2024/2847) trasforma la segnalazione delle vulnerabilità in un obbligo giuridico vincolante con scadenze precise per ogni fabbricante di prodotti con elementi digitali. Dall'11 settembre 2026, l'Articolo 14 impone la notifica delle vulnerabilità attivamente sfruttate e degli incidenti gravi tramite la piattaforma di segnalazione unica ENISA (SRP) con cadenza 24 ore / 72 ore / 14 giorni, accompagnata da una policy obbligatoria sulla divulgazione coordinata delle vulnerabilità (CVD) ai sensi dell'Allegato I Parte II. Questa pagina è il riferimento canonico: cosa richiede la legge, quando inizia ciascun conto, cosa deve contenere una policy CVD conforme, come VEX supporta l'obbligo di assenza di vulnerabilità sfruttabili note e quali sanzioni prevede l'Articolo 64 in caso di mancata segnalazione.

Cosa Richiede il CRA per la Segnalazione delle Vulnerabilità?

L'Articolo 14 del Regolamento sulla ciberresilienza è il nucleo operativo del regime di gestione degli incidenti del regolamento. Impone tre obblighi a ogni fabbricante di prodotti con elementi digitali immessi sul mercato UE:

1. Notificare qualsiasi vulnerabilità attivamente sfruttata nel prodotto simultaneamente al CSIRT coordinatore e a ENISA, con cadenza 24h / 72h / 14 giorni (Art. 14(1), 14(2)).
2. Notificare qualsiasi incidente grave che incida sulla sicurezza del prodotto con cadenza 24h / 72h / 1 mese (Art. 14(3), 14(4)).
3. Informare gli utenti del prodotto interessato in merito alla vulnerabilità o all'incidente e alle eventuali misure correttive, senza indebito ritardo (Art. 14(8)).

L'Articolo 14 si affianca a due altri obblighi trattati in questa pagina: la policy CVD obbligatoria ai sensi dell'Allegato I Parte II e il requisito di assenza di vulnerabilità sfruttabili note ai sensi dell'Allegato I Parte I, motivo per cui VEX è rilevante per un prodotto conforme al CRA. Nessuno di questi obblighi prevede una soglia dimensionale. Le PMI beneficiano di uno stretto sgravio sanzionatorio sulla scadenza delle 24 ore (si veda oltre), ma non sono esonerate dalla segnalazione.

La Piattaforma di Segnalazione Unica ENISA (SRP)

La SRP è il canale unico attraverso cui transita ogni notifica ai sensi dell'Articolo 14. Esiste perché l'Articolo 14(1) impone al fabbricante di notificare simultaneamente il CSIRT coordinatore e ENISA, e 27 notifiche separate sarebbero impraticabili. L'Articolo 16(1) affida la piattaforma alla responsabilità operativa di ENISA: "la gestione e la manutenzione quotidiane di tale piattaforma di segnalazione unica sono assicurate da ENISA."

Come funziona in pratica:

• Si invia una sola notifica tramite il terminale elettronico del CSIRT designato come coordinatore ai sensi dell'Articolo 14(7).
• La notifica raggiunge simultaneamente il CSIRT coordinatore e ENISA.
• Il CSIRT coordinatore diffonde quindi la notifica ai CSIRT degli altri Stati membri in cui il prodotto è immesso sul mercato (Art. 16). Quella diffusione secondaria è responsabilità del CSIRT, non del fabbricante.
• L'Articolo 16(2) consente a un CSIRT di ritardare la diffusione in circostanze particolarmente eccezionali. L'Articolo 16(6) consente un ritardo durante la divulgazione coordinata con il consenso del fabbricante.

Stato a maggio 2026: la SRP è prevista operativa entro l'11 settembre 2026, secondo la pagina ENISA SRP. L'implementazione è stata affidata tramite gara ENISA/2025/OP/0001 (contratto quadriennale) con chiusura a marzo 2025. Il fornitore non è stato reso pubblico. Nessun URL di registrazione è stato pubblicato. È atteso un periodo di test pre-lancio; le date specifiche non sono state annunciate. Gli atti di esecuzione ai sensi dell'Articolo 14 che fissano i formati e la struttura delle notifiche erano ancora in attesa al momento della redazione.

Cosa devono fare i fabbricanti ora: identificare il proprio CSIRT coordinatore ai sensi dell'Articolo 14(7), redigere e pre-approvare i template di segnalazione per le notifiche a 24h, 72h e 14 giorni, e definire una rota di escalation fuori orario. Template e processi non possono essere redatti mentre il conto delle 24 ore è in corso.

Scadenze di Segnalazione in Dettaglio

Vulnerabilità e incidenti gravi seguono entrambi un modello di segnalazione a stadi. I conti differiscono nella fase della relazione finale.

Tabella delle Scadenze di Segnalazione ai sensi dell'Articolo 14

Fase	Vulnerabilità (Art. 14(2))	Incidente grave (Art. 14(4))	Punto di partenza
Avviso preliminare	24 ore	24 ore	Il fabbricante ne viene a conoscenza
Notifica dettagliata	72 ore	72 ore	Il fabbricante ne viene a conoscenza
Relazione finale	14 giorni dalla disponibilità di una misura correttiva o di attenuazione	1 mese dalla notifica dell'incidente a 72 ore	Punto di partenza diverso per ciascun percorso
Informazione agli utenti	Senza indebito ritardo	Senza indebito ritardo	Ai sensi dell'Art. 14(8)

Contenuto di Ciascuna Notifica

Avviso preliminare (24 ore). Informazioni minime per allertare le autorità: identità del fabbricante, prodotto e versione interessati, breve descrizione, gravità iniziale, se lo sfruttamento è confermato o sospettato e un'indicazione della portata potenziale dell'impatto. L'avviso preliminare è un segnale, non un'analisi.

Notifica dettagliata (72 ore). A questa fase si applicano due obblighi distinti. La notifica di vulnerabilità a 72 ore ai sensi dell'Articolo 14(2)(b) riguarda le vulnerabilità attivamente sfruttate. La notifica di incidente a 72 ore ai sensi dell'Articolo 14(4)(b) riguarda gli incidenti gravi. In entrambi i casi la notifica espande l'avviso preliminare con dettagli tecnici, versioni e configurazioni interessate, metodo di sfruttamento (se noto), stato attuale della mitigazione, stima della timeline di rimedio, portata degli utenti noti interessati e qualsiasi coordinamento in corso con terze parti.

Relazione finale. Per le vulnerabilità, il conto dei 14 giorni parte "al più tardi 14 giorni dopo che una misura correttiva o di attenuazione è disponibile" (Art. 14(2)(c)), non dalla scoperta né dalla notifica a 72 ore. Per gli incidenti gravi, il conto di 1 mese è ancorato alla notifica dell'incidente a 72 ore ai sensi dell'Articolo 14(4)(c). La relazione finale copre la causa radice, la descrizione tecnica integrale, le azioni di rimedio intraprese, le misure di prevenzione attuate e la valutazione dell'impatto confermato.

1. Consapevolezza del fabbricante. Il conto delle 24 ore parte nel momento in cui si forma una ragionevole convinzione dello sfruttamento attivo.
2. + 24 ore. Avviso preliminare inviato tramite la ENISA SRP (Art. 14(2)(a)).
3. + 72 ore. Notifica dettagliata inviata con dettagli tecnici, versioni interessate e stato della mitigazione (Art. 14(2)(b)).
4. Misura correttiva o di attenuazione disponibile. Il conto dei 14 giorni per la relazione finale parte qui, non dalla scoperta.
5. + 14 giorni. Relazione finale inviata: causa radice, descrizione tecnica integrale, rimedio, impatto confermato (Art. 14(2)(c)).

Cosa Attiva l'Obbligo di Segnalazione?

L'Articolo 14 prevede due categorie che attivano l'obbligo.

1. Vulnerabilità Attivamente Sfruttate

Una vulnerabilità nel prodotto che:

• è nota al fabbricante (rilevata internamente o segnalata dall'esterno),
• è stata usata da un attore malevolo, e
• colpisce o potrebbe colpire gli utenti del prodotto.

Il CRA definisce una vulnerabilità attivamente sfruttata come quella in cui "un attore malevolo fa uso di una falla." Questo non coincide con la divulgazione pubblica, una proof-of-concept pubblicata o la dimostrazione di sfruttabilità da parte di un ricercatore. Il trigger è l'uso malevolo reale.

2. Incidenti Gravi

Incidenti di sicurezza che incidono sulla sicurezza del prodotto, compromettono l'ambiente di sviluppo in modo da influenzarne la sicurezza, causano un'interruzione diffusa del servizio agli utenti o determinano una compromissione su vasta scala.

Scenari da Segnalare e Scenari Non Segnalabili

Scenario	Da segnalare?	Motivazione
Un ricercatore segnala una vulnerabilità in forma riservata	No	Nessuna evidenza di sfruttamento; gestire tramite CVD
PoC pubblicata su GitHub	No	La pubblicazione non equivale a sfruttamento
Un cliente segnala attività coerente con la vulnerabilità	Sì	Soglia della ragionevole convinzione soddisfatta
Vulnerabilità rilevata come sfruttata in the wild	Sì	Uso malevolo attivo
Un componente nello SBOM ha una CVE nota sfruttata	Valutare	Segnalabile solo se lo sfruttamento colpisce il prodotto specifico (VEX rilevante)
Il prodotto è preso di mira da attori di minaccia nominati	Sì	Evidenza diretta di sfruttamento
Un malware generico sfrutta una classe di vulnerabilità presente nel prodotto	Valutare	Solo se la specifica implementazione è interessata

Lo Standard della "Ragionevole Convinzione"

La prova forense dello sfruttamento non è richiesta. Lo standard dell'Articolo 14 è la ragionevole convinzione basata sulle evidenze disponibili: pattern di accesso insoliti coerenti con tecniche di exploit note, segnalazioni di clienti di compromissione, threat intelligence che indica che il prodotto è preso di mira o rilevamento di codice exploit progettato per il prodotto. In caso di incertezza, segnalare. Un avviso preliminare anticipato che si rivela infondato è di gran lunga preferibile a una scadenza mancata per uno sfruttamento reale, e la notifica a 72 ore può aggiornare la valutazione.

Policy sulla divulgazione coordinata delle vulnerabilità (CVD): il legame con l'articolo 14

L'Allegato I, Parte II, punto 5 del Regolamento sulla cibersicurezza impone ai fabbricanti di «istituire e applicare una politica di divulgazione coordinata delle vulnerabilità». La policy CVD è il meccanismo operativo che trasforma le segnalazioni dei ricercatori esterni in un flusso di triage strutturato e che, quando il triage rileva uno sfruttamento attivo, fa partire in parallelo il contatore di segnalazione dell'articolo 14. L'obbligo si applica a ogni prodotto con elementi digitali, senza soglia dimensionale né esenzione per le PMI. Il livello minimo di pubblicazione è un URL pubblico più un file security.txt in /.well-known/security.txt (RFC 9116), affinché le segnalazioni siano individuabili dai ricercatori che il Regolamento intende canalizzare.

Per i contenuti della policy, le finestre di divulgazione, le clausole di safe harbour e i modelli di comunicazione con i ricercatori, si veda la guida CRA dedicata alla divulgazione coordinata delle vulnerabilità. Per come la CVD si colloca tra gli altri obblighi dell'Allegato I, Parte II (SBOM, remediation, aggiornamenti sicuri, fornitura a titolo gratuito), si veda la gestione delle vulnerabilità CRA. Questa pagina si concentra sulla cadenza di notifica dell'articolo 14 che scatta quando il triage conferma lo sfruttamento attivo.

VEX: Comunicare l'Applicabilità delle Vulnerabilità

L'Allegato I Parte I impone ai prodotti CRA di essere immessi sul mercato senza vulnerabilità sfruttabili note e con una configurazione sicura per impostazione predefinita. La scansione degli SBOM produce lunghi elenchi di CVE sui componenti, la maggior parte dei quali non è effettivamente sfruttabile nel prodotto specifico. VEX (Vulnerability Exploitability eXchange) è il meccanismo che trasforma quei risultati grezzi di scansione in una posizione difendibile "non interessato / interessato / corretto / in indagine" per ogni CVE, che è quanto il regolamento, gli standard armonizzati in sviluppo e gli appalti tedeschi ai sensi di BSI TR-03183 Parte 3 si aspettano.

Cos'è VEX

VEX è una dichiarazione strutturata e leggibile da macchina circa il fatto che una vulnerabilità in un componente riguardi effettivamente un prodotto specifico. Risponde alla domanda: "CVE-XXXX esiste nel nostro SBOM. Interessa il nostro prodotto, perché sì o perché no, e cosa deve fare l'utente?" I quattro stati principali sono:

Stato	Significato
not_affected	La vulnerabilità esiste nel componente ma non riguarda questo prodotto (percorso del codice vulnerabile non raggiungibile, funzione non chiamata, configurazione che mitiga, ecc.). È attesa una giustificazione.
affected	La vulnerabilità riguarda questo prodotto. Sono attesi azione e raccomandazione.
fixed	La vulnerabilità era presente ed è stata corretta in questa versione.
under_investigation	Stato non ancora determinato; valutazione in corso.

Collegamento con il CRA

VEX non è nominato nel testo del CRA, ma è lo strumento operativo alla base di tre clausole del regolamento:

• Allegato I Parte I, assenza di vulnerabilità sfruttabili note. Una dichiarazione VEX not_affected con una giustificazione documentata è l'evidenza che si è valutato un CVE e si è concluso che non si applica. Senza di essa, ogni CVE nello SBOM è una presunta esposizione.
• Allegato I Parte II, gestione delle vulnerabilità. VEX è la traccia di audit di come ogni CVE si è spostato da under_investigation a not_affected, affected o fixed nel tempo.
• Articolo 14, trigger di segnalazione. Una vulnerabilità contrassegnata come affected e nota per essere attivamente sfruttata è esattamente il trigger che avvia il conto delle 24 ore. Una vulnerabilità contrassegnata not_affected con una giustificazione solida non lo è.

Formati VEX

Due formati sono rilevanti in pratica. CycloneDX VEX è incorporato direttamente in uno SBOM CycloneDX sotto vulnerabilities[].analysis. CSAF VEX è un documento separato in CSAF 2.0 (il formato che BSI TR-03183 Parte 3 richiede per i bollettini di sicurezza e che i CERT tedeschi pubblicano e consumano per impostazione predefinita). Entrambi sono leggibili da macchina e soddisfano entrambi lo stesso ruolo operativo.

Un'asserzione VEX CycloneDX minimale:

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.5",
  "version": 1,
  "vulnerabilities": [
    {
      "id": "CVE-2027-XXXXX",
      "source": { "name": "NVD" },
      "analysis": {
        "state": "not_affected",
        "justification": "code_not_reachable",
        "detail": "The vulnerable function is not called in our implementation."
      },
      "affects": [{ "ref": "pkg:generic/openssl@3.0.12" }]
    }
  ]
}

La specifica CycloneDX 1.5 definisce sei stati di analisi (in_triage, exploitable, not_affected, false_positive, resolved, resolved_with_pedigree), un vocabolario a granularità più fine rispetto ai quattro di OpenVEX (not_affected, affected, fixed, under_investigation), sui quali si mappa. BSI TR-03183 Parte 3 si aspetta dichiarazioni VEX insieme agli SBOM per i prodotti allineati al CRA. Per il quadro completo su SBOM e BSI TR-03183, si veda la guida cluster SBOM.

Esenzioni per PMI e Obblighi Ridotti

L'Articolo 64(10) prevede uno stretto sgravio sanzionatorio per i fabbricanti più piccoli. Non esonera nessuno dalla segnalazione.

Le microimprese e le piccole imprese (definite come meno di 50 dipendenti e un fatturato annuo o totale di bilancio fino a 10 milioni di EUR; microimprese: meno di 10 dipendenti, 2 milioni di EUR) sono esonerate dalle sanzioni specificamente per il mancato rispetto delle scadenze dell'avviso preliminare di 24 ore ai sensi dell'Articolo 14(2)(a) e dell'Articolo 14(4)(a). L'esonero copre solo le sanzioni per la tempistica della scadenza delle 24 ore.

Ancora obbligatori, senza esonero PMI:

• La notifica dettagliata a 72 ore (Art. 14(2)(b) e 14(4)(b)).
• La relazione finale a 14 giorni per le vulnerabilità e a 1 mese per gli incidenti gravi.
• La policy CVD ai sensi dell'Allegato I Parte II.
• Tutti gli altri obblighi CRA, incluso il requisito di assenza di vulnerabilità sfruttabili note ai sensi dell'Allegato I Parte I.

Le medie imprese (fino a 250 dipendenti) non sono coperte dallo sgravio PMI in alcun modo. L'esonero è uno stretto sgravio sanzionatorio, non un regime di segnalazione ridotto.

Errori Comuni

• Attendere la certezza forense prima di avviare il conto. L'Articolo 14 usa lo standard della ragionevole convinzione. Attendere la prova farà mancare la scadenza.
• Confondere CVD e segnalazione ai sensi dell'Articolo 14. La segnalazione di un ricercatore è un input per il processo CVD; la segnalazione ai sensi dell'Articolo 14 scatta quando ci sono evidenze di sfruttamento attivo. La policy CVD deve contenere un gate esplicito per questo.
• Escalation a punto unico di guasto. Una sola persona autorizzata a segnalare, irraggiungibile un venerdì sera. Il conto delle 24 ore non si ferma.
• Primo contatto con il CSIRT coordinatore durante un incidente. Stabilire la relazione e il percorso di notifica adesso, mentre non c'è ancora nessun conto in corso.
• Nessuna policy CVD pubblicata. L'obbligo dell'Allegato I Parte II non è soddisfatto da un documento interno.
• Nessuna asserzione VEX. Ogni CVE nello SBOM è presunto sfruttabile finché non si dice diversamente. L'Allegato I Parte I è molto più difficile da difendere senza VEX.
• Trattare il lancio della SRP come un problema futuro. Template, rote di escalation e relazioni con i CSIRT devono essere in vigore prima di settembre 2026, non costruiti dopo.