Quero implementar gestão de vulnerabilidades
Resposta rápida
Gestão de vulnerabilidades não é "rodar scanner uma vez" — é programa contínuo de identificação, priorização e remediação. Comece pelo inventário de ativos (não há como proteger o que não enxerga), escolha ferramenta proporcional ao porte (de scan básico em SaaS a plataforma corporativa), defina cadência regular de scan (semanal para crítico, mensal para o resto), priorize por exploitabilidade real — não por nota CVSS bruta —, e estabeleça ciclo de remediação com SLA por severidade. O sucesso depende menos da ferramenta e mais da capacidade de fechar vulnerabilidade: empresa que descobre milhares e fecha dezenas tem programa pior do que aquela que descobre centenas e fecha centenas. Métrica que importa é tempo médio até remediação, não volume identificado.
Na empresa pequena, gestão de vulnerabilidades cabe em uso de ferramentas embutidas (gestão de atualização do Windows, atualização de SaaS, scanner básico de servidores se houver) e ciclo trimestral conduzido pelo MSP. Não compre plataforma corporativa (Tenable, Qualys, Rapid7) — custo e complexidade são desproporcionais. Foco em higiene: patches do sistema operacional e dos navegadores em dia, atualização de aplicações de mercado, configuração segura básica. Política simples: vulnerabilidade crítica é fechada em até 30 dias; o resto entra na manutenção regular. O risco maior é tratar atualização como sempre adiável — postergar patch por meses é o caminho mais comum para incidente.
Na empresa média, programa de vulnerabilidades vira disciplina formal. Adote plataforma adequada (Tenable, Qualys, Rapid7, ou alternativas mais leves como Nessus standalone) cobrindo servidores, endpoints, aplicações expostas e cloud. Estabeleça cadência (semanal para crítico, mensal para o resto), priorização por exploitabilidade (CVSS combinado com EPSS e contexto de exposição), SLA por severidade (crítico 7-14 dias, alto 30 dias, médio 90 dias). Responsável claro por remediação, fluxo integrado com ticket. Comitê de vulnerabilidade mensal para acompanhar indicadores. O risco maior é gerar relatório que ninguém remedia: scanner roda, ticket abre, área responsável não trata, vulnerabilidade envelhece.
Na empresa grande, programa de vulnerabilidades é maduro com equipe dedicada de gestão de vulnerabilidades dentro de segurança. Plataforma corporativa com cobertura ampla — infraestrutura, endpoints, aplicações web, contêineres, cloud, código (SAST/DAST/SCA) —, integração com ticketing e CMDB, priorização baseada em risco com CVSS, EPSS, threat intel e contexto de criticidade. SLAs formais por severidade e por classe de ativo, acompanhamento por comitê regular, integração com gestão de mudança. O risco maior é silos: time de aplicação não fala com time de infraestrutura, dono de ativo não conhecido para parte do parque, e vulnerabilidade fica órfã. Governança e dados confiáveis de propriedade são pré-condição.
- Atualizações de sistema são adiadas até virarem urgência
- Nunca houve scan estruturado de vulnerabilidades em todo o parque
- Auditoria, cliente ou seguro começou a pedir relatório de vulnerabilidade
- Incidente recente partiu de vulnerabilidade conhecida e não corrigida
- Time de TI não tem cadência regular de patch nem registro do que foi feito
- Há scanner rodando, mas ninguém remedia o que ele encontra
Gestão contínua, não evento pontual
Vulnerabilidade é descoberta o tempo todo: novos CVEs aparecem semanalmente, novas configurações inseguras emergem, novo software entra no parque. Gestão de vulnerabilidades como evento (scan anual com consultoria) cobre uma foto momentânea e ignora a maior parte do risco. O programa precisa ser contínuo: scan regular, priorização contínua, remediação em ciclos, métricas acompanhadas. Sem essa cadência, o relatório do scan vira documento de prateleira — útil para auditoria pontual, irrelevante para reduzir risco.
Priorização por exploitabilidade, não por nota bruta
Nota CVSS sozinha é guia ruim. Vulnerabilidade com CVSS 9,8 que não é explorada ativamente e não tem exposição no ambiente é menos urgente que vulnerabilidade com CVSS 7,5 que está sendo explorada em massa em um ativo exposto à internet. Priorização madura combina três camadas. CVSS como ponto de partida (severidade técnica). EPSS (Exploit Prediction Scoring System) que estima probabilidade de exploração nos próximos dias. Contexto de exposição: o ativo está exposto à internet? Tem dado sensível? É crítico para negócio? A combinação dessas três produz lista priorizada que faz diferença real — não lista de mil itens críticos que ninguém remedia.
SLAs realistas por severidade
Programa maduro define SLA por severidade. Padrão de mercado razoável: vulnerabilidade crítica em ativo exposto, 7 a 14 dias. Alta, 30 dias. Média, 90 dias. Baixa, manutenção regular. SLAs muito agressivos viram fracasso silencioso — time não cumpre, métrica vermelha vira normal, ninguém se importa. SLA realista, cumprido na maior parte dos casos, com escalonamento para exceções, é o que constrói disciplina.
- Inventário de ativos com donos. Endpoints, servidores, aplicações, cloud, com responsável por remediação identificado para cada categoria. Sem dono, vulnerabilidade fica órfã.
- Seleção da ferramenta. Proporcional ao porte: básico em SaaS para empresa pequena, plataforma intermediária para média, corporativa para grande.
- Cadência de scan. Semanal para crítico (ativos expostos, sistemas-chave), mensal para o resto. Pontual em mudança relevante.
- Priorização e SLA. CVSS combinado com EPSS e contexto de exposição. SLAs realistas por severidade.
- Ciclo de remediação e métricas. Ticket integrado com fluxo de mudança, comitê mensal de acompanhamento, métricas de tempo médio até remediação, percentual de SLA cumprido, idade média do backlog.
Quando não dá para patchar
Nem toda vulnerabilidade pode ser remediada por patch. Sistema legado sem atualização do fornecedor, aplicação crítica que quebra com patch, janela de manutenção inexistente — situações reais. Programa maduro tem processo formal de exceção. Quem aprova exceção, qual a justificativa, qual o controle compensatório (segregação de rede, monitoramento extra, hardening adicional), qual o prazo de revisão. Exceção sem prazo de revisão vira buraco permanente; exceção com governança vira risco aceito conscientemente, que é diferente.
Ferramenta sem inventário. Scanner roda no que conhece. Sem inventário de ativos, parte do parque fica fora — e ataque mira justamente o ativo esquecido.
Volume como métrica de sucesso. "Encontramos 5 mil vulnerabilidades" não é vitória. Tempo médio de remediação e idade do backlog medem o programa de verdade.
SLAs irreais. Promessa de 24 horas para crítico em parque inteiro vira fracasso normalizado. SLA factível, cumprido, com escalonamento para exceção, constrói disciplina.
Ticket sem dono. Vulnerabilidade encontrada, ticket aberto, ninguém atribuído. Em semanas, idade média do backlog explode e o programa perde força.
Exceção permanente sem governança. "Não dá para patchar" vira desculpa universal. Processo formal de exceção com prazo de revisão diferencia risco aceito de risco esquecido.
- Inventário de ativos com donos por categoria
- Ferramenta de scan adequada ao porte, com cobertura definida
- Cadência de scan estabelecida (semanal/mensal/pontual)
- Priorização combina CVSS, EPSS e contexto de exposição
- SLAs realistas por severidade, pactuados com áreas responsáveis
- Fluxo de ticket integrado com gestão de mudança
- Comitê regular de acompanhamento com indicadores claros
- Processo formal de exceção, com aprovador e prazo de revisão