No contexto da segurança da informação, a forma como vulnerabilidades são reportadas pode ser tão crítica quanto a própria descoberta. Um processo de reporte bem estruturado não apenas acelera a correção, mas também protege os usuários, mantém a confiança no ecossistema e evita danos legais e reputacionais. Esta aula aborda os quatro pilares do reporting de vulnerabilidades: disclosure, severidade, timeline e remediação.

Vamos explorar desde os modelos de divulgação (como divulgação total, coordenada e privada) até a construção de cronogramas realistas que equilibrem a urgência da correção com a necessidade de qualidade. Você aprenderá a classificar vulnerabilidades usando padrões reconhecidos (CVSS), a comunicar riscos de forma clara e a acompanhar o ciclo de vida de uma correção até sua validação final.

Disclosure

O termo disclosure refere-se ao processo de revelar uma vulnerabilidade a terceiros. A escolha do tipo de disclosure impacta diretamente a segurança dos usuários e o relacionamento com o fornecedor do software. Existem três abordagens principais: divulgação total, divulgação coordenada (anteriormente chamada de 'responsável') e divulgação privada.

Divulgação total envolve a publicação imediata e completa dos detalhes da vulnerabilidade, sem dar ao fornecedor tempo para preparar uma correção. Isso força uma ação rápida, mas pode deixar sistemas expostos se a correção não for rápida. Divulgação coordenada é o meio-termo: o pesquisador informa o fornecedor em privado, dá um prazo razoável para corrigir e só publica após o prazo ou após a correção. Divulgação privada ocorre quando a vulnerabilidade é compartilhada apenas com o fornecedor, sem publicação pública, geralmente para casos de alto risco ou acordos de confidencialidade.

Na prática, a divulgação coordenada é a mais recomendada por iniciativas como o CERT e o OWASP, pois equilibra a necessidade de transparência com a segurança dos usuários. O pesquisador deve sempre tentar estabelecer um contato claro com o fornecedor, enviando um relatório detalhado que inclua passos de reprodução, impacto potencial e uma sugestão de correção.

Exemplo de comunicação inicial a um fornecedor:

Assunto: [Vulnerabilidade] Falha de autenticação no módulo X

Olá, equipe de segurança,

Identifiquei uma vulnerabilidade de autenticação no módulo X, versão 1.2.3.
Um atacante pode contornar a verificação de senha enviando uma requisição
malformada. Segue um PoC que demonstra o problema.

Impacto: Acesso não autorizado a contas de usuários.

Sugestão: Validar a entrada no servidor e implementar autenticação em duas
etapas.

Estou disponível para fornecer mais detalhes. Qual é o prazo estimado para
correção?

Atenciosamente,
[Seu Nome]

Severity

A severidade de uma vulnerabilidade indica o grau de risco que ela representa. Uma classificação adequada ajuda as equipes a priorizar correções e a comunicar a urgência a stakeholders não técnicos. O padrão mais usado é o CVSS (Common Vulnerability Scoring System), atualmente na versão 3.1, que gera uma pontuação de 0 a 10 com base em vetores que avaliam vetor de ataque, complexidade, privilégios necessários, interação do usuário e impacto na confidencialidade, integridade e disponibilidade.

Além do CVSS, organizações costumam usar classificações qualitativas: Crítica (9.0-10.0), Alta (7.0-8.9), Média (4.0-6.9), Baixa (0.1-3.9) e Nenhuma (0.0). A severidade deve ser calculada com base no pior cenário realista, considerando o contexto da instalação. Por exemplo, uma vulnerabilidade que exige acesso físico ao servidor pode ser menos severa em um data center seguro do que em um quiosque público.

Ao reportar, inclua a pontuação CVSS e o vetor, pois isso permite que outros especialistas compreendam a classificação. Um erro comum é superestimar a severidade para forçar uma correção rápida, o que pode levar a alertas desnecessários. Por outro lado, subestimar pode atrasar correções críticas. Por isso, sempre documente os fatores que influenciaram a pontuação.

Exemplo de cálculo de severidade CVSS v3.1:

Vetor: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

AV:N = Rede (explorável remotamente)
AC:L = Baixa complexidade
PR:N = Nenhum privilégio necessário
UI:N = Nenhuma interação do usuário
S:U = Escopo inalterado
C:H, I:H, A:H = Alto impacto na confidencialidade, integridade e disponibilidade

Pontuação base: 9.8 (Crítica)

Timeline

A timeline (cronograma) define os prazos para cada etapa do processo de divulgação e correção. Uma timeline bem construída reduz o risco de exposição prolongada e demonstra profissionalismo. O ponto de partida é a data em que o fornecedor confirma o recebimento do relatório. A partir daí, o pesquisador e o fornecedor devem acordar marcos como: confirmação da vulnerabilidade, data de correção planejada, data de lançamento do patch e data de divulgação pública.

Prazos comuns variam: vulnerabilidades críticas podem exigir correção em 7 dias; alta, 30 dias; média, 90 dias; baixa, 120 dias ou mais. No entanto, esses valores são apenas referências – cada caso deve ser avaliado individualmente. Se o fornecedor não responder ou recusar corrigir, o pesquisador pode considerar reduzir o prazo e partir para divulgação pública, respeitando princípios éticos e legais.

Durante o processo, é essencial manter uma comunicação regular e documentar todas as interações. Isso protege ambas as partes e fornece evidências caso haja disputas. Após a correção, o pesquisador deve verificar se o patch resolve efetivamente o problema e, se possível, publicar um advisory descrevendo a vulnerabilidade e a solução.

