Cosa succede davvero quando segnali una vulnerabilità

Trovare la vulnerabilità è la parte che tutti romanticizzano: l'intuizione, il proof of concept che funziona, l'adrenalina. Ma il bug è la parte facile. La parte difficile, ingrata e spesso frustrante è quella che viene dopo: convincere la persona giusta ad ascoltare, a sistemare il problema, e a darne atto. Si chiama divulgazione coordinata, e avendo segnalato la stessa classe di bug su decine di progetti open source ho visto l'intero spettro - dal manuale perfetto al silenzio totale. Ecco come va davvero.

Il primo muro: trovare a chi scrivere

Metà della battaglia è capire dove segnalare. I progetti maturi hanno un file SECURITY.md, un canale di advisory privato (su GitHub, il bottone "Report a vulnerability") o un indirizzo security@. Moltissimi non hanno niente: nessun contatto, nessuna policy, solo un issue tracker pubblico - dove non puoi certo scrivere i dettagli di una falla - e, se sei fortunato, l'email di un maintainer. La regola d'oro per chi segnala: cerca in quest'ordine SECURITY.md, l'advisory privato della piattaforma, security@, poi il maintainer. E non scrivere mai i dettagli in un issue pubblico: trasformeresti una segnalazione responsabile in un 0-day a cielo aperto.

Il report che ottiene una risposta

Un buon report non è un atto d'accusa, è un favore reso facile da accettare. Quello che fa la differenza: un titolo chiaro, le versioni interessate, un proof of concept minimo e riproducibile, l'impatto spiegato in parole semplici (cosa può fare davvero un attaccante) e - quando puoi - una proposta di fix. Dall'altra parte, il più delle volte, c'è un volontario che mantiene il progetto nel tempo libero. Più gli rendi facile capire e agire, più è probabile che il bug venga sistemato in fretta. Un report che rispetta il tempo di chi lo legge è metà del lavoro.

Poi: il silenzio

L'esito più comune non è né un fix né un rifiuto: è il nulla. Mandi un report curato e non risponde nessuno. Non è quasi mai malafede - è banda passante. La sicurezza dell'open source spesso poggia su una sola persona con un lavoro vero e una vita oltre il repository. Cosa fare: un sollecito gentile dopo qualche giorno, una scadenza ragionevole e - se il problema è serio e il silenzio persiste - l'escalation a un coordinatore terzo come un CERT/CSIRT nazionale o CISA, che possono fare da ponte quando il contatto diretto fallisce.

Embargo, finestra di disclosure e i 90 giorni

"Coordinata" significa proprio questo: dai al progetto il tempo di rilasciare una correzione prima di rendere pubblici i dettagli. La convenzione più diffusa - resa famosa da Google Project Zero - è una finestra di 90 giorni: abbastanza perché un team serio fixi, non così tanto da lasciare gli utenti esposti all'infinito. L'embargo è l'accordo a tenere riservati i dettagli fino alla data di pubblicazione concordata. E la scadenza non è cattiveria: senza una data, "ci arriviamo" diventa "non ci arriviamo mai". La deadline è ciò che trasforma una buona intenzione in una patch.

La CVE: a cosa serve davvero

A un certo punto entra in gioco la CVE, e qui c'è un equivoco da sfatare: non è un trofeo. È un identificativo pubblico e stabile - un numero - che permette a tutti di riferirsi alla stessa vulnerabilità: gli scanner, gli SBOM, i team di difesa, gli utenti che devono capire se sono esposti. Si ottiene tramite una CNA (CVE Numbering Authority): a volte è il progetto stesso, a volte una piattaforma, a volte un'autorità "di ultima istanza" come MITRE o CISA. La CVE non rende il bug più grave; lo rende citabile. È idraulica per l'ecosistema della difesa, non una medaglia.

Quando va storto

Non tutte le segnalazioni finiscono bene, e i modi di fallire sono ricorrenti. Il fix silenzioso: il vendor corregge il bug in una release qualsiasi, senza advisory e senza credito - il problema è risolto nel codice ma gli utenti non sanno di dover aggiornare con urgenza, ed è il caso peggiore per chi usa il software. La disputa: "non è una vulnerabilità, è una scelta di design" - a volte vero, a volte un modo per chiudere la conversazione. Il mai-sistemato: riconosciuto ma lasciato lì per mesi. E il pubblico per sbaglio: qualcuno apre un issue pubblico con il PoC dentro, e l'embargo non esiste più. La maturità di un progetto si misura esattamente da come evita queste trappole.

Una checklist per chi segnala

• Trova il contatto giusto: SECURITY.md, advisory privato della piattaforma, security@, poi il maintainer. Mai un issue pubblico.
• Scrivi un report che si può azionare: versioni, PoC minimo, impatto in chiaro, fix proposto.
• Concorda una finestra: una scadenza ragionevole (i 90 giorni sono un buon default), non un ultimatum.
• Sii paziente ma presente: un sollecito gentile, poi l'escalation a un CERT/CISA se serve.
• Coordina la CVE: non per il numero, ma perché chi difende possa riferirsi al problema.
• Pubblica con responsabilità: alla data concordata, con i dettagli utili a difendersi, non a sfruttare.

La lezione

Il mito dell'hacker solitario si ferma al momento della scoperta. Ma il valore vero - per gli utenti, per chi mantiene il software e per la reputazione di chi segnala - sta tutto in ciò che viene dopo: una divulgazione gestita bene, cooperativa, silenziosa. Si misura lì la maturità di un ricercatore, non nel trovare il bug. La regola che mi porto dietro è semplice: segnala come vorresti che segnalassero un bug nel tuo codice - con cura, chiarezza e la pazienza di portare la cosa fino in fondo.