Divulgazione coordinata delle vulnerabilità: come gestire un programma

Che cos'è la divulgazione coordinata delle vulnerabilità?

La divulgazione coordinata delle vulnerabilità (CVD, coordinated vulnerability disclosure) è la pratica di gestire in privato una vulnerabilità appena scoperta tra chi l'ha trovata e il vendor finché non è disponibile una correzione o una mitigazione, per poi pubblicarla. La CERT Guide to Coordinated Vulnerability Disclosure la descrive come la raccolta di informazioni da chi trova le vulnerabilità, il coordinamento della condivisione di tali informazioni tra gli stakeholder interessati e la divulgazione della vulnerabilità e delle sue mitigazioni, anche al pubblico.

Per un vendor di prodotti, la CVD ha due metà. La metà rivolta all'esterno, ricevere segnalazioni e pubblicare advisory, è l'oggetto di questa pagina. La metà interna, verificare, correggere e rilasciare, è il ciclo di vita della gestione delle vulnerabilità. Entrambe sono gestite di solito da un PSIRT.

CVD, full disclosure e bug bounty a confronto

	Divulgazione coordinata	Full disclosure	Bug bounty
Che cos'è	Segnalazione privata, correzione, poi pubblicazione in un momento concordato	Chi trova la vulnerabilità pubblica subito i dettagli, informando o meno il vendor	Un programma che paga per i risultati validi
Chi controlla i tempi	Vendor e scopritore insieme, a volte con un coordinatore	Chi trova la vulnerabilità	I termini del programma, di solito sul modello della CVD
Rischio per gli utenti	Il più basso: i dettagli diventano pubblici quando esiste una correzione o scade un termine	Il più alto: gli attaccanti lo scoprono insieme ai difensori	Come per la CVD
Costo	Tempo del personale per triage e risposta	Lavoro di emergenza non pianificato	Tempo del personale più ricompense e spesso costi di piattaforma

Un bug bounty non è un'alternativa a un programma di divulgazione delle vulnerabilità (VDP). È un incentivo che vi si aggiunge. Ogni vendor ha bisogno di un modo con cui chiunque possa segnalare una vulnerabilità; un bounty decide solo se alcune segnalazioni vengono pagate.

Che cosa contiene una policy di divulgazione delle vulnerabilità

Una policy di divulgazione delle vulnerabilità è il documento pubblico che stabilisce i termini del Suo programma. ISO/IEC 29147, lo standard internazionale per la divulgazione delle vulnerabilità, rende obbligatorio un elemento, un canale di contatto preferito, e ne raccomanda diversi altri. Una policy completa comprende:

• Come segnalare. Un indirizzo dedicato o un modulo web, e un modo per inviare in sicurezza i dettagli sensibili, come una chiave di cifratura pubblicata.
• Che cosa includere. Prodotto e versione interessati, passaggi per riprodurre il problema, impatto e come contattare il segnalatore.
• Ambito. Quali prodotti, versioni e servizi sono coperti e quali metodi di test sono vietati, come il denial of service o l'accesso ai dati di altri utenti.
• Safe harbor. L'impegno a non intraprendere azioni legali contro la ricerca in buona fede che rispetta la policy.
• Che cosa possono aspettarsi i segnalatori. Quando darà riscontro alla segnalazione, come li terrà aggiornati e il Suo tempo obiettivo per una correzione.
• Tempistica di divulgazione. Quando i dettagli diventano pubblici e che cosa succede se una correzione richiede più tempo.
• Pubblicazione. Dove compaiono gli advisory e se assegna ID CVE.
• Riconoscimenti. Se e come riconosce il merito ai segnalatori, e se paga dei bounty.

Mantenga la policy breve e specifica. I segnalatori la leggono per decidere se segnalare a Lei è sicuro e vale lo sforzo.

security.txt: renda il Suo contatto facile da trovare

Una policy funziona solo se i ricercatori riescono a trovarla. RFC 9116, pubblicato nell'aprile 2022, definisce security.txt, un piccolo file di testo servito su /.well-known/security.txt tramite HTTPS.

Contact: mailto:[email protected]
Expires: 2027-09-30T23:00:00.000Z
Encryption: https://example.com/pgp-key.txt
Policy: https://example.com/security/disclosure-policy
Acknowledgments: https://example.com/security/thanks
Preferred-Languages: en
Canonical: https://example.com/.well-known/security.txt