Exemplo de timeline em formato de tabela:

Data          | Marco
--------------|------------------------------------------
Dia 0        | Envio do relatório ao fornecedor
Dia 2        | Confirmação de recebimento
Dia 5        | Fornecedor reproduz a vulnerabilidade
Dia 10       | Acordo de correção para 30 dias
Dia 40       | Lançamento do patch
Dia 45       | Divulgação coordenada (após correção)
Dia 50       | Verificação da correção e publicação do advisory

Remediation

A remediação é a fase em que a vulnerabilidade é corrigida. Isso pode envolver a implementação de um patch, a alteração de configuração, ou a adoção de medidas mitigatórias temporárias. Para o pesquisador, a remediação não é apenas sugerir uma correção – é acompanhar se ela foi aplicada corretamente e se é eficaz.

Um bom relatório de remediação deve incluir uma descrição técnica da causa raiz, uma ou mais estratégias de correção (por exemplo, validar entradas, atualizar bibliotecas, usar listas de controle de acesso) e, se possível, um patch ou código de exemplo. Além disso, é importante sugerir testes de regressão para garantir que a correção não introduza novos problemas.

Após a correção, o pesquisador deve re-testar a vulnerabilidade para confirmar que foi eliminada. Se a correção for inadequada, é necessário comunicar ao fornecedor e reabrir o caso. Por fim, a documentação do processo – incluindo o advisory final – é crucial para a comunidade, pois permite que outros sistemas sejam verificados contra a mesma falha.

Exemplo de seção de remediação em um relatório:

Causa raiz: Falta de sanitização do parâmetro 'id' na URL.

Correção recomendada:
  - Em PHP: filter_input(INPUT_GET, 'id', FILTER_VALIDATE_INT)
  - Em Java: usar PreparedStatement
  - Em Python: usar parâmetros em consultas SQL

Mitigação temporária:
  - Bloquear requisições com caracteres não numéricos no WAF.

Testes recomendados:
  - Enviar payloads maliciosos (ex.: '1 OR 1=1') e verificar se são rejeitados.
  - Executar testes de regressão nas funcionalidades afetadas.

Boas Práticas e Observações Finais

Além dos pilares acima, algumas boas práticas elevam a qualidade do seu reporte:

  • Seja claro e objetivo: use linguagem simples, evite jargões desnecessários e forneça um resumo executivo.
  • Inclua um PoC (Proof of Concept): quando possível, um código funcional que demonstra a vulnerabilidade acelera a validação.
  • Respeite a legislação: evite acessar dados reais além do necessário para a demonstração; use ambientes de teste.
  • Mantenha a confidencialidade: não divulgue informações sensíveis antes do acordo.
  • Construa um relacionamento: a colaboração entre pesquisadores e fornecedores fortalece a segurança coletiva.

Referências

Exercícios

  1. Explique a diferença entre divulgação total, coordenada e privada, e cite um cenário em que cada uma seria apropriada.

    ✓ Resposta: Divulgação total: publicação imediata de todos os detalhes, sem dar tempo ao fornecedor; apropriada quando o fornecedor é negligente ou a vulnerabilidade é ativamente explorada. Divulgação coordenada: informar o fornecedor em privado e aguardar um prazo razoável antes de publicar; é a mais recomendada para a maioria dos casos. Divulgação privada: apenas o fornecedor fica sabendo, sem publicação; apropriada para vulnerabilidades de baixo risco ou quando há acordo de confidencialidade.

  2. Dado o vetor CVSS: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N, qual é a severidade (pontuação e classificação)?

    ✓ Resposta: O vetor indica impacto alto na confidencialidade (C:H) e nenhum na integridade (I:N) ou disponibilidade (A:N). A pontuação base é 7.5, classificada como Alta.

  3. Descreva um cronograma razoável para uma vulnerabilidade crítica que afeta um servidor web público, desde a notificação até a correção.

    ✓ Resposta: Para uma vulnerabilidade crítica, um cronograma pode ser: Dia 0 – envio do relatório; Dia 2 – confirmação de recebimento; Dia 5 – reprodução confirmada; Dia 10 – acordo de correção em 15 dias; Dia 25 – lançamento do patch; Dia 30 – divulgação coordenada após correção. Prazos menores podem ser necessários se houver exploração ativa.

  4. Cite três estratégias de remediação para uma vulnerabilidade de SQL Injection e explique quando cada uma é preferível.

    ✓ Resposta: 1. Uso de prepared statements (consultas parametrizadas): preferível quando o código é desenvolvido em linguagens como Java, PHP, Python etc., pois separa os dados da consulta. 2. Sanitização e validação de entrada: útil quando prepared statements não são possíveis, mas deve ser aplicada com cautela. 3. Uso de ORM (Object-Relational Mapping): recomendado para novos projetos, pois abstrai a construção de consultas e reduz o risco de erros.

  5. Após enviar um relatório de vulnerabilidade, o fornecedor não responde por 30 dias. Quais ações você pode tomar, considerando princípios éticos?

    ✓ Resposta: Primeiro, tente novos contatos (e-mail, telefone, canais oficiais de segurança). Se persistir a falta de resposta, você pode considerar a divulgação pública após um prazo razoável (geralmente 90 dias), mas deve notificar o fornecedor da sua intenção. Antes de divulgar, avalie o risco para os usuários e, se possível, forneça orientações de mitigação. Em casos extremos, você pode reportar à CERT ou a órgãos reguladores.