Nem toda pessoa que procura uma vulnerabilidade em um sistema pretende explorá-la. Algumas querem apenas contribuir e comunicar o problema a quem pode resolvê-lo. Mas como encontrar o canal e o responsável corretos?

Eu mesmo tive essa dificuldade várias vezes durante minha carreira. Não havia indicação de como notificar uma vulnerabilidade e geralmente não recebia uma resposta da organização, que talvez ficasse mais assustada com a notícia do que com a própria vulnerabilidade, talvez achando que eu fosse prejudicá-los!

Sabendo disso, implementamos na IMAGIX um processo de divulgação coordenada de vulnerabilidades, com uma política de recebimento de relatos além do registro publicamente disponível dos pesquisadores cujas contribuições ajudaram a aprimorar nossos serviços.

Quem encontra uma falha precisa saber a quem contar

Para quem está do lado de fora, a primeira dificuldade é prática. O endereço de contato de um site costuma levar ao atendimento geral, e quem lê a mensagem pode não saber o que é uma vulnerabilidade nem a quem repassá-la. Um relato técnico enviado por esse caminho pode receber uma resposta automática, ficar dias sem resposta ou chegar tarde a quem pode agir.

A segunda dificuldade é a incerteza sobre a reação, como mencionei nas minhas experiências acima. Quem reporta não sabe se a empresa vai agradecer, ignorar ou tratar o relato como uma ameaça. Sem nenhuma indicação pública de como a organização lida com isso, muitos pesquisadores desistem de avisar, e a falha continua disponível para um indivíduo malicioso que não tem intenção de avisar ninguém.

Um arquivo num endereço previsível

O arquivo security.txt resolve a primeira dificuldade. Definido pela RFC 9116, publicada em 2022, é um arquivo de texto simples que qualquer organização pode publicar sempre no mesmo caminho do seu domínio: /.well-known/security.txt. Quem quer relatar algo não precisa procurar pelo site, basta conhecer o domínio.

Apesar de simples, o recurso ainda é pouco usado. Um levantamento publicado em janeiro de 2025 encontrou o arquivo em cerca de 1,25% dos um milhão de domínios mais acessados do mundo, e menos da metade desses arquivos seguia a especificação.

O arquivo diz onde reportar e a política define as condições

A própria RFC deixa claro que o security.txt não substitui uma política de divulgação. Ele informa onde reportar. As condições da colaboração ficam num documento próprio, indicado pelo campo Policy.

Na política da IMAGIX, essas condições cobrem quatro pontos:

  • o que enviar: o sistema afetado, a descrição do problema e do impacto possível, os passos para reproduzi-lo e evidências sem dados sensíveis;
  • o que não fazer: violar a privacidade de alguém, destruir dados, interromper serviços, usar engenharia social ou acessar contas e dados sem autorização;
  • o que está fora de escopo: varreduras automáticas sem evidência de impacto, testes de negação de serviço e relatos baseados apenas em versões desatualizadas de software;
  • o que esperar: confirmação do recebimento em até cinco dias úteis, avaliação da gravidade, retorno a quem reportou e divulgação coordenada depois da correção.

A política também estabelece condições: a pesquisa feita de boa-fé, dentro dessas regras e sem causar dano é tratada como pesquisa de segurança autorizada. É essa garantia que permite a um pesquisador reportar sem receio de ser tratado como invasor.

Divulgação coordenada: corrigir antes de tornar público

Divulgação coordenada é o acordo de que os detalhes de uma falha só se tornam públicos depois da correção, ou depois de um prazo razoável combinado entre quem encontrou e quem precisa corrigir. Quem encontrou aguarda e quem recebeu se compromete a investigar, responder e corrigir.

O acordo protege as duas partes e, principalmente, quem usa o sistema. Publicar os detalhes de uma falha ainda aberta entrega a informação a quem quer explorá-la antes que exista correção. Manter silêncio indefinidamente, por outro lado, tira de quem reportou qualquer garantia de que o relato foi levado a sério.

O processo é descrito em normas internacionais: a ISO/IEC 29147 trata de como receber relatos e divulgar vulnerabilidades, e a ISO/IEC 30111 trata de como a organização investiga e corrige o que recebeu.

Transparência sem facilitar ataques

Uma empresa pode ser transparente sobre a existência de vulnerabilidades corrigidas, sobre seus processos de resposta e sobre o reconhecimento de pesquisadores, sem divulgar informações que facilitem ataques. O Hall da Fama é onde a IMAGIX aplica esse princípio, e ele cumpre duas funções ao mesmo tempo.

A primeira é reconhecer. Pesquisadores de segurança constroem reputação pelo trabalho que conseguem mostrar, e um registro público, com o nome de quem reportou e a descrição do que foi encontrado, é uma forma concreta de reconhecer esse trabalho.

A segunda é prestar contas. Cada entrada informa que um problema existiu, em que parte dos serviços, e que foi corrigido. Para quem confia dados a um sistema, como um serviço de saúde, isso mostra que os problemas são encontrados e que há alguém para responder quando isso acontece. Para quem pensa em reportar algo, mostra que os relatos anteriores foram recebidos, investigados e corrigidos.

Se você encontrou algo, a Política de Divulgação de Vulnerabilidades explica o que enviar e para onde.

Referências

#Segurança da informação#Divulgação de vulnerabilidades#Transparência