Unha páxina de política de seguridade non é un proceso de divulgación

Todo proxecto serio ten unha páxina de seguridade, e unha páxina é barata. A pregunta útil é se un informe enviado pola canle documentada produce unha versión corrixida que os usuarios correntes poidan instalar. Iso esixe catro probas en lugar dunha afirmación, e todas son verificables desde fóra sen sondar nada. Ningunha require unha proba contra o servidor doutra persoa. Todas caben nunha páxina de notas.

Atope a canle e comprobe que existe

Comece pola ruta documentada: unha páxina de política de seguridade, un enderezo dedicado ou un ficheiro /.well-known/security.txt cuxo campo Contact está definido por RFC 9116.

Despois lea o parágrafo do alcance en lugar da introdución amable. Que produtos se cobren, que versións e que trato pide o proxecto?

Unha canle que pertence a outro proxecto, ou a un provedor de aloxamento en lugar do mantedor, non é un proceso de divulgación para o software que avalía.

Rastrexador público ou canle privada

Os defectos ordinarios van a un rastrexador público e benefícianse del. Un informe cun detalle explotable non, e presentalo en público expón os usuarios mentres o mantedor aínda o le.

Un proxecto que só ofrece un rastrexador público non proporcionou unha canle de divulgación, diga o que diga a súa documentación.

Nada disto autoriza probar sistemas que non posúe. Un enderezo de denuncia é unha invitación a enviar información, non un permiso para sondar servidores públicos non relacionados.

Siga unha corrección de principio a fin

Escolla un aviso anterior e rastréxeo: nomea as versións afectadas e a versión que as corrixe, e pode un usuario instalar realmente esa versión?

Ese rastro é a diferenza entre un acuse de recibo e unha reparación. Unha resposta amable que nunca produce unha versión é un resultado de relacións públicas. Un aviso breve cun número de versión e unha ligazón de descarga é un proceso que funciona. Un bo aviso responde de presa a catro cousas: que está afectado, cal é o impacto, que versión o corrixe e onde conseguilo.

O historial de versións completa o resto. As versións regulares con notas claras suxiren un proxecto que pode entregar unha corrección, o que importa máis ca unha política elocuente.

Mantedor do cliente ou operador do servizo

Para unha VPN, as persoas que escriben o cliente e as que operan unha pasarela adoitan ser organizacións distintas. Un problema no código do cliente e un erro de despregamento do servidor necesitan destinatarios diferentes.

Decida a cal dos dous afecta o seu achado antes de envialo, porque dirixilo á parte equivocada adoita acabar en silencio en lugar de nun rebote.

Que proba a ausencia e que non

Unha lista de avisos baleira non demostra que un produto estea libre de defectos. Pode significar un proxecto novo, unha superficie pequena ou que ninguén mira.

Igualmente, unha páxina de política ausente non é proba de mala fe. É proba de que non pode verificar o proceso, e esa é a conclusión honesta que cómpre anotar.

Que anotar

Anote catro feitos: un contacto que poida verificar, un alcance que cubra a súa versión, avisos que nomeen versións corrixidas e un historial de versións que mostre que as correccións saen.

Despois anote que queda descoñecido. Unha revisión que o di é máis útil ca unha que converte unha política ausente nunha afirmación de seguridade.