Como este tema funciona na sua empresa
Gestão de vulnerabilidades é o processo contínuo de descobrir, avaliar, priorizar, corrigir e verificar vulnerabilidades em sistemas e aplicações. Diferente de "encontrar e corrigir tudo", VGM aceita que corrigir todas as vulnerabilidades é impossível e foca em priorização baseada em risco: qual vulnerabilidade será explorada primeiro? Qual causa maior impacto? Qual temos capacidade de remediar com recursos disponíveis?
Processo contínuo de descoberta
Ferramenta que escaneia rede, aplicações, código ou cloud em busca de fraquezas conhecidas. Scanners de rede (Nessus, Qualys) descobrem servidores expostos; scanners de aplicação (Acunetix) encontram bugs web; scanners de código (Snyk) identificam dependências inseguras1. Não descobrem tudo (especialmente vulnerabilidades de lógica), mas automatizam descoberta de fracos óbvios.
Descoberta pontual (1-2x/ano) é insuficiente. Vulnerabilidades novas aparecem continuamente. Programa maduro: scan maior a cada trimestre + scan de sistemas críticos mensalmente + verificação contínua em ambientes cloud.
Avaliação e classificação
CVSS (Common Vulnerability Scoring System) é métrica de severidade teórica (0-10, onde 10 é crítico). Vulnerabilidade com CVSS 9 sem exploit público é menos urgente que CVSS 7 amplamente explorado. Priorização efetiva: CVSS + exploração ativa + contexto (aplicação exposta na internet vs. sistema interno)2.
Mesma vulnerabilidade tem prioridade diferente em contextos diferentes. SQL injection em aplicação web pública = crítica. SQL injection em admin backend interno = baixa. Considerar: quem acessa? Qual é exposição?
Priorização e SLAs
Padrão recomendado: Crítico (7 dias para remediar), Alto (30 dias), Médio (90 dias), Baixo (sem prazo obrigatório). Critério deve ser risco, não apenas CVSS. Vulnerabilidade crítica sem patch disponível tem tratamento diferente (mitigação).
Nem toda vulnerabilidade tem patch (zero-day, sistema legado sem suporte). Alternativa: mitigação (firewall WAF, segmentação de rede, desabilitar funcionalidade). Processo deve permitir ambas as opções.
Tratamento e remediação
Aplicar correção do fornecedor. Etapas: validar compatibilidade, testar em staging, aplicar em produção, validar que patch foi aplicado e não quebrou nada.
Se patch não é viável (legacy, zero-day), implementar controles compensadores. Exemplo: SQL injection pode ser mitigado com WAF (firewall de aplicação web) enquanto patch não está disponível.
Verificação e revalidação
Corrigir não é suficiente. Necessário: retest (escanear novamente) para confirmar que vulnerabilidade foi realmente eliminada. Muitos gestores aplicam patch e esquecem de retest. Resultado: "correção" foi ineficaz. Retest deve ser automático ou documentado (parte de SLA de remediação).
Métricas de efetividade
Acompanhar: tempo médio de remediação por severidade, percentual de vulnerabilidades críticas ainda abertas, cobertura de scanning (qual % de infraestrutura é verificada). Dashboard deve mostrar tendências (está melhorando ou piorando?).
Sinais de VGM fraco
- Scanner roda 1-2x/ano ou nunca roda
- Sem SLA claro para remediação
- Vulnerabilidades críticas abertas há meses
- Não há retest após patch
- Sem integração com patch management
- Não há visibilidade (CIO não sabe quantas vulnerabilidades abertas tem)
- Sem documentação de decisões (por que vulnerabilidade X não foi corrigida?)
Implementação de VGM
Fase 1: Descoberta
Escolher scanner apropriado para seu ambiente. Validar em staging. Escanear. Documentar resultado (baseline de vulnerabilidades existentes).
Fase 2-3: Priorização e tratamento
Aplicar SLA por severidade. Corrigir ou mitigar conforme SLA. Retest e fechamento. Integrar com change management. Escalar se SLA não puder ser cumprido.
Perguntas frequentes
Como gerenciar vulnerabilidades de forma efetiva?
Implementar ciclo: descoberta (scanner), avaliação (CVSS + exploração), priorização (risco), remediação (patch ou mitigação), revalidação (retest). Documentar cada passo. Comunicar progresso regularmente.
Qual é o processo de gestão de vulnerabilidades?
1) Descoberta (scanner escaneia); 2) Avaliação (classificar por severidade); 3) Priorização (SLA por risco); 4) Tratamento (patch ou mitigação); 5) Verificação (retest). Ciclo contínuo, não um-off.
Como priorizar vulnerabilidades para correção?
Usar matriz: CVSS + exploração ativa + contexto. Crítico com exploit público = máxima prioridade. Baixo sem exploração = prioridade mínima. SLA deve refletir essa priorização.
Qual é a diferença entre descoberta e avaliação de vulnerabilidades?
Descoberta = scanner encontra vulnerabilidade. Avaliação = análise humana de severidade, impacto e contexto. Scanner diz "CVSS 8", avaliação diz "mas está em sistema interno, então risco é médio".
Como saber se vulnerabilidade foi corrigida?
Retest: escanear novamente após patch. Se scanner não detecta mais, está corrigida. Se ainda detecta, patch foi ineficaz ou não foi aplicado corretamente. Retest deve ser documentado.
Quanto tempo para corrigir uma vulnerabilidade?
Depende de severidade e disponibilidade de patch. SLA recomendado: crítico 7 dias, alto 30 dias, médio 90 dias. Se patch não existe, mitigar. Se sistema é legacy, pode não haver solução rápida.
Referências
- 1 NIST SP 800-40 Rev. 4 — Guide to Enterprise Patch Management Planning
- 2 CVSS v3.1 e EPSS (Exploit Prediction Scoring System) — Métricas de severidade com contexto de exploração
- OWASP Vulnerability Management — Guia prático de gestão de vulnerabilidades
- CIS Vulnerability and Patch Management Benchmark — Framework de boas práticas
- Verizon DBIR (Data Breach Investigations Report) — Estatísticas de incidentes por vulnerabilidade conhecida