Chi scopre una vulnerabilità nel vostro prodotto ha bisogno di un modo chiaro e raggiungibile da esseri umani per segnalarla, e il vostro team ha bisogno di una politica scritta su come quella segnalazione viene confermata, triagiata, corretta e divulgata. Ai sensi del Cyber Resilience Act UE (Regolamento (UE) 2024/2847), questo significa mettere in atto e applicare una politica di divulgazione coordinata delle vulnerabilità (CVD), oltre a pubblicare un punto di contatto unico per le segnalazioni di vulnerabilità. Non esiste alcuna esenzione per le PMI. Questa pagina illustra cosa deve contenere la politica, come pubblicare il canale di contatto e come la CVD si interseca con la segnalazione delle vulnerabilità e con il più ampio framework di gestione delle vulnerabilità.
Sintesi
- La politica CVD è obbligatoria. Scritta, pubblicata, applicata, senza soglie dimensionali. Dettagli in Cosa richiede effettivamente il CRA più sotto.
- È richiesto un punto di contatto unico. Gli utilizzatori devono poter raggiungere una persona; il canale non può essere limitato a strumenti automatizzati.
security.txt(RFC 9116) è la convenzione de facto per pubblicare il contatto, ma il CRA non impone un formato specifico.- La CVD non coincide con la segnalazione a ENISA. La CVD disciplina il vostro rapporto con il segnalatore; il contatore regolatorio verso ENISA e il CSIRT coordinatore scorre in parallelo. Si veda Coordinamento con ENISA più sotto.
- La divulgazione pubblica delle vulnerabilità corrette è obbligatoria, con una stretta deroga nei casi in cui il rischio di sicurezza della pubblicazione superi il beneficio fino a quando gli utilizzatori abbiano avuto la possibilità di applicare la patch.
- I dettagli sulle sanzioni stanno nella guida enforcement. Vedi sanzioni e applicazione per la scala delle sanzioni e i poteri di mercato.
I quattro pilastri di una postura CVD conforme al CRA: politica, contatto, pubblicazione e rinvio all'enforcement.
Cosa richiede effettivamente il CRA per la CVD
Il requisito CVD è breve: i fabbricanti devono "mettere in atto 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:
| Requisito | Cosa significa nella pratica | Errore comune |
|---|---|---|
| Mettere in attoPolitica documentata | Esiste una politica scritta e accessibile. Indica ai segnalatori cosa rientra nell'ambito, come segnalare, quale risposta aspettarsi e quando avviene la divulgazione. | Un'abitudine interna non documentata di smistare le email su security@ non basta. |
| ApplicareProcesso operativo | La politica è operativa, non soltanto pubblicata. Le scadenze di riscontro, gli impegni di triage e le condizioni di divulgazione scritte nel documento vengono rispettati nella pratica. | Una politica che promette un riscontro entro 72 ore ma impiega abitualmente tre settimane non è applicata. |
| Facilitare la segnalazioneCanale accessibile | La politica rende semplice per i segnalatori esterni condividere informazioni sulle vulnerabilità: un indirizzo di contatto, un processo pubblicato e un canale raggiungibile da esseri umani, non chiuso dietro un login o un chatbot. | Un portale solo con login, un intake solo automatizzato o un percorso di contatto nascosto non servono la finalità dell'obbligo. |
| Non penalizzare i segnalatoriNorma di ricerca in buona fede | Non è una clausola letterale del CRA. Il CRA inquadra la CVD come segnalazione strutturata e nota che i programmi di bug bounty possono incentivare le segnalazioni. ISO/IEC 29147 e le linee guida ENISA trattano il safe harbour per la ricerca in buona fede come una caratteristica normale di una politica CVD. | Riservarsi azioni legali contro la ricerca in buona fede nell'ambito previsto fa crollare il canale di segnalazione anche se esiste un indirizzo di contatto. |
Per il framework più ampio (gli otto obblighi numerati di cui la CVD è uno), si veda la gestione delle vulnerabilità.
Il punto di contatto unico
La politica CVD funziona solo se i segnalatori riescono a trovare un contatto reale e una via umana verso il fabbricante. L'obbligo del punto di contatto unico del CRA si traduce in tre requisiti concreti:
- Facilmente identificabile. Il contatto deve essere visibile nelle informazioni sul prodotto, nelle istruzioni per l'utilizzatore che accompagnano il prodotto e sul sito web pubblico. Un contatto raggiungibile solo leggendo l'informativa sulla privacy non supera questo test.
- Canali multipli. "Scegliere i mezzi di comunicazione preferiti" 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. "Senza limitarli agli 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 CRA non richiede di separare il supporto al consumatore dall'intake delle vulnerabilità, ma la maggior parte dei fabbricanti gestisce una casella dedicata alla sicurezza instradata al team di sicurezza del prodotto, per mantenere la CVD distinta dal supporto generale.
Pubblicare la politica CVD: security.txt e oltre
Il CRA non nomina security.txt, RFC 9116 o alcun formato specifico di pubblicazione. Richiede un canale di contatto "facilmente identificabile" e una politica CVD "messa in atto 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 per 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 ripiego, ma il percorso well-known è preferito.
Oltre security.txt. Lo standard "facilmente identificabile" implica che il contatto debba comparire anche nella pagina di supporto o di contatto del prodotto, nelle istruzioni per l'utilizzatore che accompagnano il prodotto, 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 la segnalazione" e quello di "non limitarli agli strumenti automatizzati" solo se aperti ai segnalatori esterni con risposta umana. Un bounty privato a invito non soddisfa di per sé il requisito del contatto pubblico e deve coesistere con un canale pubblico.
Ricevere e triagiare le segnalazioni di vulnerabilità
Una politica CVD si applica attraverso un flusso documentato di intake e triage. I meccanismi descritti di seguito non sono prescritti dal CRA, ma rappresentano l'aspetto di 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), assegnare 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, il gate dell'escalation regolatoria) 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 contro 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 azione legale contro ricerca nell'ambito, il che fa collassare il canale. |
| Chiudere il cerchio | Ogni segnalazione riceve una risposta finale: corretta (con advisory e CVE), duplicata, non si correggerà (con motivazione) o fuori ambito. | Confermare una volta e poi sparire: la ragione più comune per cui le politiche CVD appaiono non applicate dall'esterno. |
Coordinamento con ENISA e i ricercatori esterni
L'intake CVD e la segnalazione a ENISA sono obblighi distinti con destinatari diversi. La politica CVD disciplina il vostro rapporto con il segnalatore. La notifica regolatoria disciplina il vostro dovere verso ENISA e il CSIRT coordinatore. I due processi scorrono in parallelo e si attivano in modo diverso.
Quando una segnalazione CVD diventa un trigger regolatorio. I fabbricanti devono notificare "qualsiasi vulnerabilità attivamente sfruttata" tramite la SRP con una cadenza di 24 ore, 72 ore e 14 giorni. Il trigger è "attivamente sfruttata", non "segnalata". Un intake CVD con un proof-of-concept funzionante non è di per sé un trigger regolatorio; lo diventa quando esistono evidenze affidabili che un attore malevolo abbia sfruttato la vulnerabilità in un sistema senza autorizzazione.
Gli incidenti gravi seguono una cadenza diversa: 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 comprimere in un unico schema "24h/72h/14g". Si veda segnalazione delle vulnerabilità.
ENISA e i CSIRT designati come coordinatori. La trasmissione avviene tramite la SRP usando il terminale elettronico del CSIRT designato come coordinatore nello Stato membro dello stabilimento principale del fabbricante. I fabbricanti possono ricevere segnalazioni direttamente, oppure indirettamente tramite un CSIRT designato come coordinatore ai sensi della direttiva NIS2. Per i meccanismi di onboarding alla SRP si veda l'onboarding ENISA SRP.
Coordinamento con il ricercatore. Quando un ricercatore propone un embargo mentre voi pubblicate un fix, documentate la finestra concordata e rispettatela. Quando il ricercatore rifiuta o pubblica prima del previsto, la vostra politica CVD deve indicare come rispondete, tipicamente accelerando l'advisory e la patch.
Tempistiche di divulgazione pubblica
La divulgazione pubblica di una vulnerabilità corretta non è facoltativa ai sensi del CRA. Una volta reso disponibile un aggiornamento di sicurezza, i fabbricanti devono condividere e divulgare pubblicamente una descrizione della vulnerabilità, informazioni che consentano agli utilizzatori di identificare il prodotto interessato, l'impatto, la gravità e indicazioni chiare per rimediare. Un ritardo è ammesso "in casi debitamente giustificati" qualora i rischi di sicurezza della pubblicazione superino i benefici, ma soltanto "fino a quando gli utilizzatori non abbiano avuto la possibilità di applicare la pertinente patch".
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, perché il rapporto finale regolatorio è dovuto entro 14 giorni dalla disponibilità di una misura correttiva.
Formato della divulgazione pubblica. Un advisory allineato al CRA dovrebbe contenere, come minimo, un ID CVE, una descrizione chiara, il prodotto e il range di versioni interessati, la gravità (punteggio base CVSS), l'impatto, il rimedio e il credito quando 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" è ristretto. Consente di trattenere i dettagli pubblici fino a quando gli utilizzatori 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 il dovere di divulgazione pubblica indipendentemente dall'intento.
Errori comuni
| Errore | Perché non supera il test del CRA |
|---|---|
| Minacce legali contro ricercatori in buona fede | Viola il dovere di "applicare una politica di divulgazione coordinata delle vulnerabilità" e scoraggia il canale di intake richiesto dallo stesso dovere. |
| Nessun canale di contatto pubblico, solo login a un portale interno | Non supera il dovere di punto di contatto unico "facilmente identificabile" né il dovere di "fornire un indirizzo di contatto". |
Autorisponditore security-noreply@ senza triage umano |
Il punto di contatto unico vieta di limitare la comunicazione a strumenti automatizzati. |
| Confermare la ricezione e non rispondere più | La politica è "messa in atto" ma non "applicata"; sono richieste entrambe. |
| Chiudere le segnalazioni come "non si correggerà" senza motivazione | Indistinguibile dall'ignorare la segnalazione dall'esterno; i ricercatori reagiscono pubblicando. |
| Raggruppare le correzioni di sicurezza in release di funzionalità che gli utilizzatori rinviano | Gli aggiornamenti di sicurezza devono essere separabili dagli aggiornamenti funzionali "ove tecnicamente fattibile". |
| Correggere silenziosamente senza advisory | Viola il dovere di divulgazione pubblica. |
| Trattare l'intake CVD come la trasmissione a ENISA | Destinatari diversi, obblighi diversi. La CVD non esonera dalla segnalazione regolatoria, e la segnalazione regolatoria non esonera dalla CVD. |
Domande frequenti
I piccoli fabbricanti devono avere una politica CVD ai sensi del CRA?
Sì. Il dovere 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 una stretta riduzione delle sanzioni sulle scadenze dell'allerta precoce a 24 ore, ma la riduzione tocca solo [quelle sanzioni](/cra-compliance/penalties-and-enforcement), non l'obbligo sostanziale, e non si estende alle medie imprese. Un fornitore di firmware di due persone ha bisogno di una politica CVD pubblicata, di un canale di contatto e di un processo di triage allo stesso modo di un grande fornitore.
Il `security.txt` è obbligatorio ai sensi del CRA?
No. Il CRA non nomina security.txt né RFC 9116. Impone un punto di contatto unico "facilmente identificabile" e un indirizzo di contatto per la segnalazione delle vulnerabilità. security.txt è la convenzione de facto usata per soddisfare quei doveri 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 per l'utilizzatore che accompagnano il prodotto è altrettanto conforme. Il requisito cogente è un canale pubblicato, funzionante e raggiungibile da esseri umani; il formato è una scelta.
L'intake CVD può essere lo stesso canale della trasmissione a ENISA?
No. Si tratta di destinatari diversi e obblighi diversi. L'intake CVD è il canale attraverso cui i ricercatori esterni e gli utilizzatori segnalano le vulnerabilità al fabbricante. La trasmissione a ENISA è la notifica regolatoria del fabbricante a ENISA e al CSIRT coordinatore, effettuata tramite la Piattaforma Unica di Segnalazione. Un ricercatore non trasmette alla SRP; lo fa il fabbricante. Confondere i due porta a non confermare al ricercatore (violazione CVD) o a non notificare ENISA quando lo sfruttamento è confermato (esposizione sanzionatoria seria).
Cosa succede quando un ricercatore esterno segnala una vulnerabilità attivamente sfruttata?
Partono due contatori in parallelo. Il processo CVD disciplina il rapporto con il ricercatore: confermare la ricezione, triagiare, concordare un embargo, pubblicare un fix, pubblicare un advisory, accreditare il segnalatore. Il processo regolatorio disciplina il rapporto con ENISA e il CSIRT coordinatore: un'allerta precoce di 24 ore, una notifica di 72 ore e un rapporto finale entro 14 giorni dalla disponibilità di una misura correttiva. Il contatore delle 24 ore parte quando il fabbricante viene a conoscenza che lo sfruttamento è attivo, il che può coincidere con il momento in cui le prove del ricercatore rendono credibile tale conclusione. Aspettare la certezza forense farà mancare la scadenza. I due processi scorrono in parallelo e si concludono su superfici diverse.
La politica CVD deve offrire un safe harbour legale ai ricercatori?
No, il CRA non richiede una clausola esplicita di safe harbour. Il CRA inquadra la CVD come processo di segnalazione strutturato e cita i programmi di bug bounty come modo per incentivare le segnalazioni; non codifica la protezione legale né la riduzione del rischio per i ricercatori. La norma viene dalla prassi del settore più che dal regolamento: ISO/IEC 29147, le linee guida ENISA e la maggior parte delle raccomandazioni dei CSIRT nazionali convergono su una clausola scritta di safe harbour che copre la ricerca in buona fede nell'ambito pubblicato. Una politica che si riserva il diritto di azione legale contro la ricerca nell'ambito fa crollare il canale e, nella pratica, fallisce sulla metà "applicare" del dovere di politica CVD.