• Obbligatori: Contact ed Expires. RFC 9116 raccomanda una scadenza a meno di un anno di distanza, così il file non diventa obsoleto.
• Facoltativi: Policy, Encryption, Acknowledgments, Preferred-Languages, Canonical e Hiring.
• Firma: l'RFC raccomanda una firma OpenPGP cleartext, con Canonical impostato.

Metta un promemoria in calendario prima della data di Expires. Un file scaduto dice ai ricercatori che nessuno sta leggendo.

Embargo e tempistiche di divulgazione

L'embargo è il periodo tra la segnalazione e la pubblicazione. La norma più citata è la policy di Google Project Zero: i vendor hanno 90 giorni per rendere disponibile una patch, e i dettagli vengono pubblicati 30 giorni dopo il rilascio della patch. Un vendor che ha bisogno di un po' più di tempo può chiedere un periodo di grazia, fino a un massimo di 104 giorni in totale. Quando una vulnerabilità è già sfruttata in the wild, la scadenza scende a 7 giorni.

La Sua policy può stabilire termini diversi, e molti segnalatori li accettano. Ciò che conta è che la tempistica sia scritta, che Lei tenga informati i segnalatori e che chieda una proroga prima della scadenza e non dopo. Un advisory pubblicato nei tempi previsti con una mitigazione è meglio del silenzio.

ID CVE e CNA

La maggior parte degli advisory riporta un ID CVE, così clienti e strumenti possono abbinarli. Gli ID vengono assegnati dalle CVE Numbering Authorities (CNA), organizzazioni autorizzate ad assegnare ID entro un ambito concordato. Molti vendor di software sono CNA per i propri prodotti, e questo consente loro di assegnare l'ID e pubblicare il record con i propri tempi. Se Lei non lo è, l'ID viene assegnato da una CNA il cui ambito copre il Suo prodotto, o da una CNA of Last Resort.

Coordinamento tra più parti

Alcune vulnerabilità riguardano molti vendor contemporaneamente: un difetto in una libreria ampiamente usata, in un protocollo o in un chip. In questi casi un coordinatore aiuta a raggiungere tutti i vendor interessati e a concordare un'unica data di pubblicazione.

• CERT/CC, presso il Software Engineering Institute della Carnegie Mellon University, coordina i casi multi-vendor e pubblica la guida CERT alla CVD.
• CSIRT nazionali nell'UE. Ai sensi della NIS2, ogni Stato membro designa un CSIRT come proprio coordinatore CVD. Agisce come intermediario di fiducia tra segnalatori e vendor, negozia le tempistiche di divulgazione, gestisce le vulnerabilità che riguardano più soggetti e accetta segnalazioni anonime.
• La European Vulnerability Database (EUVD) di ENISA, istituita ai sensi della NIS2, è operativa dal maggio 2025 e pubblica informazioni sulle vulnerabilità pubblicamente note, comprese quelle coordinate a livello UE.

ISO/IEC 29147 copre anche il caso in cui Lei ricopra entrambi i ruoli: un vendor il cui prodotto contiene il componente vulnerabile di un altro vendor, che deve segnalare upstream e informare i propri clienti.

Dopo l'arrivo di una segnalazione

1. Dia riscontro entro il tempo promesso dalla Sua policy e fornisca al segnalatore un ID di tracciamento.
2. Verifichi la segnalazione e ne valuti la gravità.
3. Individui ciò che è interessato: ogni prodotto, release e branch supportato che contiene il codice o il componente vulnerabile.
4. Corregga e rilasci per ogni branch interessato, tenendo aggiornato il segnalatore.
5. Pubblichi l'advisory, con ID CVE, versioni interessate, correzione e riconoscimenti. Gli advisory leggibili da una macchina usano CSAF, e VEX indica ai clienti quali prodotti non sono interessati.

Il processo completo, con ruoli, tempistiche e metriche, è descritto nel ciclo di vita della gestione delle vulnerabilità.

La normativa sta rendendo obbligatorie le policy CVD

Il Cyber Resilience Act dell'UE impone ai fabbricanti di adottare e applicare una politica di divulgazione coordinata delle vulnerabilità e di fornire un indirizzo di contatto per segnalare le vulnerabilità, comprese quelle nei componenti di terze parti (allegato I, parte II). Questi obblighi si applicano dall'11 dicembre 2027; veda che cosa richiede il CRA. L'articolo 21, paragrafo 2, lettera e), della NIS2 elenca la gestione e la divulgazione delle vulnerabilità tra le misure di sicurezza che i soggetti essenziali e importanti devono adottare. Negli Stati Uniti, l'Executive Order 14028 ha disposto indicazioni sulla software supply chain che includono la partecipazione a un programma di divulgazione delle vulnerabilità.

