Relatório da Rapid7 revela a velocidade com que criminosos exploram vulnerabilidades recém-divulgadas e coloca em discussão a eficácia dos tradicionais SLAs de correção. Para os CISOs, o desafio já não é apenas corrigir falhas, mas negociar riscos, prioridades e investimentos com a velocidade exigida pelo cenário de ameaças.
Durante anos, organizações estruturaram seus programas de gestão de vulnerabilidades em torno de prazos relativamente previsíveis. Vulnerabilidades críticas deveriam ser corrigidas em sete, quinze ou trinta dias, dependendo da classificação de severidade, enquanto falhas de menor impacto poderiam aguardar ciclos regulares de atualização.
Esse modelo, embora tenha contribuído para organizar processos de segurança e estabelecer responsabilidades, começa a enfrentar uma realidade cada vez mais difícil de ignorar: os atacantes não respeitam os calendários corporativos de atualização.
Dados apresentados no relatório de ameaças do terceiro trimestre de 2026 da Rapid7 reforçam essa preocupação. Segundo os resultados divulgados, vulnerabilidades de alta severidade começaram a ser exploradas, em média, apenas três dias após sua divulgação pública. Na amostra analisada, 71% das explorações ocorreram nos primeiros sete dias.
A diferença entre o tempo disponível para exploração e o prazo tradicional de correção revela um problema importante de governança.
Uma organização que estabelece trinta dias para corrigir determinada vulnerabilidade pode estar formalmente em conformidade com sua política interna e, simultaneamente, permanecer exposta durante a fase mais crítica da atividade dos atacantes.
A pergunta que emerge para a liderança de segurança é inevitável: de que adianta cumprir o SLA quando a exploração acontece antes do prazo terminar?
A velocidade dos ataques está mudando a gestão de vulnerabilidades
O crescimento da automação ofensiva, a disponibilidade de ferramentas de exploração e a rápida disseminação de informações técnicas reduziram o intervalo entre a divulgação de vulnerabilidades e sua utilização em ataques reais.
Esse fenômeno é particularmente preocupante em sistemas diretamente acessíveis pela internet, como gateways de acesso remoto, VPNs, plataformas de gerenciamento, aplicações web e componentes de infraestrutura.
Quando uma vulnerabilidade permite execução remota de código ou acesso não autenticado, a exposição pode se tornar crítica antes mesmo que uma organização conclua seus procedimentos tradicionais de avaliação e aprovação de mudanças.
É importante distinguir três conceitos:
- Tempo até a exploração: intervalo entre a divulgação pública de uma vulnerabilidade e sua utilização observada em ataques.
- Tempo até a detecção: período necessário para que a organização identifique que possui ativos vulneráveis.
- Tempo até a mitigação: intervalo necessário para eliminar ou reduzir efetivamente a exposição.
Esses indicadores não são equivalentes.
Uma organização pode identificar uma vulnerabilidade em poucas horas e ainda levar semanas para corrigi-la. Da mesma forma, a instalação de uma atualização não significa necessariamente que todas as instâncias vulneráveis foram efetivamente protegidas.
O verdadeiro indicador de maturidade passa a ser o tempo durante o qual a organização permanece exposta a uma ameaça explorável.
O problema dos SLAs fixos de 30 dias
O modelo tradicional de gestão de vulnerabilidades costuma utilizar a classificação CVSS como principal referência para estabelecer prazos.
Embora o CVSS continue relevante para avaliar características técnicas de severidade, ele não representa isoladamente a probabilidade de exploração nem o impacto específico sobre determinada organização.
Duas vulnerabilidades com a mesma pontuação podem apresentar níveis de risco operacional completamente diferentes.
Imagine dois cenários:
Cenário A: uma vulnerabilidade crítica em um servidor interno, isolado da internet, protegido por controles adicionais e sem evidências conhecidas de exploração ativa.
Cenário B: uma vulnerabilidade de alta severidade em um gateway de autenticação exposto à internet, com código de exploração disponível e campanhas de ataque já identificadas.
Uma política baseada exclusivamente na severidade técnica poderia atribuir prazos semelhantes ou até priorizar o primeiro cenário.
Entretanto, a exposição e a atividade dos atacantes podem justificar uma resposta muito mais urgente no segundo.
Isso não significa abandonar os SLAs. Significa reconhecer que o prazo de correção deve ser consequência da avaliação de risco, e não o único instrumento utilizado para defini-la.
O novo SLA: da severidade técnica à exposição real
Para os CISOs, a evolução necessária é estabelecer um modelo de priorização que considere diferentes dimensões de risco.
Entre elas estão a exploração ativa, a disponibilidade de exploits, a exposição à internet, a criticidade do ativo, os privilégios associados, a sensibilidade dos dados e a existência de controles compensatórios.
Fontes como o catálogo Known Exploited Vulnerabilities (KEV), da CISA, e o Exploit Prediction Scoring System (EPSS) podem complementar o CVSS e fornecer sinais adicionais para priorização.
Um modelo operacional poderia estabelecer, por exemplo:
| Situação de risco | Meta inicial sugerida |
|---|---|
| Exploração ativa confirmada em ativo crítico exposto | Mitigação emergencial, idealmente em até 24 horas |
| Exploit público e exposição externa relevante | Mitigação em até 72 horas |
| Vulnerabilidade crítica sem exploração conhecida, em ativo relevante | Correção em até 7 dias |
| Vulnerabilidade de alta severidade com exposição controlada | Correção em até 15 dias |
| Risco moderado, com controles compensatórios eficazes | Ciclo de até 30 dias, sujeito a reavaliação |
Esses prazos são exemplos de desenho de política, não recomendações universais nem exigências estabelecidas pela Rapid7 ou pela NIS2.
A definição final depende da realidade operacional, do apetite a risco e das obrigações aplicáveis a cada organização.
O ponto fundamental é que uma vulnerabilidade sob exploração ativa não deve necessariamente aguardar o mesmo processo de aprovação reservado a uma atualização de rotina.
O CISO precisa negociar velocidade com o negócio
A discussão sobre vulnerabilidades frequentemente se concentra nas equipes de segurança e infraestrutura.
Entretanto, quando uma correção exige indisponibilidade de sistemas, mudanças em aplicações críticas ou interrupção de operações, a decisão ultrapassa o domínio técnico.
Ela passa a envolver continuidade de negócios, impacto financeiro, disponibilidade de serviços e responsabilidade executiva.
É nesse momento que o CISO precisa traduzir vulnerabilidades em linguagem de risco empresarial.
Em vez de apresentar apenas um relatório contendo centenas de falhas críticas, a liderança de segurança deve demonstrar quais processos de negócio estão expostos, quais ameaças possuem exploração conhecida e quais consequências podem surgir caso a correção seja adiada.
A conversa deixa de ser:
“Precisamos instalar uma atualização de segurança.”
E passa a ser:
“Temos um serviço crítico exposto a uma vulnerabilidade explorada ativamente. Precisamos decidir entre uma janela emergencial de manutenção ou a aceitação formal de um risco operacional elevado.”
Essa mudança exige participação efetiva dos responsáveis pelos sistemas e dos executivos que assumem os riscos associados às decisões de negócio.
Aceitar um risco não significa transferir a responsabilidade para a equipe de segurança. Significa reconhecer, documentar e aprovar conscientemente uma exposição residual.
NIS2: gestão de vulnerabilidades também é responsabilidade de governança
Na União Europeia, a Diretiva NIS2 reforça a necessidade de tratar a cibersegurança como uma responsabilidade organizacional e de gestão.
O artigo 21 estabelece requisitos relacionados às medidas de gestão de riscos de cibersegurança, incluindo políticas e procedimentos para avaliar a eficácia dos controles e práticas de segurança na aquisição, desenvolvimento e manutenção de sistemas, abrangendo o tratamento e a divulgação de vulnerabilidades.
O artigo 20 também estabelece responsabilidades para os órgãos de administração das entidades abrangidas, incluindo aprovação e supervisão das medidas de gestão de riscos.
Isso não significa que a NIS2 imponha um prazo universal de 24, 72 horas ou 30 dias para corrigir vulnerabilidades.
A diretiva exige uma abordagem proporcional e apropriada aos riscos, complementada pelas regras nacionais de transposição e, quando aplicável, por requisitos setoriais ou regulamentares específicos.
Na prática, organizações sujeitas à NIS2 precisam ser capazes de demonstrar que seus processos de identificação, priorização, tratamento e acompanhamento de vulnerabilidades são adequados à sua exposição.
A simples existência de uma política formal não comprova, por si só, a eficácia dos controles.
Uma vulnerabilidade explorada ativamente, mantida durante semanas sem mitigação, pode suscitar questionamentos relevantes sobre a efetividade do processo de gestão de riscos, ainda que seu prazo interno não tenha expirado.
Evidências: o que o conselho e os auditores deveriam exigir?
A maturidade de um programa de gestão de vulnerabilidades não pode ser avaliada apenas pela quantidade de atualizações instaladas ou pelo percentual de cumprimento de SLAs.
É necessário demonstrar a redução efetiva da exposição.
Algumas métricas particularmente relevantes para relatórios executivos incluem:
1. Mean Time to Remediate (MTTR)
Tempo médio necessário para corrigir vulnerabilidades, segmentado por criticidade, exposição e exploração ativa.
2. Tempo de exposição a vulnerabilidades exploradas
Intervalo durante o qual ativos permanecem vulneráveis após a identificação de exploração conhecida.
3. Percentual de ativos críticos com vulnerabilidades KEV
Proporção de ativos críticos afetados por vulnerabilidades presentes no catálogo de exploração conhecida da CISA.
4. Vulnerabilidades fora do prazo com risco aceito
Quantidade de exceções, seus responsáveis, justificativas, controles compensatórios e datas de revisão.
5. Cobertura e confiabilidade do inventário
Percentual de ativos efetivamente identificados, monitorados e associados a responsáveis de negócio.
6. Tempo até a mitigação emergencial
Velocidade de aplicação de medidas de contenção, como bloqueios de acesso, desativação de funcionalidades, segmentação ou regras de proteção, quando a atualização definitiva não está imediatamente disponível.
Essas métricas permitem transformar o acompanhamento técnico em informação executiva.
Também criam evidências úteis para auditorias, avaliações regulatórias e demonstração de diligência na gestão de riscos.
IAM e Zero Trust: controles compensatórios podem reduzir a exposição
A discussão sobre vulnerabilidades possui uma relação direta com Identity and Access Management (IAM) e arquiteturas Zero Trust.
Embora uma plataforma de IAM não substitua a necessidade de corrigir vulnerabilidades, controles de identidade e acesso podem contribuir significativamente para reduzir a superfície de ataque e limitar movimentos posteriores a uma exploração.
Entre as medidas relevantes estão:
- Restringir acessos administrativos utilizando Privileged Access Management (PAM).
- Aplicar princípios de menor privilégio a contas humanas e não humanas.
- Reduzir a exposição de interfaces administrativas por meio de controles de acesso contextual.
- Segmentar sistemas e serviços críticos.
- Monitorar comportamentos anômalos de identidades e contas privilegiadas.
- Revisar acessos de terceiros e integrações com sistemas vulneráveis.
- Aplicar controles de autenticação resistentes a phishing onde apropriado.
Entretanto, existe uma distinção fundamental: MFA não impede necessariamente a exploração de vulnerabilidades que dispensam autenticação.
Da mesma forma, controles de identidade não eliminam falhas de execução remota de código em serviços expostos.
Por isso, o papel do IAM deve ser compreendido dentro de uma estratégia de defesa em profundidade, integrada à gestão de vulnerabilidades, ao gerenciamento de exposição e à resposta a incidentes.
Em ambientes Zero Trust, o objetivo é limitar a confiança implícita e reduzir o impacto potencial de uma falha, mesmo quando a prevenção inicial não é suficiente.
O orçamento de segurança também precisa acompanhar a nova realidade
Reduzir o tempo de correção exige mais do que estabelecer SLAs agressivos.
Uma organização pode determinar que vulnerabilidades exploradas sejam corrigidas em 24 horas, mas essa meta terá pouco valor se não existirem equipes disponíveis, automação, ambientes de testes ou mecanismos de aprovação emergencial.
O desafio para o CISO é demonstrar que velocidade de resposta depende de capacidade operacional.
Isso pode envolver investimentos em descoberta contínua de ativos, gerenciamento automatizado de atualizações, ferramentas de exposição, integração entre segurança e operações, testes automatizados e procedimentos de resposta emergencial.
Também pode exigir mudanças organizacionais.
Equipes de infraestrutura e desenvolvimento precisam participar da definição dos SLAs, enquanto responsáveis pelos processos de negócio devem compreender as consequências de adiar correções críticas.
A gestão de vulnerabilidades deixa, assim, de ser uma atividade exclusivamente operacional e passa a integrar o planejamento de resiliência da organização.
Cinco decisões que deveriam entrar na agenda do próximo comitê de riscos
A aceleração da exploração de vulnerabilidades sugere que os CISOs revisem cinco aspectos de seus programas:
- Reavaliar os SLAs atuais: identificar situações nas quais prazos de 15 ou 30 dias não são compatíveis com a exposição real.
- Criar um processo emergencial: estabelecer fluxos específicos para vulnerabilidades exploradas ativamente, incluindo responsáveis e autoridades de aprovação.
- Integrar inteligência de ameaças: utilizar evidências de exploração, EPSS, KEV e informações sobre os ativos para priorizar correções.
- Formalizar a aceitação de riscos: assegurar que exceções tenham justificativas, responsáveis, controles compensatórios e validade definida.
- Modernizar os indicadores executivos: substituir relatórios centrados apenas em volume de vulnerabilidades por métricas de exposição, tempo de resposta e redução de riscos.
Essas decisões precisam ser acompanhadas por testes periódicos dos processos, para verificar se a organização consegue efetivamente responder dentro dos prazos estabelecidos.
Conclusão: cumprir o prazo não é o mesmo que controlar o risco
Os dados divulgados pela Rapid7 representam um alerta importante para os modelos tradicionais de gestão de vulnerabilidades.
Se a exploração pode ocorrer poucos dias após a divulgação pública, políticas baseadas exclusivamente em prazos fixos tornam-se insuficientes para determinados cenários.
Isso não significa que toda vulnerabilidade deva ser corrigida imediatamente, nem que o prazo de trinta dias tenha perdido completamente sua utilidade.
Significa que o SLA precisa refletir o risco real, a criticidade dos ativos e a atividade dos atacantes.
Para os CISOs, a transformação mais importante não é apenas tecnológica. É de governança.
A liderança de segurança precisa estabelecer mecanismos para que decisões sobre exposição, continuidade operacional, investimento e aceitação de riscos sejam tomadas com informações atualizadas e responsabilidades claramente definidas.
Em um ambiente no qual vulnerabilidades podem ser exploradas em três dias, um SLA de trinta dias pode continuar sendo um indicador administrativo válido, mas não pode ser confundido com garantia de proteção.
A pergunta que deve orientar o próximo comitê executivo não é simplesmente quantas vulnerabilidades foram corrigidas dentro do prazo.
É quanto tempo a organização permaneceu exposta a riscos que os atacantes já estavam preparados para explorar.
