In un progetto open source tutto avviene in pubblico: issue, discussioni, revisioni, commit. È uno dei suoi punti di forza, ma diventa un problema quando qualcuno scopre una vulnerabilità. Se la falla viene descritta in una issue aperta prima che esista una correzione, chiunque può sfruttarla contro gli utenti. Per questo anche il progetto più piccolo ha bisogno di un processo, semplice ma scritto, per ricevere e gestire le segnalazioni di sicurezza.
Il file SECURITY.md
Il punto di partenza è un file SECURITY.md nella radice del repository. Molte piattaforme di hosting lo mostrano in evidenza. Deve rispondere a poche domande:
- quali versioni sono supportate e ricevono correzioni di sicurezza;
- come segnalare in privato: un indirizzo email dedicato, un modulo o la funzione di segnalazione privata offerta dalla piattaforma;
- cosa includere nella segnalazione;
- tempi indicativi: entro quanto si riceverà una conferma;
- politica di divulgazione: come e quando la vulnerabilità sarà resa pubblica.
Un esempio minimo:
## Versioni supportate
Ricevono correzioni di sicurezza le versioni 3.x e 2.9.x.
## Segnalare una vulnerabilità
Non aprire una issue pubblica. Usa la segnalazione privata del
repository oppure scrivi all'indirizzo di sicurezza del progetto.
Indica versione, passi per riprodurre e impatto stimato.
Riceverai una conferma entro cinque giorni lavorativi.
La divulgazione coordinata
Il modello più diffuso è la divulgazione coordinata: chi scopre la falla la comunica in privato al progetto, il progetto prepara la correzione e, a rilascio avvenuto, entrambi rendono pubblici i dettagli. Spesso si concorda una scadenza massima entro cui la divulgazione avverrà comunque, per evitare che una segnalazione resti ignorata indefinitamente.
Il processo tipico si articola in fasi:
- ricezione e conferma della segnalazione;
- verifica: riprodurre il problema e valutarne la gravità;
- correzione in un ramo privato o in un repository riservato;
- richiesta di un identificativo, se previsto;
- rilascio delle versioni corrette;
- pubblicazione dell'avviso con descrizione, versioni interessate e soluzione;
- riconoscimento a chi ha segnalato, se lo desidera.
Valutare la gravità
Non tutte le vulnerabilità sono uguali. Per decidere la priorità contano alcune domande:
- serve un accesso autenticato o basta una richiesta anonima?
- l'attacco è possibile da remoto o richiede accesso locale?
- cosa ottiene l'attaccante: lettura di dati, modifica, esecuzione di codice?
- la configurazione predefinita è vulnerabile o solo una configurazione rara?
Esistono sistemi di punteggio standardizzati, come CVSS, che traducono queste domande in un valore numerico. Sono utili per comunicare in modo uniforme, ma il giudizio di chi conosce il codice resta essenziale.
Identificativi CVE e avvisi
Un identificativo CVE dà alla vulnerabilità un nome univoco, usato da scanner, distribuzioni e strumenti di gestione delle dipendenze. Molte piattaforme di hosting e diverse fondazioni possono assegnarlo direttamente al progetto.
L'avviso pubblicato dovrebbe contenere:
| Campo | Contenuto |
|---|---|
| Descrizione | Cosa succede, senza un exploit pronto all'uso |
| Versioni interessate | Intervallo preciso |
| Versioni corrette | Dove si trova la correzione |
| Gravità | Valutazione e motivazione |
| Mitigazioni | Cosa fare se non si può aggiornare subito |
| Riconoscimenti | Chi ha segnalato, se acconsente |
Errori da evitare
- Correggere in silenzio: un commit «sistema un piccolo problema» senza avviso lascia gli utenti senza motivo per aggiornare, mentre chi legge i diff capisce benissimo di cosa si tratta.
- Discutere la falla in pubblico prima della correzione, anche solo in un commento.
- Ignorare chi segnala: chi non riceve risposta finisce spesso per pubblicare da solo.
- Non avere un piano per le versioni vecchie: se una versione non è più supportata, va detto chiaramente nell'avviso.
Per chi segnala
Se scopri una vulnerabilità in un progetto altrui, segui la procedura indicata, fornisci informazioni sufficienti a riprodurre il problema, rispetta i tempi concordati e non sfruttare la falla oltre il minimo necessario per dimostrarla. Se il progetto non ha alcun canale privato, cerca un contatto diretto dei manutentori o rivolgiti alla piattaforma che lo ospita.
Nel mio lavoro ho visto che la differenza tra un incidente contenuto e uno grave dipende spesso dalle prime quarantotto ore dopo la segnalazione: sapere già chi la riceve e cosa fare evita improvvisazioni.
In sintesi
- Ogni progetto ha bisogno di un
SECURITY.mdcon versioni supportate e canale privato. - La divulgazione coordinata protegge gli utenti finché la correzione non è disponibile.
- Gravità, identificativo CVE e avviso completo aiutano gli utenti a reagire in fretta.
- Non correggere mai in silenzio e rispondi sempre a chi segnala.
