Qualcuno ti scrive che ha trovato una falla nel tuo software. E adesso?

Il messaggio che nessuno sa dove far arrivare

Immaginate la scena. Una persona che non lavora per voi, non vi conosce e non vi ha chiesto nulla trova un difetto nel vostro prodotto. Vuole dirvelo. Apre il vostro sito e cerca un indirizzo.

Cosa trova? Nella maggior parte dei casi: un modulo di contatto commerciale, un indirizzo di assistenza clienti, forse un centralino. Il messaggio finisce in un ticket, dove qualcuno che si occupa di rimborsi lo classificherà come lamentela, oppure in una casella che nessuno legge. Passano settimane. La persona che ha trovato il problema, a quel punto, ha davanti tre strade: insistere, lasciar perdere, o pubblicarlo.

La guida congiunta pubblicata il 15 luglio 2026 da CISA, NSA, JPCERT/CC, NCSC-NL e NCSC-UK riguarda esattamente il modo di non arrivare a quel bivio. Il titolo è Establishing a Coordinated Vulnerability Disclosure Program to Work With Security Researchers, ed è rivolto ai produttori di software e ai fornitori di servizi online.

I quattro pezzi

Il documento articola un programma di divulgazione coordinata delle vulnerabilità (CVD) intorno a quattro elementi, ed è un elenco corto abbastanza da poter essere preso sul serio anche da un'azienda piccola.

1. 01
   Politica pubblica (VDP)

   dove si scrive, cosa è in perimetro, cosa aspettarsi e in quanto tempo
2. 02
   Triage

   chi riceve, chi valuta, come si stabilisce se è reale e quanto è grave
3. 03
   Rimedio

   come si corregge e come si comunica la correzione a chi la deve applicare
4. 04
   CVE

   assegnazione di un identificativo pubblico, quando ne ricorrono i presupposti

La politica di divulgazione (VDP) è la parte che manca più spesso ed è la più economica da costruire. È un documento pubblico che dice: ecco dove scrivere, ecco cosa consideriamo in perimetro, ecco cosa faremo e in quanto tempo. Non richiede un team dedicato. Richiede una decisione.

Il triage è dove i programmi mal costruiti si rompono. Una segnalazione che resta senza risposta per un mese produce un ricercatore che smette di collaborare, e la prossima volta non scriverà. La guida insiste sui tempi di riscontro perché il rapporto con chi segnala è, prima che tecnico, di reciprocità.

L'assegnazione del CVE è il passaggio che trasforma una correzione privata in un fatto pubblico verificabile. Senza identificativo, la patch esiste ma i vostri clienti non sanno di doverla applicare, e nessuno può misurare l'esposizione del proprio parco software.

La clausola che cambia il rapporto

Il punto su cui la guida è più netta riguarda la tutela legale per chi segnala: viene raccomandata l'adozione di un linguaggio chiaro di safe harbor, che protegga i ricercatori che agiscono in buona fede entro i limiti dichiarati dalla politica.

Serve capire perché è centrale e non un dettaglio da avvocati. Chi trova una vulnerabilità in un servizio online l'ha trovata facendo qualcosa che, letto con occhio ostile, può somigliare a un accesso non autorizzato. In assenza di una dichiarazione esplicita, la persona che vuole aiutarvi sta correndo un rischio personale per farlo — e le persone ragionevoli, davanti a un rischio personale senza contropartita, tendono a scegliere il silenzio.

Il safe harbor non è generosità: è la rimozione di un deterrente che agisce solo sui segnalatori onesti. Chi ha intenzioni ostili non legge la vostra politica di divulgazione.

Se siete troppo piccoli, la guida lo prevede

L'obiezione naturale di un'azienda di venti persone che vende un gestionale verticale è che tutto questo è sproporzionato. La guida la anticipa, e indica una via: appoggiarsi a intermediari terzi — la stessa CISA o altri CSIRT nazionali — per sostituire o integrare il programma.

Per il contesto italiano questo si traduce in un riferimento concreto: il CSIRT Italia dell'ACN è il punto di contatto nazionale per la gestione e il coordinamento delle segnalazioni. Un produttore piccolo non deve costruire da zero una funzione di triage e coordinamento della divulgazione: può dichiarare nella propria politica a chi ci si rivolge, e come.

Cosa fare questa settimana

Verificate se avete un indirizzo. Aprite il vostro sito da utente anonimo e cercate dove si segnala un problema di sicurezza. Se non lo trovate in un minuto, non ce l'avete — e non è un problema di navigazione, è un problema di processo.

Scrivete una VDP di una pagina. Perimetro, canale di contatto, tempi di riscontro, cosa non fare (non esfiltrare dati, non degradare il servizio, non divulgare prima del tempo concordato), e la clausola di tutela per chi rispetta le regole. Una pagina fatta oggi vale più di dieci pagine previste per il prossimo trimestre.

Decidete chi risponde, per nome. Non «il team sicurezza» se il team sicurezza non esiste. Una persona, con una sostituta, e un impegno di riscontro che siete sicuri di poter mantenere.

Chiaritevi le idee sul CVE prima che serva. Quando arriverà la prima segnalazione vera non sarà il momento buono per studiare come si richiede un identificativo, chi lo assegna e cosa comporta.

Un'ultima nota, ed è la ragione per cui questo argomento sta nella categoria delle soluzioni aziendali e non in quella normativa. Un programma di divulgazione non è un adempimento: è un canale d'ingresso per informazioni che nessun vostro strumento produrrà mai. Il vostro monitoraggio vede ciò che succede dentro. Un ricercatore esterno vede il vostro prodotto come lo vede un attaccante — e, a differenza dell'attaccante, ha deciso di dirvelo.