Una pagina di politica di sicurezza non è un processo di divulgazione

Ogni progetto serio ha una pagina di sicurezza, e una pagina costa poco. La domanda utile è se un rapporto inviato attraverso il canale documentato produce una versione corretta che gli utenti comuni possono installare. Servono quattro prove invece di un’affermazione, e tutte sono verificabili dall’esterno senza sondare nulla. Nessuna richiede un test contro il server di qualcun altro. Tutte stanno su una pagina di appunti.

Trovate il canale e verificate che esista

Cominciate dal percorso documentato: una pagina di politica di sicurezza, un indirizzo dedicato o un file /.well-known/security.txt il cui campo Contact è definito dalla RFC 9116.

Poi leggete il paragrafo sul perimetro invece dell’introduzione amichevole. Quali prodotti sono coperti, quali versioni e quale trattamento chiede il progetto?

Un canale che appartiene a un altro progetto, o a un fornitore di hosting invece che al manutentore, non è un processo di divulgazione per il software che state valutando.

Tracker pubblico o canale privato

I difetti ordinari stanno in un tracker pubblico e ne traggono vantaggio. Un rapporto con un dettaglio sfruttabile no, e pubblicarlo espone gli utenti mentre il manutentore lo sta ancora leggendo.

Un progetto che offre solo un tracker pubblico non ha fornito un canale di divulgazione, qualunque cosa dica la sua documentazione.

Niente di tutto questo autorizza a testare sistemi che non possedete. Un indirizzo di segnalazione è un invito a inviare informazioni, non un permesso di sondare server pubblici non correlati.

Seguite una correzione da capo a fondo

Scegliete un avviso passato e seguitelo: nomina le versioni interessate e la versione che le corregge, e un utente può davvero installare quella versione?

Quella traccia è la differenza tra una conferma e una riparazione. Una risposta gentile che non produce mai una versione è un esito di relazioni pubbliche. Un avviso conciso con un numero di versione e un link di download è un processo che funziona. Un buon avviso risponde in fretta a quattro cose: cosa è interessato, qual è l’impatto, quale versione lo corregge e dove ottenerlo.

La cronologia delle versioni completa il resto. Versioni regolari con note chiare suggeriscono un progetto capace di consegnare una correzione, e questo conta più di una politica eloquente.

Manutentore del client o operatore del servizio

Per una VPN, le persone che scrivono il client e quelle che gestiscono un gateway sono spesso organizzazioni diverse. Un problema nel codice del client e un errore di distribuzione del server richiedono destinatari diversi.

Decidete a quale dei due riguarda la vostra scoperta prima di inviarla, perché indirizzarla alla parte sbagliata di solito finisce nel silenzio invece che in un rimbalzo.

Cosa dimostra l’assenza e cosa no

Un elenco di avvisi vuoto non dimostra che un prodotto sia privo di difetti. Può significare un progetto giovane, una superficie piccola o che nessuno guarda.

Allo stesso modo, una pagina di politica assente non è prova di malafede. È prova che non potete verificare il processo, e questa è la conclusione onesta da annotare.

Cosa annotare

Annotate quattro fatti: un contatto che potete verificare, un perimetro che copre la vostra versione, avvisi che nominano versioni corrette e una cronologia delle versioni che mostri che le correzioni escono.

Poi annotate ciò che resta sconosciuto. Una revisione che lo dice è più utile di una che trasforma una politica assente in un’affermazione di sicurezza.