Vulnerability disclosure responsabile: come gestire la scoperta di una falla in produzione
Il 3 febbraio 2025 stavo eseguendo un penetration test commissionato da un cliente su una loro applicazione PHP custom. Durante l'attività ho notato che l'applicazione si integrava con un sistema gestionale verticale italiano ampiamente diffuso nel settore - un software prodotto da un vendor italiano con circa 300 PMI paganti come clienti attivi. Per curiosità professionale, ho testato anche l'applicazione gestionale stessa (con autorizzazione del mio cliente che la utilizza regolarmente) e ho scoperto una vulnerabilità critica - una remote code execution non autenticata tramite un endpoint upload file malconfigurato - che permetteva a qualunque attaccante con accesso Internet all'istanza del gestionale di eseguire codice arbitrario sul server.
Il problema è che non ero cliente del vendor del gestionale. Non avevo obbligo contrattuale di riportare la vulnerabilità, non avevo alcun rapporto professionale con loro. Le mie opzioni erano tre. Prima opzione: ignorare la scoperta e non fare nulla (moralmente insoddisfacente - 300 PMI italiane erano a rischio concreto di compromissione). Seconda opzione: pubblicare la vulnerabilità pubblicamente (responsabilmente scorretto - avrebbe permesso a malintenzionati di sfruttarla prima del fix). Terza opzione: responsible disclosure al vendor, seguendo pattern etico standard della comunità security. Ho scelto la terza opzione e ho passato i due mesi successivi a gestire un processo di disclosure complicato - il vendor non aveva canale di security disclosure documentato, i tempi di fix erano incerti, la comunicazione con i loro responsabili tecnici è stata frammentata.
In questo articolo descrivo il processo di disclosure come l'ho condotto, con le decisioni prese, gli errori commessi (di cui ce ne sono stati), e le lezioni apprese. Il tema è rilevante per chiunque lavori nel mondo security o sviluppo PHP perché la scoperta di vulnerabilità in software third-party non è un evento raro - a chiunque si occupi seriamente di sicurezza applicativa capita regolarmente. Il principio guida è uno: la responsible disclosure è un equilibrio delicato fra proteggere gli utenti finali della vulnerabilità, incentivare il vendor a fissare rapidamente, rispettare i diritti legali di tutte le parti coinvolte, e mantenere la propria reputazione professionale intatta.
Se ti occupi professionalmente di offensive security o penetration testing e ti trovi regolarmente a gestire scoperte di vulnerabilità in software third-party, nel mio profilo professionale trovi il dettaglio delle attività di offensive security e responsible disclosure condotte per contesti PMI italiane, con approccio etico e documentazione formale per ogni caso gestito.
Il framework di responsible disclosure: il consenso della comunità security
La responsible disclosure (o coordinated vulnerability disclosure, CVD) è la pratica di riportare vulnerabilità privatamente al vendor, dare loro tempo ragionevole per fissare il problema, e solo successivamente divulgare pubblicamente i dettagli della vulnerabilità. La norma ISO/IEC 29147 sul Vulnerability Disclosure formalizza il processo, e la pratica è adottata universalmente dalla community security da almeno vent'anni.
Il framework standard che applico in disclosure seguendo la guida CERT/CC al coordinated vulnerability disclosure include sei fasi sequenziali. Fase 1 - Scoperta: la vulnerabilità è identificata da un ricercatore, che ne valida sfruttabilità e impatto. Fase 2 - Contatto iniziale: il ricercatore contatta il vendor attraverso il canale appropriato con i dettagli della vulnerabilità. Fase 3 - Negoziazione timeline: vendor e ricercatore concordano una timeline ragionevole per il fix, tipicamente 90 giorni. Fase 4 - Sviluppo fix: il vendor sviluppa e testa la correzione. Fase 5 - Rilascio fix: il vendor rilascia la correzione ai suoi clienti. Fase 6 - Disclosure pubblica: dopo che la maggioranza dei clienti ha applicato il fix (tipicamente 30-90 giorni dopo il rilascio), i dettagli tecnici della vulnerabilità possono essere pubblicati.
Il timing di 90 giorni deriva dalla policy di Project Zero di Google ed è diventato standard de facto della community. È un compromesso fra due pressioni opposte: dare abbastanza tempo al vendor di risolvere in modo pulito, ma non tanto da incentivare procrastinazione che lascia gli utenti finali esposti indefinitamente.
Il problema: il vendor italiano senza canale security
Il primo problema concreto che ho affrontato è stato trovare il canale corretto per contattare il vendor. Molti vendor internazionali maturi hanno canali dedicati: [email protected], security.txt nel loro dominio web, programmi bug bounty formalizzati (HackerOne, Bugcrowd). Il vendor italiano coinvolto non aveva niente di questo. Il loro sito web aveva un generic [email protected] e un modulo di supporto tecnico destinato esclusivamente a clienti paganti.
Il pattern che ho applicato è stato progressivo. Primo tentativo: email a [email protected] con titolo "[SECURITY] Vulnerabilità critica scoperta - richiesta contatto con responsabile tecnico" e corpo generico che non rivelava dettagli tecnici ma indicava urgenza. Nessuna risposta in 72 ore. Secondo tentativo: ricerca su LinkedIn dei responsabili tecnici del vendor (CTO, CISO, responsabile sviluppo), identificazione di due persone con ruolo rilevante, contatto diretto via LinkedIn message con testo equivalente. Uno dei due mi ha risposto dopo 48 ore aprendo un canale email diretto per continuare la conversazione.
Questa esperienza mi ha portato a una conclusione importante: la scoperta di una vulnerabilità in un vendor italiano senza canale security richiede skills di business development oltre che skills tecniche. Non è sufficiente essere bravo in security - serve anche capacità di trovare le persone giuste e comunicare in modo efficace con gente non tecnica che può non capire inizialmente la gravità della situazione.
Il report di vulnerabilità: struttura e contenuti
Una volta stabilito il contatto, il secondo step è la trasmissione del report di vulnerabilità - documento tecnico che descrive in dettaglio il problema, permette al vendor di riprodurlo, documenta l'impatto. Il report ideale include otto sezioni.
Sezione 1 - Informazioni generali: nome del ricercatore, affiliation (se rilevante), data scoperta, canale di contatto preferito per follow-up.
Sezione 2 - Sommario esecutivo: descrizione in 1-2 paragrafi della vulnerabilità e del suo impatto, comprensibile anche a lettori non tecnici (CTO, management).
Sezione 3 - Dettagli tecnici: descrizione tecnica precisa del bug, endpoint interessato, parametri vulnerabili, meccanismo di sfruttamento.
Sezione 4 - Proof of concept: esempio concreto riproducibile - tipicamente curl command o script Python che dimostra lo sfruttamento su un'istanza test.
Sezione 5 - Impatto: CVSS score calcolato con calcolatrice standard, categoria CWE se applicabile, scenari di sfruttamento realistico, potenziale danno.
Sezione 6 - Mitigazioni temporanee: se esistono workaround applicabili dai clienti prima del fix ufficiale (es. disabilitare funzionalità specifica, configurazione firewall), elencarli.
Sezione 7 - Suggerimenti per il fix: proposta tecnica di correzione, se il ricercatore ha idee costruttive.
Sezione 8 - Timeline proposta: data proposta per disclosure pubblica (tipicamente +90 giorni), con nota che è negoziabile.
Per la vulnerabilità che ho trovato, il report finale era di 12 pagine inclusive di 3 screenshot del PoC. L'ho trasmesso al responsabile tecnico tramite email cifrata con PGP (la sua chiave pubblica era disponibile su un keyserver standard, dato che conoscevo già il suo nome).
La negoziazione timeline: quando il vendor vuole più tempo
Il vendor mi ha risposto in 4 giorni confermando la ricezione, la riproducibilità del bug, e la severity critica. Ma ha richiesto un'estensione della timeline: 180 giorni invece dei 90 standard, motivando con la necessità di deployment coordinato ai loro 300 clienti PMI, di cui una parte aveva installazioni on-premise custom che richiedevano test specifici.
La negoziazione timeline è il momento più delicato della responsible disclosure. Il ricercatore deve bilanciare empatia verso le difficoltà operative del vendor con la responsabilità verso gli utenti finali che sono esposti mentre il fix viene sviluppato. La mia regola generale è concedere estensioni ragionevoli quando il vendor dimostra buona fede e sta genuinamente lavorando al fix, ma non concedere estensioni illimitate che diventano procrastinazione.
Per il caso specifico, ho accettato un compromesso: timeline di 135 giorni (4,5 mesi) con requisito di milestone intermedie - report di stato ogni 30 giorni, prima versione di patch disponibile entro 90 giorni per installation pilot, rollout completo entro 135 giorni, disclosure pubblica coordinata al completamento. Questa struttura ha fornito visibilità al vendor sul mio impegno a collaborare costruttivamente e ha fornito a me visibilità sul progresso reale del fix.
La fase di sviluppo fix: communication cadence
Durante i 135 giorni di sviluppo del fix, ho mantenuto una comunicazione cadenced con il responsabile tecnico del vendor. Ogni 30 giorni riceveva un status update via email, ogni 60 giorni facevamo una video call di 30 minuti per discutere progress e issue emergenti. Il mio ruolo in questa fase era duplice: validatore tecnico (rivedere versioni intermedie del fix per confermare che risolvesse davvero il problema senza introdurre regressioni), e interlocutore che ricordava garbatamente la timeline concordata.
Al giorno 90 il vendor ha consegnato la prima beta del fix per mia revisione. Il fix iniziale risolveva la vulnerabilità principale ma io ho identificato un secondo vettore di attacco correlato che la prima versione del fix non gestiva - una variante dell'exploit che bypassava il controllo introdotto. Ho comunicato questo al vendor che ha rivisto il fix nel mese successivo. Questa interazione è esattamente ciò che la responsible disclosure dovrebbe produrre: collaborazione costruttiva fra ricercatore e vendor per arrivare a un fix solido.
La disclosure pubblica: coordination e contenuto
Al giorno 135, il vendor ha completato il rollout ai propri clienti (rilascio automatico via aggiornamento a pagamento per installation cloud, rilascio disponibile per download per installation on-premise con notifica urgente ai clienti). Abbiamo concordato la disclosure pubblica per il giorno 140 - una finestra di 5 giorni extra per permettere ai clienti più lenti di aggiornare.
Il contenuto della disclosure pubblica ha incluso: advisory tecnico dettagliato pubblicato sul mio blog personale e sul blog del vendor, registrazione CVE tramite il MITRE CVE Program, tweet con link alla pubblicazione per amplificazione sulla community, notifica al CERT Nazionale italiano tramite il canale dedicato. L'advisory tecnico seguiva lo stesso schema del report iniziale ma orientato a lettori esterni (non il vendor stesso), con enfasi su "come verificare di essere patchato" per aiutare i clienti a confermare la propria postura post-fix.
Considerazioni legali: il labirinto italiano
Uno degli aspetti che rende responsible disclosure particolarmente complessa in Italia è il quadro normativo. L'articolo 615-ter del codice penale italiano punisce l'accesso abusivo a sistema informatico anche quando le intenzioni del ricercatore sono benevole - tecnicamente, testare un exploit contro un sistema terzo anche solo per verificarne la sfruttabilità può configurare il reato. Molti ricercatori italiani evitano completamente disclosure a vendor italiani per questa ragione, con il risultato che vulnerabilità in software italiano restano non corrette più a lungo di quelle in software internazionali.
La protezione legale che il ricercatore ha durante disclosure dipende dalla formulazione specifica della comunicazione con il vendor e dalla documentazione della buona fede. Il pattern operativo che applico include: consulenza legale preventiva con avvocato specializzato in diritto informatico prima di inviare report, trasmissione del report tramite canali che lasciano tracciabilità chiara (email PGP-cifrata preferibile a Signal o Telegram, PEC per particolare rilevanza legale), conservazione di tutta la corrispondenza per 10 anni minimo, astensione da qualunque azione sui sistemi del vendor oltre la validazione tecnica della vulnerabilità.
Alcuni vendor seri internazionali offrono safe harbor - una dichiarazione contrattuale pubblica che il vendor non perseguirà legalmente i ricercatori che seguono responsible disclosure secondo regole specifiche. È un elemento di maturità security che vorrei vedere adottato anche da vendor italiani in modo più diffuso.
Il ruolo della community: CVE, CERT, divulgazione responsabile
Dopo la disclosure pubblica, la vulnerabilità entra nel ciclo di vita standard della community security. Il CVE assegnato viene referenziato da scanner automatici (Nessus, OpenVAS, Trivy), database di vulnerabilità (NVD, Snyk DB, Github Security Advisories), security feed di notizie che copre ambito infosec. Questa visibilità è strumentale: facilita la patch adoption, permette alle aziende di includere la vulnerabilità nei loro processi di vulnerability management, contribuisce all'ecosistema di conoscenza security globale.
La pratica professionale della disclosure si integra con il framework complessivo di costruzione di cultura della sicurezza informatica come processo continuo e con i pattern di threat modeling PMI per identificare i rischi prima del codice - entrambi necessari sia dal lato ricercatore che dal lato vendor per maturità security complessiva.
Lezioni apprese personalmente dal caso specifico
Dalla gestione di questa specifica disclosure (e da altre precedenti in scala più ridotta), le lezioni personali che ho internalizzato sono cinque. Prima lezione: il report tecnico iniziale deve essere fatto con cura straordinaria - è la prima impressione che il vendor ha del ricercatore, e determina il tono della collaborazione successiva. Investire mezza giornata extra in un report chiaro, strutturato e costruttivo paga enormemente. Seconda lezione: l'empatia operativa con il vendor facilita collaborazione. Capire che il vendor ha altre priorità, altri bug, limiti di budget e team - e negoziare tenendone conto - produce risultati migliori di approccio aggressivo. Terza lezione: documentare tutto in formato tracciabile. In caso di disputa o escalation legale, avere log completo di ogni comunicazione è critico. Quarta lezione: non farlo gratis, o falla con scope chiaro. Dedicare mesi a disclosure non pagata di software di cui non sei cliente può essere moralmente soddisfacente ma economicamente pesante. Quinta lezione: non tutti i vendor meritano responsible disclosure illimitata. Se un vendor è sistematicamente non collaborativo, nasconde informazioni, ritarda senza ragione valida, il ricercatore ha diritto a pubblicare anche prima della timeline originaria - il safe harbor morale di responsible disclosure vale solo in presenza di buona fede reciproca.
Se sei uno sviluppatore o security professional che ha scoperto una vulnerabilità in software third-party e non sai come procedere, il processo di responsible disclosure è meno complicato di quanto sembri ma richiede disciplina. Se vuoi confrontarti sul tuo caso specifico con guidance sul processo di disclosure, contattami per una sessione preliminare: in una consulenza guidata valutiamo insieme il caso, la struttura del report tecnico appropriato, la strategia di comunicazione con il vendor, e gli aspetti legali italiani specifici al tuo caso.