- Vulnerabilidades de software exploradas agora iniciam mais violações do que senhas roubadas. O Data Breach Investigations Report 2026 da Verizon estima o número em 31% das violações.
- Você não consegue corrigir o que não sabe que tem. Um inventário preciso de ativos, com um responsável definido para cada sistema, vem antes de qualquer ferramenta de verificação.
- Priorize com base no risco do mundo real, e não apenas na pontuação CVSS. Uma vulnerabilidade do catálogo Known Exploited Vulnerabilities da CISA em um dispositivo voltado para a Internet pesa mais do que um problema de pontuação mais alta em um servidor interno isolado.
- No setor financeiro, a Resolução CMN 4.893, alterada pela Resolução CMN 5.274, exige que as instituições corrijam as vulnerabilidades identificadas em tempo hábil, apliquem correções de segurança regularmente e contratem um teste de penetração independente todos os anos. Os seus fornecedores de tecnologia são cada vez mais solicitados a apresentar as mesmas provas.
- Quando não for possível corrigir, mitigue, registre o risco e defina uma data de expiração. Decidir não aplicar uma atualização é uma decisão de risco para a gestão, e não para um administrador individual.
O que a gestão de vulnerabilidades cobre
A gestão de patches é o processo de obter atualizações do fornecedor em seus sistemas. A gestão de vulnerabilidades é mais ampla. Abrange encontrar pontos fracos em tudo que você executa, decidir quais são os mais importantes, corrigi-los ou mitigá-los dentro de um prazo definido e provar que a correção funcionou. Patches ausentes são um tipo de vulnerabilidade. Configurações incorretas, credenciais padrão, interfaces de gerenciamento expostas e software sem suporte são outros, e uma ferramenta de patch não os encontrará.
Trate-a como um processo operacional contínuo, com responsáveis, metas e relatórios, e não como uma tarefa mensal de TI. A orientação de gestão de vulnerabilidades do NCSC britânico estabelece uma linha de base útil: aplique atualizações o mais rápido possível e, de preferência, automaticamente, mantenha um inventário de seus ativos e de quem os possui, e tenha um processo específico para vulnerabilidades que os invasores já estão explorando.
Por que a janela está diminuindo
Os atacantes exploram vulnerabilidades mais rápido do que muitas organizações conseguem corrigi-las. O Verizon 2026 DBIR descobriu que as organizações corrigiram totalmente apenas 26% das vulnerabilidades do catálogo Known Exploited Vulnerabilities (KEV) da CISA, abaixo dos 38% do ano anterior. O tempo mediano para a correção completa aumentou de 32 para 43 dias. Essas são vulnerabilidades com exploração ativa e confirmada, e a maioria permaneceu aberta por semanas.
Ao mesmo tempo, o Global Threat Report 2026 da CrowdStrike registrou um aumento das vulnerabilidades zero-day exploradas antes da divulgação pública e constatou que 40% das vulnerabilidades exploradas por atores ligados à China tinham como alvo dispositivos de borda voltados para a Internet, como firewalls, VPNs e gateways de acesso remoto. A IA também está acelerando a pesquisa de vulnerabilidades no lado do ataque, como explica nosso artigo sobre IA e resposta a incidentes. Um ciclo mensal de patches que leva seis semanas para chegar ao último dispositivo deixa uma longa lacuna.
Patches mais rápidos resolvem apenas parte disso. Você também precisa saber onde está sua exposição, para que as vulnerabilidades importantes sejam corrigidas primeiro e o restante siga um cronograma previsível.
O ciclo de vida da gestão de vulnerabilidades
A maioria dos programas maduros segue as mesmas seis etapas. Cada uma depende da anterior, e as lacunas nas etapas iniciais prejudicam tudo o que se segue.
Priorizar além do CVSS
O Common Vulnerability Scoring System (CVSS) avalia a gravidade técnica de uma vulnerabilidade. Ele não informa se alguém o está explorando ou se o sistema afetado é importante para o seu negócio. Classificar apenas por CVSS faz com que as equipes busquem pontuações mais altas em sistemas isolados enquanto uma falha explorada ativamente na VPN fica esperando. Combine quatro sinais.
Definir prazos de correção
Os prazos de correção transformam prioridades em compromissos que as pessoas conseguem cumprir. A tabela abaixo é o ponto de partida que usamos com clientes. Ajuste-a ao seu apetite pelo risco e às exigências do seu setor, do seu regulador e dos seus clientes.
| Nível | O que qualifica | Prazo sugerido |
|---|---|---|
| Emergência | No catálogo CISA KEV ou sabidamente explorada de forma ativa, em um sistema voltado para a Internet ou crítico para os negócios | Mitigada em 48 horas (antes, para sistemas expostos sob ataque ativo), totalmente corrigida em 7 dias |
| Crítico/Alto | O fornecedor classifica o problema como crítico ou alto, a pontuação básica do CVSS v3 é 7 ou superior ou o fornecedor não fornece nenhuma gravidade | 14 dias a partir do lançamento |
| Médio | CVSS 4,0 a 6,9 sem exploração conhecida | 30 dias |
| Baixo | CVSS abaixo de 4,0 ou achados que exigem acesso significativo para serem explorados | 90 dias ou o próximo ciclo programado |
Conte o prazo a partir da data em que a atualização foi lançada ou a vulnerabilidade foi publicada, e não a partir da data em que seu scanner a encontrou. Isso impede que a varredura lenta oculte patches lentos. Se ainda não houver correção, use o processo de exceção abaixo até que ela exista. Ative atualizações automáticas sempre que a plataforma oferecer suporte. Isso tira da fila a maioria dos patches de rotina.
Dispositivos de borda e acesso remoto
Firewalls, concentradores VPN, gateways de acesso remoto e outros dispositivos de rede são os sistemas que os invasores mais desejam comprometer e aqueles que as organizações mais frequentemente se esquecem de atualizar. Eles ficam na Internet, geralmente executam firmware que precisa de atualização manual e raramente oferecem suporte a agentes de segurança de endpoint.
Dê a esses dispositivos um processo próprio. Assine os avisos de segurança do fornecedor e verifique-os semanalmente. Certifique-se de que as interfaces de gerenciamento não possam ser acessadas pela Internet. Substitua os dispositivos que atingiram o fim do suporte, porque os fornecedores param de lançar correções para eles. Quando uma vulnerabilidade crítica for anunciada, corrija primeiro e depois verifique se há sinais de que o dispositivo foi comprometido antes da correção. Os invasores que exploraram a falha antecipadamente podem já ter instalado a persistência que sobrevive à atualização. Guias de hardening como os CIS Benchmarks ajudam a reduzir a superfície exposta desde o início.
Quando você não consegue corrigir
Às vezes ainda não há correção, a correção quebra um aplicativo crítico ou o sistema pertence a um fornecedor que controla a atualização. A orientação do NCSC britânico é direta: não aplicar uma atualização é uma decisão de risco da alta gestão, e não algo que um administrador possa decidir sozinho.
Trate isso como uma exceção formal. Aplique controles compensatórios: isole o sistema em seu próprio segmento de rede, restrinja quem e o que pode se conectar a ele, desative o recurso vulnerável ou adicione monitoramento para tentativas de exploração. Registre a exceção em seu registro de risco com um responsável definido, o motivo, os controles em vigor e uma data de expiração. Defina com antecedência quem pode aprovar uma exceção e quando ela deve ser levada a um responsável sênior pelo risco. Teste se os controles compensatórios funcionam e reavalie a exceção quando a ameaça, a exposição ou as correções disponíveis mudarem. O isolamento reduz a exposição, mas mídias removíveis, acesso de fornecedores e usuários locais ainda podem alcançar um sistema isolado. Revise a exceção antes que expire. Uma exceção sem data final torna-se uma lacuna permanente que ninguém se lembra de ter aprovado.
Software sem suporte precisa de um plano próprio. Remova-o ou mova-o para um segmento de rede separado, sem acesso à Internet, até que possa ser substituído. Nosso artigo sobre o fim do suporte do Windows 10 aborda um dos exemplos atuais mais comuns. Sistemas gerenciados por fornecedores também precisam estar previstos nos seus contratos; nosso guia de segurança da cadeia de suprimentos aborda como definir expectativas de correção para os fornecedores.
O que a lei e os frameworks exigem
A legislação brasileira, a regulamentação financeira e os frameworks mais comuns esperam uma gestão de vulnerabilidades, com diferentes níveis de detalhe.
Se os seus sistemas tratam dados pessoais, o artigo 46 da LGPD exige medidas de segurança técnicas e administrativas capazes de proteger esses dados contra acesso não autorizado e contra perda, alteração ou divulgação acidental ou ilegal. O guia da ANPD para agentes de tratamento de pequeno porte não é vinculante, mas recomenda manter sistemas e software atualizados e inclui a gestão de vulnerabilidades entre as medidas de segurança. Um incidente causado por uma vulnerabilidade com patch disponível há meses é difícil de justificar perante a ANPD. Veja como a ANPD fiscaliza a LGPD.
As instituições autorizadas pelo Banco Central deverão abranger a avaliação e correção de vulnerabilidades em sua política de segurança cibernética. Desde as alterações introduzidas pela Resolução CMN 5.274 em dezembro de 2025, seus procedimentos e controles devem incluir testes e análises periódicas, varreduras periódicas para identificar dispositivos conectados indevidamente, testes de penetração, correção oportuna de vulnerabilidades identificadas, gerenciamento do ciclo de vida e aplicação regular de correções de segurança. Um novo Artigo 22-A exige um teste de penetração independente todos os anos, com resultados documentados e planos de ação. As instituições tiveram até 1 de março de 2026 para se adaptarem. A Resolução BCB 538 traz regras equivalentes para instituições de pagamento por meio da Resolução BCB 85.
Nenhuma das regras define um número fixo de dias para aplicação de patches. Se você fornece tecnologia para um banco, veja o que a CMN 5.274 e a BCB 538 exigem dos fornecedores.
O controle 8.8 do Anexo A, Gestão de vulnerabilidades técnicas, exige que você obtenha informações sobre vulnerabilidades técnicas, avalie sua exposição e tome medidas apropriadas. O controle não fixa prazos. Para demonstrar que ele funciona, os auditores normalmente esperam ver um processo definido, prazos de remediação, evidências de que você os atende e um registro de exceções com risco aceito. O controle 5.9 (inventário de informações e outros ativos associados) apoia isso. Nosso guia ISO 27001 abrange o processo de certificação mais amplo.
Se você fabrica produtos com elementos digitais vendidos na UE, o Cyber Resilience Act exige que os fabricantes relatem vulnerabilidades exploradas ativamente desde 11 de setembro de 2026, e as principais obrigações de segurança passam a valer em 11 de dezembro de 2027.
Métricas para reportar à diretoria
A diretoria não precisa de contagens de varredura. Precisa saber se a organização está corrigindo as coisas certas com rapidez suficiente. Seis métricas cobrem quase tudo.
Vulnerabilidades sabidamente exploradas dentro do prazo. A porcentagem de vulnerabilidades listadas no KEV ou exploradas ativamente corrigidas dentro do prazo de emergência. Este é o número mais útil.
Tempo mediano de correção por nível. Quanto tempo as correções realmente levam, em comparação com as metas da sua política.
Correções dentro do prazo. A porcentagem de achados corrigidos dentro do prazo do seu nível, com os itens atrasados detalhados por responsável e tipo de ativo. Uma mediana saudável pode esconder uma longa cauda de achados antigos e graves.
Cobertura da verificação. A porcentagem de ativos do seu inventário que foram verificados nos últimos 30 dias. A baixa cobertura faz com que todas as outras métricas pareçam melhores do que são.
Exceções abertas. O número de vulnerabilidades com risco aceito, a idade delas e quantas já passaram da data de expiração.
Ativos não suportados. O número de sistemas que executam software que não recebe mais atualizações de segurança, com um plano e uma data para cada um.
Erros comuns
Fazer varreduras sem inventário. Um scanner só verifica aquilo para o que foi apontado. Sem um inventário para comparar, não é possível saber quais ativos ficaram de fora, e os que ficam de fora costumam ser os menos mantidos.
Tratar cada pontuação alta de CVSS como urgente. Quando tudo é urgente, nada é. As equipes se esgotam percorrendo milhares de achados em ordem de pontuação, enquanto as poucas que os invasores estão usando aguardam sua vez.
Esquecer firmware e aplicativos de terceiros. As atualizações do sistema operacional geralmente são automatizadas. Plug-ins de navegador, leitores de PDF, ferramentas de desenvolvedor, firmware de dispositivos de rede e aplicações de negócio geralmente não são, e é aí que as lacunas tendem a ocorrer. Ferramentas de gerenciamento de endpoints e políticas do Microsoft 365 e do Intune podem resolver grande parte disso.
Confiar nos relatórios de implantação. Um patch marcado como implantado não é um patch confirmado como instalado. Verifique com uma nova varredura.
Exceções que nunca expiram. Todo risco aceito precisa de um responsável, uma data de revisão e controles compensatórios. Caso contrário, a lista de exceções torna-se silenciosamente a lista de sistemas que um invasor tentaria primeiro.
Ryland lidera programas de cibersegurança, conformidade e gestão de TI para organizações regulamentadas no Brasil, Reino Unido e Países Baixos há mais de 20 anos. Perfil completo