L'Allegato I Parte II, lettera 5) del Regolamento sulla ciberresilienza dell'UE (Regolamento (UE) 2024/2847) impone a ogni fabbricante di istituire e applicare una politica di divulgazione coordinata delle vulnerabilità (CVD), e l'Articolo 13(17) richiede un unico punto di contatto raggiungibile da esseri umani per le segnalazioni di vulnerabilità. Non esistono soglie dimensionali. Questa pagina illustra cosa deve contenere la politica, come pubblicare il canale di contatto e come la CVD si interseca con la segnalazione ai sensi dell'Articolo 14 e con il più ampio framework dell'Allegato I Parte II.
Sintesi
- La politica CVD è obbligatoria ai sensi dell'Allegato I Parte II, lettera 5): deve essere scritta, pubblicata e applicata, senza soglie dimensionali.
- L'Articolo 13(17) richiede un unico punto di contatto affinché gli utenti possano segnalare le vulnerabilità; il canale non può essere limitato a strumenti automatizzati.
security.txt(RFC 9116) è la convenzione de facto per pubblicare il contatto, ma il Regolamento sulla ciberresilienza non impone un formato specifico.- CVD non è la segnalazione ai sensi dell'Articolo 14: la CVD disciplina il rapporto con i segnalatori; l'Articolo 14 è il contatore regolatorio verso ENISA e il CSIRT coordinatore quando una vulnerabilità viene attivamente sfruttata.
- La divulgazione pubblica delle vulnerabilità corrette è obbligatoria ai sensi dell'Allegato I Parte II, lettera 4), con una stretta deroga per i casi in cui il rischio di sicurezza della pubblicazione supera il beneficio fino a che gli utenti abbiano avuto la possibilità di applicare la patch.
- Si applicano sanzioni di primo livello: fino a €15.000.000 o al 2,5% del fatturato mondiale annuo totale ai sensi dell'Articolo 64(2), se superiore.
I quattro pilastri che definiscono una postura CVD conforme al Regolamento sulla ciberresilienza: il mandato della politica, l'obbligo di contatto, la convenzione di pubblicazione e il massimale delle sanzioni.
Cosa richiede effettivamente il Regolamento sulla ciberresilienza per la CVD
L'Allegato I Parte II, lettera 5) è breve. Testo integrale del Regolamento (UE) 2024/2847:
(5) istituire e applicare una politica di divulgazione coordinata delle vulnerabilità;
Quella singola frase contiene quattro componenti operative, ciascuna delle quali può non essere rispettata in modo diverso nella pratica:
Significa che esiste una politica scritta e accessibile. Un'abitudine interna non documentata di smistare le email security@ non costituisce una politica.
Significa che la politica è operativa, non soltanto pubblicata. Le scadenze per i riscontri, gli impegni di triage e le condizioni di divulgazione previste nel documento devono essere rispettati nella pratica. Una politica che promette un riscontro entro 72 ore ma impiega sistematicamente tre settimane non è applicata.
È la direzione implicita che la politica deve servire. L'Allegato I Parte II, lettera 6) la esplicita: i fabbricanti devono "facilitare la condivisione di informazioni sulle potenziali vulnerabilità", "anche fornendo un indirizzo di contatto".
Non figura nel testo del Regolamento sulla ciberresilienza. Il considerando 76 inquadra la CVD come un processo di segnalazione strutturato e cita i programmi bug-bounty come incentivo alle segnalazioni; non codifica la protezione legale né la riduzione del rischio per i ricercatori. La norma deriva dalla prassi del settore: ISO/IEC 29147, le linee guida ENISA e le raccomandazioni dei CSIRT nazionali trattano la clausola di safe harbour per la ricerca in buona fede come standard CVD.
Per il più ampio framework dell'Allegato I Parte II (gli otto obblighi numerati di cui la CVD è uno), si consulti la gestione delle vulnerabilità CRA.
L'unico punto di contatto (Articolo 13(17))
L'Articolo 13(17) si affianca all'Allegato I Parte II, lettera 5) e gli conferisce forma operativa. Testo integrale:
- Ai fini del presente regolamento, i fabbricanti designano un unico punto di contatto per consentire agli utenti di comunicare direttamente e rapidamente con loro, anche al fine di facilitare la segnalazione delle vulnerabilità del prodotto con elementi digitali.
I fabbricanti si assicurano che l'unico punto di contatto sia facilmente identificabile dagli utenti. Includono inoltre l'unico punto di contatto nelle informazioni e nelle istruzioni per l'utente di cui all'Allegato II.
L'unico punto di contatto consente agli utenti di scegliere il mezzo di comunicazione preferito e non limita tale mezzo a strumenti automatizzati.
Tre regole da interiorizzare:
- Facilmente identificabile. Il contatto deve essere visibile nelle informazioni sul prodotto, nelle istruzioni di accompagnamento dell'Allegato II e sul sito web pubblico. Un contatto raggiungibile solo leggendo l'informativa sulla privacy non supera questo test.
- Canali multipli. "Scegliere il mezzo di comunicazione preferito" significa almeno due. Una casella di posta
security@funzionante e un modulo web, con una chiave PGP disponibile per le segnalazioni sensibili, costituiscono il punto di partenza realistico. - Nessun intake solo automatizzato. "Non limita tale mezzo a strumenti automatizzati" esclude una postura in cui l'unico indirizzo raggiungibile sia
security-noreply@o un chatbot che chiude i ticket senza revisione umana.
Il Regolamento sulla ciberresilienza non richiede di separare il supporto agli utenti e l'intake di vulnerabilità, ma la maggior parte dei fabbricanti gestisce una casella di posta dedicata alla sicurezza, instradata al team di sicurezza del prodotto, per mantenere la CVD distinta dal supporto generale.
Pubblicare la propria politica CVD: security.txt e altro
Il Regolamento sulla ciberresilienza non menziona security.txt, RFC 9116 o alcun formato di pubblicazione specifico. Richiede un canale di contatto "facilmente identificabile" e una politica CVD "istituita e applicata". All'interno di questi vincoli, il settore ha convergito su security.txt come convenzione de facto.
Campi RFC 9116 che vale la pena pubblicare:
| Campo | Scopo |
|---|---|
Contact: |
Uno o più canali di segnalazione. Almeno uno è obbligatorio. |
Expires: |
Data dopo la quale il file è obsoleto. Obbligatorio secondo RFC 9116. |
Encryption: |
Chiave pubblica (PGP, S/MIME) per le segnalazioni riservate. |
Acknowledgments: |
Pagina che accredita i ricercatori per le divulgazioni passate. |
Policy: |
Link al documento completo della politica CVD. |
Preferred-Languages: |
Lingue in cui opera il team di triage. |
Canonical: |
URL dove si prevede che il file risieda. |
Dove pubblicarlo. La posizione convenzionale è https://example.com/.well-known/security.txt, servito tramite HTTPS. RFC 9116 accetta anche https://example.com/security.txt come fallback, ma well-known è preferito.
Oltre il security.txt. Lo standard "facilmente identificabile" implica che il contatto debba comparire anche nella pagina di supporto o contatto del prodotto, nelle istruzioni di accompagnamento dell'Allegato II, nella documentazione per sviluppatori dei prodotti API e in una pagina pubblica della politica CVD a cui i ricercatori possano collegarsi.
I fabbricanti che gestiscono programmi di bug bounty aggiungono tipicamente HackerOne, Bugcrowd o Intigriti come canali di intake aggiuntivi. Questi soddisfano l'obbligo di "facilitare le segnalazioni" (Allegato I Parte II, lettera 6)) e quello di "non limitato a strumenti automatizzati" (Articolo 13(17)) solo se aperti a ricercatori esterni con risposta umana. Un bounty privato su invito non soddisfa di per sé il requisito del contatto pubblico e deve coesistere con un canale pubblico.
Ricevere e smistare le segnalazioni di vulnerabilità
Una politica CVD è applicata attraverso un flusso documentato di intake e triage. I meccanismi riportati di seguito non sono prescritti dal Regolamento sulla ciberresilienza, ma rappresentano come appare una politica applicabile nella pratica.
| Fase | Cosa fa una politica applicabile | Errore comune |
|---|---|---|
| Riscontro | Confermare la ricezione entro lo SLA pubblicato. Il punto di riferimento del settore è 72 ore; molte politiche si impegnano a 24 o 48 ore per le segnalazioni ad alta gravità. Ciò che si pubblica è ciò che si fa. | "Risponderemo tempestivamente" è inapplicabile di per sé. |
| Triage | Validare (riproducibile su una versione supportata), valutare la gravità (CVSS v3.1 o v4.0 con aggiustamenti ambientali, si veda la valutazione della gravità), valutare la sfruttabilità (exploit noto, PoC pubblico o evidenza in circolazione, che è il gate per l'Articolo 14) e delimitare le versioni interessate tramite l'SBOM. | Chiudere come "non riproducibile" senza indicare il range di versioni testato. |
| Rapporto con il ricercatore | Pubblicare tre elementi: una dichiarazione di safe harbour per la ricerca in buona fede nell'ambito definito; gli elementi fuori ambito (dati di produzione, ingegneria sociale, denial-of-service sull'infrastruttura live); e le aspettative di divulgazione (finestra di embargo, condizioni di fix, credito). Embargo tipico: fino alla pubblicazione della patch, con un termine massimo di 90 giorni. | Riservarsi il diritto di intraprendere azioni legali contro ricerche nell'ambito definito, il che compromette il canale. |
| Chiudere il cerchio | Ogni segnalazione riceve una risposta finale: corretta (con advisory e CVE), duplicata, non corretta (con motivazione) o fuori ambito. | Rispondere una volta e sparire: la ragione più comune per cui le politiche CVD non appaiono applicate dall'esterno. |
Coordinamento con ENISA e i ricercatori esterni
L'intake CVD e la segnalazione ENISA ai sensi dell'Articolo 14 sono obblighi distinti con destinatari diversi. La politica CVD disciplina il rapporto con il segnalatore. L'Articolo 14 disciplina la notifica regolatoria del fabbricante a ENISA e al CSIRT coordinatore. I due processi scorrono in parallelo e si attivano in modo diverso.
Quando una segnalazione CVD diventa un trigger dell'Articolo 14. L'Articolo 14(1) impone ai fabbricanti di notificare "qualsiasi vulnerabilità attivamente sfruttata" tramite l'SRP. L'Articolo 14(2) stabilisce la cadenza: allerta precoce a 24 ore, notifica a 72 ore e rapporto finale entro 14 giorni dalla disponibilità di una misura correttiva. Il trigger è "attivamente sfruttata", non "segnalata". Un intake CVD con una proof-of-concept funzionante non è di per sé un trigger dell'Articolo 14; lo diventa quando esiste una ragionevole convinzione che un attore malevolo abbia usato la falla contro un obiettivo reale. Per gli incidenti gravi ai sensi dell'Articolo 14(3) e 14(4), la cadenza è 24 ore, 72 ore, poi un rapporto finale entro un mese dalla notifica delle 72 ore. I due flussi condividono le fasi iniziali e divergono sulla tranche del rapporto finale. Non si devono collassare in un unico schema "24h/72h/14g". Si veda la segnalazione ai sensi dell'Articolo 14 CRA.
ENISA e CSIRT designati come coordinatori. L'Articolo 14(7) richiede la trasmissione tramite l'SRP usando il punto di accesso elettronico del CSIRT designato come coordinatore nello Stato membro del principale stabilimento del fabbricante. Il considerando 76 fornisce la cornice più ampia: i fabbricanti possono ricevere segnalazioni direttamente, o indirettamente tramite un CSIRT designato come coordinatore ai sensi dell'Articolo 12(1) della Direttiva (UE) 2022/2555 (NIS2). Per i meccanismi di onboarding all'SRP, si veda l'onboarding ENISA SRP.
Coordinamento con i ricercatori. Quando un ricercatore propone un embargo mentre si sviluppa il fix, si documenta la finestra concordata e la si rispetta. Quando il ricercatore si rifiuta o pubblica prima del previsto, la politica CVD deve indicare come si risponde, tipicamente accelerando l'advisory e la patch.
Tempistiche di divulgazione pubblica
La divulgazione pubblica di una vulnerabilità corretta non è facoltativa ai sensi del Regolamento sulla ciberresilienza. L'Allegato I Parte II, lettera 4) impone ai fabbricanti, "una volta reso disponibile un aggiornamento di sicurezza", di "condividere e divulgare pubblicamente le informazioni sulle vulnerabilità corrette, inclusa una descrizione delle vulnerabilità, le informazioni che consentono agli utenti di identificare il prodotto con elementi digitali interessato, gli impatti delle vulnerabilità, la loro gravità e informazioni chiare e accessibili che aiutano gli utenti a rimediare alle vulnerabilità". Lo stesso punto consente un ritardo "in casi debitamente giustificati, qualora i fabbricanti ritengano che i rischi per la sicurezza della pubblicazione superino i benefici per la sicurezza", ma solo "fino a quando agli utenti non sia stata data la possibilità di applicare la patch pertinente".
Finestre di embargo. Lo standard de facto del settore è 90 giorni dalla segnalazione alla divulgazione pubblica, misurati dalla data in cui il fabbricante è stato notificato per la prima volta. Project Zero, CERT/CC e la maggior parte dei CSIRT nazionali operano su o vicino a questo punto di riferimento. Per le vulnerabilità attivamente sfruttate la finestra si riduce tipicamente a giorni, poiché l'Articolo 14(2)(c) richiede un rapporto finale entro 14 giorni dalla disponibilità di una misura correttiva.
Formato della divulgazione pubblica. Un advisory conforme al Regolamento sulla ciberresilienza deve contenere, come minimo, un ID CVE, una descrizione chiara, il prodotto e il range di versioni interessati, la gravità (punteggio base CVSS), l'impatto, la soluzione e il credito dove il segnalatore ha acconsentito a essere nominato. CSAF (Common Security Advisory Framework) è il formato machine-readable che la maggior parte dei CSIRT nazionali e il database delle vulnerabilità di ENISA si aspettano.
Il ritardo "debitamente giustificato" della lettera 4) è ristretto. Consente di trattenere i dettagli pubblici fino a quando gli utenti possono applicare la patch; non consente fix silenziosi che non vengono mai pubblicati. Un fabbricante che pubblica una patch e non descrive mai cosa ha corretto viola la lettera 4) indipendentemente dall'intento.
Errori comuni
| Errore | Perché non supera il test del Regolamento sulla ciberresilienza |
|---|---|
| Minacce legali contro ricercatori in buona fede | Viola "applicare una politica di divulgazione coordinata delle vulnerabilità" (Allegato I Parte II, lettera 5)) e scoraggia il canale di intake che la lettera 6) richiede. |
| Nessun canale di contatto pubblico, solo un portale interno con login | Non supera il test "facilmente identificabile" dell'Articolo 13(17) e della lettera 6) dell'Allegato I Parte II "fornendo un indirizzo di contatto". |
Autorisponditore security-noreply@ senza triage umano |
L'Articolo 13(17) vieta di limitare la comunicazione a strumenti automatizzati. |
| Confermare la ricezione e non rispondere più | La politica è "istituita" ma non "applicata". L'Allegato I Parte II, lettera 5) richiede entrambe. |
| Chiudere le segnalazioni come "non corrette" senza motivazione | Indistinguibile dall'ignorare la segnalazione dall'esterno; i ricercatori reagiscono pubblicando. |
| Raggruppare le correzioni di sicurezza in release di funzionalità che gli utenti rinviano | Viola l'Allegato I Parte II, lettera 2): gli aggiornamenti di sicurezza devono essere separabili dagli aggiornamenti funzionali "ove tecnicamente fattibile". |
| Correggere silenziosamente senza advisory | Viola l'obbligo di divulgazione pubblica dell'Allegato I Parte II, lettera 4). |
| Trattare l'intake CVD come la trasmissione ENISA dell'Articolo 14 | Destinatari diversi, obblighi diversi. La CVD non esonera dall'Articolo 14, e l'Articolo 14 non esonera dalla CVD. |
Domande Frequenti
Le piccole imprese hanno bisogno di una politica CVD ai sensi del Regolamento sulla ciberresilienza?
Sì. L'obbligo di politica CVD non prevede soglie dimensionali. Si applica a ogni fabbricante che immette sul mercato dell'UE un prodotto con elementi digitali, indipendentemente dal numero di dipendenti o dal fatturato. Le microimprese e le piccole imprese beneficiano di un'esenzione ristretta sui termini di 24 ore dell'Articolo 14 ai sensi dell'Articolo 64(10)(a), che copre sia l'Articolo 14(2)(a) per le vulnerabilità attivamente sfruttate sia l'Articolo 14(4)(a) per gli incidenti gravi. L'esenzione riguarda solo le sanzioni su quelle scadenze, non l'obbligo sostanziale, e non si estende alle medie imprese. (Allegato I Parte II punto 5; Articolo 64(10)(a); Articolo 3(19).)
Il `security.txt` è obbligatorio ai sensi del Regolamento sulla ciberresilienza?
No. Il Regolamento sulla ciberresilienza non menziona security.txt o RFC 9116. Impone un unico punto di contatto "facilmente identificabile" e un indirizzo di contatto per le segnalazioni di vulnerabilità. security.txt è la convenzione de facto usata per soddisfare tali obblighi perché è il primo posto controllato dagli scanner automatici e dalla maggior parte dei ricercatori, ma un contatto pubblicato in modo prominente su una pagina pubblica dedicata alla sicurezza e nelle istruzioni dell'Allegato II è anch'esso conforme. Il requisito cogente è un canale pubblicato, funzionante e raggiungibile da esseri umani; il formato è una scelta. (Articolo 13(17); Allegato I Parte II punto 6; RFC 9116.)
L'intake CVD può coincidere con la trasmissione ENISA dell'Articolo 14?
No. Si tratta di destinatari diversi e obblighi diversi. L'intake CVD è il canale attraverso cui i ricercatori esterni e gli utenti segnalano le vulnerabilità al fabbricante. La trasmissione ai sensi dell'Articolo 14 è la notifica regolatoria del fabbricante a ENISA e al CSIRT coordinatore, effettuata tramite la Piattaforma Unica di Segnalazione ENISA. Un ricercatore non trasmette all'SRP; lo fa il fabbricante. Confondere i due porta a non rispondere a un ricercatore (violazione CVD) o a non notificare ENISA quando lo sfruttamento è confermato (esposizione a sanzioni di primo livello). (Articolo 14(1) e 14(7); Articolo 16; Articolo 64(2).)
Cosa accade quando un ricercatore esterno segnala una vulnerabilità attivamente sfruttata?
Due contatori partono in parallelo. Il processo CVD disciplina il rapporto con il ricercatore: confermare la ricezione, fare il triage, concordare un embargo, pubblicare un fix, pubblicare un advisory, accreditare il segnalatore. Il processo dell'Articolo 14 disciplina il rapporto con il regolatore: un'allerta precoce di 24 ore a ENISA e al CSIRT coordinatore, una notifica di 72 ore e un rapporto finale entro 14 giorni dalla disponibilità di una misura correttiva. Il contatore delle 24 ore parte nel momento in cui il fabbricante viene a sapere che lo sfruttamento è attivo, il che può coincidere con il momento in cui le prove del ricercatore rendono credibile tale conclusione. Attendere la certezza forense farà mancare la scadenza. I due processi scorrono in parallelo e si concludono su superfici diverse. (Articolo 14(1) e 14(2); Allegato I Parte II punto 5.)
La politica CVD deve offrire un safe harbour legale ai ricercatori?
No, il Regolamento sulla ciberresilienza non richiede una clausola esplicita di protezione legale. Il considerando 76 descrive la CVD come un processo di segnalazione strutturato e cita i programmi bug-bounty come incentivo alle segnalazioni; non codifica la protezione legale né la riduzione del rischio per i ricercatori. La norma deriva dalla prassi del settore, non dal regolamento: ISO/IEC 29147, le linee guida ENISA sulla CVD e le raccomandazioni dei CSIRT nazionali convergono su una clausola scritta di protezione per la ricerca in buona fede entro l'ambito pubblicato. Una politica che si riserva il diritto di intraprendere azioni legali contro la ricerca nell'ambito fa crollare il canale e, in pratica, fallisce sulla metà "applicare" dell'Allegato I Parte II punto 5. (Considerando 76; ISO/IEC 29147; linee guida ENISA sulla CVD.)