Una pàgina de política de seguretat no és un procés de divulgació

Cada projecte seriós té una pàgina de seguretat, i una pàgina és barata. La pregunta útil és si un informe enviat pel canal documentat produeix una versió corregida que els usuaris corrents puguin instal·lar. Calen quatre proves en lloc d’una afirmació, i totes són verificables des de fora sense sondejar res. Cap no requereix una prova contra el servidor d’una altra persona. Totes caben en una pàgina de notes.

Trobeu el canal i comproveu que existeix

Comenceu per la ruta documentada: una pàgina de política de seguretat, una adreça dedicada o un fitxer /.well-known/security.txt el camp Contact del qual està definit per RFC 9116.

Després llegiu el paràgraf de l’abast en lloc de la introducció amable. Quins productes es cobreixen, quines versions i quin tracte demana el projecte?

Un canal que pertany a un altre projecte, o a un proveïdor d’allotjament en lloc del mantenidor, no és un procés de divulgació per al programari que avalueu.

Rastrejador públic o canal privat

Els defectes ordinaris van a un rastrejador públic i se’n beneficien. Un informe amb un detall explotable no, i presentar-lo públicament exposa els usuaris mentre el mantenidor encara el llegeix.

Un projecte que només ofereix un rastrejador públic no ha proporcionat un canal de divulgació, digui el que digui la seva documentació.

Res d’això autoritza provar sistemes que no posseïu. Una adreça de denúncia és una invitació a enviar informació, no un permís per sondejar servidors públics no relacionats.

Seguiu una correcció de principi a fi

Triïu un avís anterior i resseguiu-lo: anomena les versions afectades i la versió que les corregeix, i pot un usuari instal·lar realment aquella versió?

Aquest rastre és la diferència entre un reconeixement i una reparació. Una resposta amable que mai no produeix una versió és un resultat de relacions públiques. Un avís breu amb un número de versió i un enllaç de descàrrega és un procés que funciona. Un bon avís respon de pressa quatre coses: què està afectat, quin és l’impacte, quina versió ho corregeix i on aconseguir-la.

L’historial de versions completa la resta. Les versions regulars amb notes clares suggereixen un projecte que pot lliurar una correcció, cosa que importa més que una política eloqüent.

Mantenidor del client o operador del servei

Per a una VPN, les persones que escriuen el client i les que operen una passarel·la sovint són organitzacions diferents. Un problema al codi del client i un error de desplegament del servidor necessiten destinataris diferents.

Decidiu a quin dels dos afecta la vostra troballa abans d’enviar-la, perquè encaminar-la a la part equivocada sol acabar en silenci en lloc d’un rebot.

Què prova l’absència i què no

Una llista d’avisos buida no demostra que un producte estigui lliure de defectes. Pot significar un projecte jove, una superfície petita o que ningú no mira.

Igualment, una pàgina de política absent no és prova de mala fe. És prova que no podeu verificar el procés, i aquesta és la conclusió honesta que cal anotar.

Què cal anotar

Anoteu quatre fets: un contacte que podeu verificar, un abast que cobreix la vostra versió, avisos que anomenen versions corregides i un historial de versions que mostra que les correccions surten.

Després anoteu què queda desconegut. Una revisió que ho diu és més útil que una que converteix una política absent en una afirmació de seguretat.