Divulgacao responsavel de vulnerabilidade: o que fazer quando alguem reporta uma falha na sua empresa

Por que sua empresa precisa de um canal de divulgação responsável

Divulgação responsável (ou responsible disclosure) é o processo pelo qual um pesquisador de segurança, cliente, funcionário ou até um curioso que encontrou uma falha no seu sistema consegue reportá-la diretamente para você — de forma privada, documentada e com prazo acordado — antes que a informação se torne pública. Parece um detalhe burocrático, mas é justamente o que separa um incidente contornado em silêncio de uma crise de imagem com nome da empresa em portal de notícias.

O ponto que a maioria das empresas brasileiras ignora é simples: a falha já existe. Ela não passa a existir quando alguém a reporta. Quando um pesquisador encontra uma exposição no seu portal do cliente, uma API sem autenticação ou um bucket de armazenamento aberto, ele tem três caminhos — avisar você, ignorar, ou publicar. Se não existe um canal claro para o primeiro caminho, você está estatisticamente empurrando essa pessoa para o terceiro. Não por má-fé: por falta de alternativa. Quem tenta reportar por formulário genérico de "Fale Conosco" e recebe resposta automática de SAC costuma desistir em 48 horas.

Há também um componente jurídico crescente. A LGPD, no artigo 48, obriga a comunicação de incidentes que possam acarretar risco relevante aos titulares. Um reporte externo bem triado é, na prática, sua chance de conter o problema e cumprir prazos regulatórios com controle da narrativa. Um reporte perdido na caixa de spam do marketing é a chance de descobrir o vazamento pelo jornalista que te liga pedindo posicionamento.

Como montar o canal: security.txt, e-mail dedicado e política pública

A infraestrutura mínima de um canal de divulgação responsável é surpreendentemente barata. Não exige plataforma paga, não exige equipe dedicada em tempo integral, e pode ser implantada em uma tarde. O que ela exige é decisão: alguém precisa assumir a caixa de entrada e o compromisso de responder.

Os três componentes essenciais são:

• Arquivo security.txt — padrão descrito na RFC 9116, publicado em https://seudominio.com.br/.well-known/security.txt. É um arquivo de texto simples com os campos Contact, Expires, Preferred-Languages e, opcionalmente, Policy e Encryption. Pesquisadores procuram esse arquivo antes de qualquer outra coisa. Sua ausência é interpretada como "essa empresa não quer saber".
• Endereço dedicado — security@ ou seguranca@, com encaminhamento para pelo menos duas pessoas e monitoramento ativo. Nunca aponte para caixa compartilhada de suporte nível 1, onde o ticket vira "usuário reclamando do site".
• Política publicada — uma página estática descrevendo escopo, o que é aceitável, prazos de resposta e a garantia de não retaliação jurídica a quem agir de boa-fé. Essa última cláusula, chamada de safe harbor, é o que efetivamente destrava reportes.

Sobre escopo: seja explícito quanto aos domínios, aplicações e faixas de IP incluídos, e igualmente explícito quanto ao que está fora — sistemas de terceiros, ambientes de parceiros, ataques de negação de serviço, engenharia social contra funcionários e testes de carga. Um escopo mal definido gera reportes irrelevantes que consomem tempo da equipe e frustram quem reporta.

Uma política de divulgação responsável não é um convite para invadirem sua empresa. É a admissão madura de que alguém eventualmente vai encontrar algo — e a definição prévia de como isso será tratado quando acontecer.

Triagem: separando ruído, achado real e chantagem

Publicado o canal, o volume chega. E a maior parte dele não é ataque nem descoberta valiosa: é ruído automatizado. Scanners genéricos rodados por aspirantes a pesquisador geram relatórios de "vulnerabilidade" que são, na verdade, cabeçalhos HTTP ausentes, versões de servidor expostas ou avisos de configuração de SPF. Um processo de triagem eficiente precisa filtrar isso em minutos, não em dias.

Um fluxo de triagem funcional segue esta ordem:

1. Acusar recebimento em até 24 horas úteis. Resposta humana, curta, com número de protocolo. Isso sozinho já reduz drasticamente o risco de divulgação pública precoce — o pesquisador sente que foi ouvido.
2. Classificar a severidade. Use CVSS ou uma escala interna simples (crítico / alto / médio / baixo). Pergunte objetivamente: há dado pessoal ou financeiro exposto? Há execução de código? Há acesso a conta de terceiro sem autenticação?
3. Reproduzir em ambiente controlado. Nunca aceite o relatório pelo texto. Se a evidência enviada não permite reprodução, peça passos detalhados antes de mobilizar equipe.
4. Definir prazo de correção e comunicar. Prazos usuais de mercado: 30 dias para crítico, 90 dias para os demais. Comunique o prazo ao pesquisador e cumpra — ou avise antes de estourar.
5. Fechar o ciclo. Confirme a correção, permita a validação pelo autor do reporte e combine a data de eventual divulgação pública.

