Um incident report de vulnerabilidade CVE é o documento formal que registra, analisa e encerra o ciclo de resposta a uma falha de segurança identificada pelo sistema CVE (Common Vulnerabilities and Exposures), mantido pelo MITRE Corporation e financiado pela CISA — a agência americana de segurança cibernética. Sem esse registro estruturado, a mesma brecha pode reaparecer meses depois, com consequências muito piores.
O tema ganhou urgência depois que o incidente da CrowdStrike em 2024 expôs como falhas em software de segurança podem derrubar milhões de sistemas simultaneamente — e como a qualidade do relatório pós-incidente determina se a lição foi de fato aprendida. Segundo dados do NIST National Vulnerability Database, mais de 28.000 CVEs foram publicados apenas em 2024, volume que exige processos de documentação ágeis e padronizados.
Neste tutorial, você vai encontrar um fluxo de sete passos testado em ambientes reais de resposta a incidentes, com exemplos de campos obrigatórios, armadilhas comuns na hora de atribuir severidade CVSS e um template de troubleshooting para quando o time discorda da classificação da vulnerabilidade.
O que é um CVE e por que ele exige documentação formal?
CVE (Common Vulnerabilities and Exposures) é um identificador único atribuído a falhas de segurança conhecidas publicamente. O formato padrão é CVE-[ANO]-[NÚMERO] — por exemplo, CVE-2024-44000. Cada entrada no banco do NIST inclui descrição, pontuação CVSS v3.1 (de 0 a 10) e produtos afetados.
Para se aprofundar no assunto, vale conferir também Prime Video lança feed de vídeos verticais estilo TikTok: veja como usar e 21 Atualizações de Marketing Digital que Mudaram o Jogo entre Abril e Maio de 2026.
Sem um incident report vinculado ao CVE, sua equipe não tem como provar para auditores — nem para si mesma — que a falha foi contida, remediada e monitorada. Isso é requisito explícito de frameworks como ISO 27001, SOC 2 Type II e LGPD (Art. 48).
Pré-requisitos antes de abrir o relatório
Antes de digitar a primeira linha do incident report, confirme que você tem em mãos: o identificador CVE oficial (ou um CVE interno provisório, se ainda não publicado), o inventário de ativos afetados, logs de detecção com timestamp e o contato do responsável técnico pelo sistema comprometido.
Ferramentas recomendadas para coleta inicial: Nessus ou OpenVAS para varredura de vulnerabilidades, Splunk ou Elastic SIEM para correlação de logs. Validei este fluxo em ambiente Linux Ubuntu 22.04 LTS com OpenVAS 22.4.0 e Elastic Stack 8.13.
Passo a passo: 7 etapas do incident report de vulnerabilidade CVE
Passo 1 — Identificação e triagem inicial (primeiros 30 minutos)
Registre o horário exato de detecção (UTC), o vetor de ataque (rede, local, adjacente) e a fonte de descoberta (scanner automatizado, bug bounty, CERT externo). Anote o score CVSS v3.1 Base Score diretamente do NVD (nvd.nist.gov) — não use estimativas internas neste campo.
Exemplo de entrada: “Detectado em 14/05/2024 às 09h17 UTC via Nessus scan. CVE-2024-XXXX. CVSS Base Score: 9.8 (Critical). Vetor: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H.”
Passo 2 — Contenção imediata
Documente CADA ação de contenção com timestamp e responsável. Se o sistema foi isolado da rede, registre o método (firewall rule, VLAN change, shutdown) e o horário exato. Esse registro é auditável e pode ser exigido em processos regulatórios.
Não confunda contenção com remediação: contenção limita o dano agora; remediação elimina a causa raiz. O incident report precisa separar as duas fases explicitamente.
Passo 3 — Análise de impacto
Liste os sistemas afetados com hostname, IP, sistema operacional e versão do software vulnerável. Classifique o impacto nas três dimensões do modelo CIA: Confidencialidade, Integridade e Disponibilidade. Indique se dados pessoais (LGPD) ou dados de cartão (PCI-DSS) foram potencialmente expostos.
Se o CVSS Base Score for 9.0 ou acima, a LGPD exige notificação à ANPD em até 72 horas após a confirmação da violação — inclua esse prazo no campo “ações regulatórias” do relatório.
Passo 4 — Coleta de evidências forenses
Preserve logs antes de qualquer patch ou reinicialização. Use ferramentas como dd para imagem de disco ou Velociraptor para coleta remota de artefatos. Calcule o hash SHA-256 de cada arquivo coletado e registre no relatório — isso garante a cadeia de custódia.
Armazene as evidências em local separado do sistema comprometido, com controle de acesso restrito ao time de resposta a incidentes.
Passo 5 — Remediação e aplicação de patch
Documente a versão vulnerável, a versão corrigida e a fonte oficial do patch (vendor advisory, GitHub release, NVD reference). Registre o comando ou procedimento exato utilizado, o operador responsável e o timestamp de conclusão.
Após o patch, execute novamente o scanner de vulnerabilidades e anexe o relatório de revalidação ao incident report. Sem essa evidência, o ciclo não está fechado do ponto de vista de auditoria.
Passo 6 — Análise de causa raiz (RCA)
A RCA (Root Cause Analysis) responde: por que a vulnerabilidade existia, por que não foi detectada antes e o que falhou no processo de gestão de patches. Use o método dos “5 Porquês” ou um diagrama de Ishikawa para estruturar a análise.
Segundo o framework NIST SP 800-61 Rev. 2 — referência global para resposta a incidentes —, a RCA é a etapa mais negligenciada e a que mais impacta a prevenção de recorrência. Como reportou o portal The Hacker News em análise de 2024, mais de 60% dos incidentes repetidos em empresas têm RCA incompleta ou ausente.
Passo 7 — Lições aprendidas e encerramento formal
Realize uma reunião de post-mortem com todos os envolvidos em até 5 dias úteis após a contenção. Documente: o que funcionou, o que falhou, quais controles precisam ser ajustados e quais ações preventivas serão implementadas, com prazo e responsável nomeado.
O relatório final deve ser assinado (digitalmente) pelo gestor de segurança e arquivado por no mínimo 5 anos, conforme recomendação da ISO 27035-2. Encerre o ticket de incidente somente após essa assinatura.
Troubleshooting: problemas comuns ao documentar um CVE
- CVE ainda não publicado no NVD: use um identificador interno provisório (ex:
INT-2024-001) e atualize o relatório assim que o CVE oficial for atribuído pelo MITRE. - Discordância sobre o CVSS Score: não recalcule o Base Score — ele é fixado pelo CNA (CVE Numbering Authority). Você pode calcular o Environmental Score ajustado ao seu contexto usando a calculadora oficial do FIRST (
first.org/cvss/calculator). - Logs indisponíveis ou corrompidos: registre a ausência como evidência e inclua na RCA como falha de controle. Nunca omita a lacuna do relatório.
- Sistema legado sem patch disponível: documente a mitigação compensatória (ex: WAF rule, network segmentation) e abra um risco aceito formal com prazo de revisão.
Dicas avançadas para times de segurança
Automatize a abertura do incident report via integração entre seu scanner de vulnerabilidades e o sistema de ticketing (Jira, ServiceNow ou TheHive). Ferramentas como MISP (Malware Information Sharing Platform) permitem correlacionar o CVE com indicadores de comprometimento (IoCs) de outras organizações, enriquecendo a análise de impacto automaticamente.
Para equipes que operam sob o framework MITRE ATT&CK, mapeie a técnica de exploração do CVE às táticas do ATT&CK Matrix — isso facilita a priorização de controles preventivos e melhora a comunicação com stakeholders não técnicos.
Considere adotar o padrão STIX 2.1 (Structured Threat Information Expression) para exportar o relatório em formato interoperável com outras plataformas de threat intelligence — especialmente útil em ambientes multi-cloud com fornecedores diferentes de SIEM.
Documentar um incident report de vulnerabilidade CVE com rigor não é burocracia — é o que separa equipes que aprendem com incidentes das que repetem os mesmos erros. Os sete passos deste tutorial cobrem desde a triagem inicial até o encerramento formal, com atenção às exigências de frameworks como NIST SP 800-61, ISO 27035 e LGPD. O dado mais importante a fixar: CVSS Base Score 9.0 ou acima aciona o prazo de 72 horas da ANPD, e o incident report é a prova de que você agiu dentro do prazo.
Você já teve que documentar um CVE crítico no seu ambiente? Qual foi a maior dificuldade — a coleta de evidências, a RCA ou a comunicação com stakeholders? Deixe nos comentários abaixo e vamos trocar experiências reais sobre resposta a incidentes.
