Uma página de política de segurança não é um processo de divulgação

Todo o projeto sério tem uma página de segurança, e uma página é barata. A pergunta útil é se um relatório enviado pelo canal documentado produz uma versão corrigida que os utilizadores comuns consigam instalar. Isso exige quatro provas em vez de uma afirmação, e todas são verificáveis de fora sem sondar nada. Nenhuma exige um teste contra o servidor de outra pessoa. Todas cabem numa página de notas.

Encontre o canal e confirme que existe

Comece pelo percurso documentado: uma página de política de segurança, um endereço dedicado ou um ficheiro /.well-known/security.txt cujo campo Contact é definido pela RFC 9116.

Depois leia o parágrafo do âmbito em vez da introdução amigável. Que produtos são abrangidos, que versões e que tratamento pede o projeto?

Um canal que pertence a outro projeto, ou a um fornecedor de alojamento em vez do mantenedor, não é um processo de divulgação para o software que está a avaliar.

Rastreador público ou canal privado

Os defeitos comuns pertencem a um rastreador público e beneficiam dele. Um relatório com um detalhe explorável não, e apresentá-lo publicamente expõe os utilizadores enquanto o mantenedor ainda o lê.

Um projeto que só oferece um rastreador público não forneceu um canal de divulgação, diga o que disser a sua documentação.

Nada disto autoriza testar sistemas que não possui. Um endereço de denúncia é um convite a enviar informação, não uma permissão para sondar servidores públicos não relacionados.

Siga uma correção do princípio ao fim

Escolha um aviso anterior e siga-o: nomeia as versões afetadas e a versão que as corrige, e pode um utilizador instalar realmente essa versão?

Esse rasto é a diferença entre uma confirmação e uma reparação. Uma resposta educada que nunca produz uma versão é um resultado de relações públicas. Um aviso breve com um número de versão e uma ligação de transferência é um processo que funciona. Um bom aviso responde depressa a quatro coisas: o que está afetado, qual é o impacto, que versão o corrige e onde o obter.

O histórico de versões completa o resto. Versões regulares com notas claras sugerem um projeto capaz de entregar uma correção, e isso importa mais do que uma política eloquente.

Mantenedor do cliente ou operador do serviço

Para uma VPN, as pessoas que escrevem o cliente e as que operam um gateway são muitas vezes organizações diferentes. Um problema no código do cliente e um erro de implementação do servidor precisam de destinatários diferentes.

Decida a qual dos dois diz respeito a sua descoberta antes de a enviar, porque encaminhá-la para a parte errada costuma terminar em silêncio em vez de num retorno.

O que a ausência prova, e o que não prova

Uma lista de avisos vazia não demonstra que um produto esteja livre de defeitos. Pode significar um projeto jovem, uma superfície pequena ou que ninguém está a olhar.

Do mesmo modo, uma página de política ausente não é prova de má-fé. É prova de que não consegue verificar o processo, e essa é a conclusão honesta a registar.

O que registar

Registe quatro factos: um contacto que possa verificar, um âmbito que cubra a sua versão, avisos que nomeiem versões corrigidas e um histórico de versões que mostre que as correções saem.

Depois registe o que continua desconhecido. Uma revisão que o diz é mais útil do que uma que converte uma política ausente numa afirmação de segurança.