Politica di divulgazione coordinata delle vulnerabilità e security.txt: modello pronto per fabbricanti
Il Cyber Resilience Act chiede a ogni fabbricante due cose semplici e poco costose: una politica che dica come ricevere le segnalazioni di vulnerabilità sui propri prodotti, e un contatto pubblico a cui inviarle. Questa guida spiega perché, propone un testo modello in italiano da adattare, mostra come pubblicare il file security.txt e che cosa fare quando arriva la prima segnalazione.
Perché il regolamento la chiede
Tra i requisiti di gestione delle vulnerabilità (Allegato I, Parte II) ce ne sono due che riguardano il rapporto con l'esterno: il fabbricante «mette in atto e applica una politica in materia di divulgazione coordinata delle vulnerabilità» (punto 5) e «adotta misure per agevolare la condivisione di informazioni sulle potenziali vulnerabilità», fornendo «un indirizzo di contatto per la segnalazione» (punto 6). Sono obblighi pieni dall'11 dicembre 2027, ma hanno un valore immediato: le segnalazioni esterne (da ricercatori, clienti, altri fabbricanti) sono una delle fonti principali per sapere che una vulnerabilità esiste, e nei casi peggiori che è sfruttata. Chi non ha un canale, lo scopre dai giornali.
«Divulgazione coordinata» significa che chi trova una falla e chi deve correggerla si accordano su tempi e modi: il ricercatore non la rende pubblica subito, il fabbricante la corregge in un tempo ragionevole e riconosce il contributo. È una prassi consolidata; il regolamento la trasforma in un requisito.
Che cosa deve contenere la politica
Una buona politica sta in una pagina. Otto elementi:
- Ambito: quali prodotti e servizi sono coperti (tutti i prodotti del catalogo, le app, il sito).
- Come segnalare: l'indirizzo e-mail dedicato, eventualmente un modulo; una chiave per cifrare le comunicazioni, se la offrite.
- Che cosa includere: prodotto e versione, descrizione, passi per riprodurre, impatto stimato.
- Che cosa vi impegnate a fare: confermare la ricezione entro un certo numero di giorni lavorativi, tenere informato chi ha segnalato, correggere in tempi ragionevoli.
- Che cosa chiedete: non rendere pubblica la vulnerabilità prima della correzione o di un termine concordato; non accedere a dati di terzi; non fare prove distruttive.
- Riconoscimento: se e come citate chi ha segnalato (una pagina dei ringraziamenti è prassi; non è obbligatorio un compenso).
- Tutela: l'impegno a non intraprendere azioni legali contro chi segnala in buona fede nel rispetto della politica.
- Lingue e aggiornamento: in quali lingue accettate le segnalazioni; la data dell'ultima revisione.
Testo modello, in italiano
Politica di divulgazione coordinata delle vulnerabilità di [Nome azienda]
[Nome azienda] prende sul serio la sicurezza dei propri prodotti. Se ritieni di aver individuato una vulnerabilità in uno dei nostri prodotti, nelle app che li accompagnano o nei nostri servizi, ti chiediamo di segnalarcela secondo questa politica.
Come segnalare. Scrivi a security@[dominio]. Indica il prodotto e la versione, una descrizione della vulnerabilità, i passi per riprodurla e l'impatto che ritieni possa avere. Se vuoi cifrare il messaggio, la nostra chiave pubblica è disponibile all'indirizzo [indirizzo]. Accettiamo segnalazioni in italiano e in inglese.
I nostri impegni. Confermiamo la ricezione entro [3] giorni lavorativi. Valutiamo la segnalazione e ti comunichiamo l'esito della prima analisi entro [10] giorni lavorativi. Ti teniamo informato sull'avanzamento della correzione. Pubblichiamo le informazioni sulla vulnerabilità corretta quando l'aggiornamento è disponibile e, se lo desideri, citiamo il tuo contributo.
Che cosa ti chiediamo. Di non rendere pubblica la vulnerabilità prima che la correzione sia disponibile, o prima di [90] giorni dalla segnalazione, salvo diverso accordo; di non accedere, modificare o cancellare dati che non ti appartengono; di non eseguire prove che possano degradare il funzionamento dei prodotti o dei servizi; di non chiedere un compenso come condizione della segnalazione.
Tutela. Non intraprenderemo azioni legali nei confronti di chi segnala in buona fede e nel rispetto di questa politica.
Ambito. Questa politica si applica a [elenco dei prodotti o «tutti i prodotti e i servizi di [Nome azienda]»]. Per le vulnerabilità di componenti di terzi integrati nei nostri prodotti, le inoltriamo al rispettivo fornitore e coordiniamo la risposta.
Ultimo aggiornamento: [data]. Versione [1.0].
I numeri tra parentesi quadre sono valori di partenza ragionevoli: adattali alla tua capacità reale di risposta. Meglio promettere dieci giorni e rispettarli che tre e mancarli.
Il file security.txt: il contatto che le macchine trovano
Il modo standard per rendere raggiungibile il contatto è un piccolo file di testo pubblicato sul sito all'indirizzo https://www.[dominio]/.well-known/security.txt, secondo lo standard RFC 9116. Ricercatori e strumenti automatici lo cercano lì. Contiene poche righe:
Contact: mailto:security@[dominio] Expires: 2027-10-07T00:00:00.000Z Preferred-Languages: it, en Policy: https://www.[dominio]/sicurezza/divulgazione-vulnerabilita Encryption: https://www.[dominio]/sicurezza/chiave-pubblica.txt Canonical: https://www.[dominio]/.well-known/security.txt
- Contact e Expires sono obbligatori. La data di scadenza va rinnovata (un anno è la prassi): un file scaduto dice «qui nessuno guarda».
- Policy rimanda alla pagina della politica; Encryption alla chiave pubblica, se la offrite; Canonical indica l'indirizzo ufficiale del file.
- Il file può essere firmato digitalmente; non è necessario per cominciare.
Due accortezze: l'indirizzo security@ deve arrivare a persone che lo leggono ogni giorno, e il contatto va riportato anche nelle istruzioni del prodotto, dove il regolamento chiede le informazioni per l'utilizzatore (Allegato II).
Quando arriva la prima segnalazione
- Rispondi subito, anche solo per confermare la ricezione, con un numero di riferimento. Chi segnala giudica l'azienda dalla prima risposta.
- Annota data e ora nel registro delle vulnerabilità: è la stessa traccia che serve per l'obbligo di segnalazione dell'articolo 14.
- Valuta: la vulnerabilità esiste? In quali prodotti e versioni? È sfruttabile? Ci sono prove che sia già sfruttata? In quest'ultimo caso parte il conto delle 24 ore per la notifica a ENISA.
- Concorda i tempi con chi ha segnalato e tieni fede alla politica.
- Correggi e comunica: aggiornamento di sicurezza gratuito, informazioni pubblicate sulla vulnerabilità corretta (Allegato I, Parte II, punto 4), ringraziamento.
- Se il componente è di un fornitore, inoltra la segnalazione e coordina: la responsabilità verso i tuoi clienti resta tua.
Domande frequenti
Devo pagare chi segnala?
No. Un programma di ricompense («bug bounty») è una scelta, non un obbligo. Il regolamento chiede un canale e una politica, non un compenso.
Siamo una piccola azienda senza un reparto sicurezza: a chi arriva security@?
Al responsabile tecnico, con un sostituto, e a chi segue la conformità. L'importante è che qualcuno legga ogni giorno e che esista una procedura, anche breve.
La politica va tradotta in inglese?
Conviene: molti ricercatori scrivono in inglese. Il file security.txt può indicare le lingue accettate.
Ricevo una segnalazione su un prodotto fuori assistenza.
Va comunque valutata: se la vulnerabilità risulta attivamente sfruttata, l'obbligo di segnalazione secondo gli orientamenti della Commissione continua anche dopo la fine del periodo di assistenza.
Da dove cominciare
La politica e il security.txt si fanno in un pomeriggio. Il lavoro vero è ciò che succede dopo ogni segnalazione: valutare, decidere, correggere, documentare. Assiduo lo rende un processo di ogni giorno. Il configuratore ti dice da dove partire.
Fonti: regolamento (UE) 2024/2847, Allegato I Parte II punti 4, 5 e 6, Allegato II, articolo 14; RFC 9116 («A File Format to Aid in Security Vulnerability Disclosure»); orientamenti della Commissione europea del 27 luglio 2026. Leggi anche: vulnerabilità di prodotto · la procedura di segnalazione.