Una segnalazione è utile solo quanto il Suo registro di ciò che ha distribuito

Ogni segnalazione solleva la stessa prima domanda: quali delle nostre release la contengono? CRACI esegue le Sue build GitHub Actions sui propri runner e registra i pacchetti effettivamente scaricati da ciascun job, comprese le dipendenze transitive, i pacchetti ripristinati dalle cache CI e le dipendenze che nessun lockfile elenca. La cronologia delle build mostra quali build passate contenevano una dipendenza vulnerabile, così Lei conosce il periodo di esposizione, e la vista dell'inventario mostra quali versioni del software sono distribuite su quali prodotti.

CRACI aggrega le SBOM tra build e repository e rivaluta di continuo le SBOM monitorate, così una volta pubblicata una vulnerabilità in un componente open source, Lei vede ovunque compaia. I team di sicurezza eseguono il triage dei risultati e li inviano ai team responsabili della correzione, CRACI supporta VEX e i policy gate possono bloccare le build che contengono una specifica CVE una volta corretta. Veda il tracciamento delle vulnerabilità.

Divulgazione coordinata delle vulnerabilità: domande frequenti

Che cos'è la divulgazione coordinata delle vulnerabilità?

La divulgazione coordinata delle vulnerabilità (CVD) è il processo in cui chi trova una vulnerabilità la segnala in privato al vendor, il vendor la corregge e i dettagli vengono pubblicati quando gli utenti possono proteggersi, di solito a una data concordata tra le parti. Coordinatori come CERT/CC o un CSIRT nazionale intervengono quando un vendor non è raggiungibile o quando sono interessati più vendor.

Qual è la differenza tra un VDP e un bug bounty?

Un programma di divulgazione delle vulnerabilità (VDP) spiega a chiunque come segnalare una vulnerabilità e che cosa aspettarsi, senza pagare per i risultati. Un bug bounty paga i ricercatori per i risultati validi, di solito entro un ambito definito e spesso tramite una piattaforma di bounty. La maggior parte delle organizzazioni inizia con un VDP; un bounty è un'aggiunta facoltativa, non un sostituto.

Che cosa dovrebbe includere una policy di divulgazione delle vulnerabilità?

Come minimo, come segnalare: un indirizzo di contatto o un modulo. ISO/IEC 29147 raccomanda inoltre di indicare che cosa deve contenere una segnalazione, come comunicare in sicurezza, che cosa possono aspettarsi i segnalatori e quando, che cosa rientra nell'ambito, come vengono pubblicati gli advisory e come viene riconosciuto il merito ai segnalatori. La maggior parte delle policy aggiunge una dichiarazione di safe harbor e una tempistica di divulgazione.

Che cos'è security.txt?

security.txt è un file di testo semplice definito in RFC 9116 e servito su /.well-known/security.txt. Indica ai ricercatori dove segnalare le vulnerabilità. Deve contenere i campi Contact ed Expires e può rimandare alla Sua policy, alla chiave di cifratura e alla pagina dei riconoscimenti.

Qual è il termine tipico per la divulgazione?

90 giorni è la norma più citata. Google Project Zero concede ai vendor 90 giorni per rendere disponibile una patch e pubblica i dettagli 30 giorni dopo la patch, con una scadenza di 7 giorni quando una vulnerabilità è già sfruttata in the wild. La Sua policy può stabilire termini diversi, e i coordinatori negoziano caso per caso.

Una policy di divulgazione coordinata delle vulnerabilità è obbligatoria?

Sempre di più, sì. Il Cyber Resilience Act dell'UE impone ai fabbricanti di prodotti con elementi digitali di adottare e applicare una policy CVD e di fornire un indirizzo di contatto per le segnalazioni, e la NIS2 elenca la gestione e la divulgazione delle vulnerabilità tra le misure di sicurezza richieste. Altrove, spesso la richiedono i clienti e le regole sugli acquisti.

Devo essere una CNA per ottenere un ID CVE?

No. Una CVE Numbering Authority (CNA) assegna gli ID CVE entro il proprio ambito, e molti vendor diventano CNA per i propri prodotti. Se Lei non lo è, l'ID può essere assegnato da una CNA il cui ambito copre il Suo prodotto, o da una CNA of Last Resort.