Existe uma categoria à parte que precisa ser reconhecida de imediato: a extorsão. Mensagens que exigem pagamento antes de revelar a falha, que ameaçam publicar dados em prazo curto, ou que incluem amostras de registros reais de clientes não são divulgação responsável — são incidente de segurança em curso. Nesse caso, o fluxo muda: acione o plano de resposta a incidentes, preserve evidências, envolva o jurídico e considere registro de ocorrência. Não negocie por e-mail corporativo sem orientação formal.

Recompensa, reconhecimento e a decisão sobre bug bounty

Bug bounty é o modelo em que a empresa paga valores predefinidos por vulnerabilidade validada, geralmente via plataformas intermediárias. Funciona muito bem para empresas com superfície digital ampla, produto próprio exposto à internet e equipe de segurança madura o suficiente para absorver o volume. Para a maioria das empresas de médio porte no Brasil, entretanto, começar por bug bounty é colocar o carro na frente dos bois.

A sequência saudável de maturidade é outra:

• Fase 1 — Canal aberto. security.txt, política pública, sem recompensa financeira. Custo próximo de zero.
• Fase 2 — Reconhecimento. Página de agradecimentos (hall of fame) com nome dos pesquisadores que contribuíram. Muitos profissionais valorizam mais isso que dinheiro, porque compõe portfólio.
• Fase 3 — Recompensa pontual. Valores simbólicos ou brindes para achados de alta severidade, ainda sem programa formal.
• Fase 4 — Programa privado. Convite a um grupo restrito de pesquisadores, com escopo fechado e pagamento.
• Fase 5 — Programa público. Só quando existir capacidade de triagem sustentada e correção rápida.

Pular etapas costuma sair caro. Empresas que abrem programa público sem processo interno acumulam fila de reportes não respondidos, perdem credibilidade na comunidade e acabam com o pior dos cenários: pagaram pela exposição e mesmo assim viraram caso público por demora na correção.

O que fazer nas primeiras 72 horas de um reporte crítico

Quando o reporte é real e grave, o relógio começa a correr em várias frentes simultâneas — técnica, jurídica e reputacional. Ter esse roteiro escrito antes evita improviso sob pressão.

Nas primeiras horas, a prioridade é conter sem destruir evidência. Isso significa aplicar mitigação imediata — bloqueio de endpoint, regra de WAF, revogação de chave, desativação temporária de funcionalidade — enquanto se preservam registros de acesso, logs de aplicação e imagens dos sistemas envolvidos. Muitas empresas cometem o erro de "limpar" o ambiente antes de coletar evidências, e depois não conseguem determinar se houve exploração real da falha por terceiros.

Em paralelo, é preciso responder a uma pergunta que muda todo o encaminhamento: a vulnerabilidade foi apenas descoberta ou foi explorada? Se a análise de logs indicar acesso indevido a dados pessoais, o caso deixa de ser gestão de vulnerabilidade e passa a ser incidente com dados pessoais, com deveres de comunicação à ANPD e aos titulares afetados. A distinção precisa ser feita com base em evidência, não em otimismo.

Por fim, alinhe a comunicação com quem reportou. Mantenha a pessoa informada, agradeça formalmente e negocie a data de divulgação pública em vez de tentar impedi-la. Tentativas de silenciar pesquisadores com ameaça jurídica têm histórico consistente de resultado inverso: transformam um problema técnico contornável em pauta de repercussão nacional.

Como a Duk apoia empresas nesse processo

Estruturar canal de divulgação responsável é menos sobre ferramenta e mais sobre processo, responsáveis definidos e capacidade real de corrigir dentro do prazo prometido. É exatamente aí que a maior parte das empresas trava — não falta boa intenção, falta quem opere o ciclo de ponta a ponta quando o reporte chega numa sexta-feira à noite.

Com mais de 18 anos de atuação e 550+ empresas atendidas, a Duk Informática & Cloud apoia clientes na implantação do security.txt e da política pública, na definição de escopo e severidade, na triagem técnica dos reportes recebidos e na correção efetiva das falhas validadas — com monitoramento contínuo e SLA de resposta. Como Microsoft Gold Partner, também cobrimos o lado de identidade e ambiente Microsoft 365, onde boa parte das exposições reportadas costuma ter origem: permissões excessivas, compartilhamentos públicos e contas sem MFA.

Se sua empresa ainda não tem um endereço público para receber esse tipo de reporte, o primeiro passo é pequeno e vale mais que qualquer projeto de longo prazo: publique o canal, defina quem responde e escreva o roteiro das primeiras 72 horas. Nossa equipe pode conduzir esse desenho junto com o seu time e assumir a operação técnica do ciclo — para que o próximo reporte chegue no lugar certo, na hora certa, e termine em correção em vez de manchete.