White PaperInstalar um patch não é o mesmo que fechar a vulnerabilidade
Remediação autônoma e validada com re-scan em 6 fases
Em 2026, um exploit surge em 1,8 dias, o patch leva 20 dias. O Patch Management fecha o loop: prioriza por risco real, faz staging, implanta via WMI e SSH e executa re-scan para confirmar o fechamento de cada CVE, com Tempo Médio de Correção auditável.
O problema: em 2025, 28,3% das CVEs exploradas foram weaponizadas em menos de 24 horas após a divulgação pública. As organizações levam em média 20 dias para aplicar o patch. A janela entre exploração disponível e correção aplicada é onde o risco real se materializa. E mesmo quando o patch é instalado, a vulnerabilidade pode persistir, porque o serviço não reiniciou, ou porque a exploração aconteceu por outro vetor.
A abordagem: o EcoTrust Patch Management fecha o loop completo: prioriza por risco real (CVSS + EPSS + CISA KEV + criticidade), testa em grupo piloto, faz deploy via protocolos nativos (WMI/WinRM para Windows, SSH para Linux) e executa um re-scan completo para confirmar que a CVE foi efetivamente fechada, não apenas que o patch foi instalado.
O resultado: Tempo Médio de Correção auditável, calculado do momento de detecção pelo VulScan até a confirmação pelo re-scan. Loop fechado com o CRQ, quando uma CVE é confirmada fechada, o ALE do cenário de risco é atualizado automaticamente no mesmo dia. Zero agente instalado nos endpoints. Zero footprint permanente.
Horas vs. 20 dias, a janela que define o risco.
O ciclo de vida de uma vulnerabilidade explorada tem duas datas críticas: quando o exploit fica disponível e quando o patch é aplicado. A diferença entre essas duas datas é a janela de exposição ativa.
Em 2025, a maioria das vulnerabilidades exploradas foi weaponizada antes mesmo de sua divulgação pública, e 28,3% das CVEs exploradas tiveram exploit funcional em menos de 24 horas após o disclosure. O tempo médio que organizações levam para testar e aplicar o patch é de 20 dias. A janela de exposição entre exploit disponível e correção aplicada é onde o risco real se materializa.
O dado mais preocupante não é o Tempo Médio de Correção médio, é que 46% dos dispositivos vulneráveis identificados no Verizon DBIR 2025 simplesmente não foram remediados dentro do período observado. Não porque a organização não soube que havia vulnerabilidade. Porque o processo de remediação não fechou o ciclo.
O ciclo que não se fecha: o scanner detecta. O ticket é aberto. O patch é agendado para a próxima janela de manutenção. O patch é instalado. O ticket é fechado. A CVE ainda aparece no próximo scan, porque o serviço não reiniciou, ou porque o patch foi instalado em uma versão diferente do que a vulnerável. O ciclo recomeça.
Por que patch instalado não é CVE fechada.
A distinção entre "patch instalado" e "vulnerabilidade remediada" é a diferença entre um processo que parece estar funcionando e um processo que está efetivamente reduzindo risco.
Patch instalado significa que um arquivo foi atualizado em disco. Vulnerabilidade remediada significa que a CVE específica que motivou o patch não existe mais naquele ativo, confirmado por um novo scan após o deploy. As duas coisas podem não ser a mesma coisa.
Muitos patches exigem reinicialização do serviço, ou do sistema inteiro, para que a versão corrigida entre em execução. Um patch instalado em disco em um processo que ainda está rodando a versão antiga em memória não remedia a vulnerabilidade. Sem re-scan, essa situação é invisível.
Em ambientes com múltiplas versões de um software, especialmente em sistemas Linux com pacotes customizados, o patch pode ter sido aplicado em uma instância diferente da que estava vulnerável. Sem verificação pós-deploy, a versão vulnerável persiste.
Uma CVE pode ser explorada por mais de um caminho. Fechar um vetor específico sem verificar se outros existem no mesmo ativo pode deixar a exposição ativa por uma rota diferente, invisível sem re-scan completo após a remediação.
Por que isso importa para auditoria: frameworks como ISO 27001 e PCI DSS exigem evidências de remediação, não apenas de instalação de patch. Um log de deploy não é evidência de que a vulnerabilidade foi fechada. Um re-scan que confirma a ausência da CVE após o deploy é. A distinção é direta e tem consequência em auditoria.
As 6 fases autônomas, da priorização à confirmação.
O Patch Management opera em 6 fases sequenciais executadas de forma autônoma pelo agente. O agente processa três filas de deploy em paralelo, sem conflito entre elas.
Risk Score por CVE: CVSS + EPSS + CISA KEV + criticidade do ativo. CVEs no CISA KEV elevadas automaticamente para fila Zero-Day independentemente do score.
Deploy em grupo controlado com os mesmos perfis de SO e software da produção. Critérios automáticos: ≥95% de sucesso, zero crashes, serviços críticos respondendo, conectividade ativa.
Deploy via protocolos nativos de gerenciamento remoto, sem instalar agente nos endpoints. Nenhum binário permanente após a sessão. Rollback automático se serviço crítico ficar indisponível.
Novo ciclo completo nos ativos remediados: re-Discovery, re-Inventory, re-VulScan. Se a CVE não aparece mais, marcada como Remediada com timestamp. Se persistir, alerta enviado com contexto.
Cálculo automático: tempo entre a primeira detecção pelo VulScan e a confirmação pelo re-scan. Cyber Risk Score atualizado. Loop fechado com o módulo CRQ, ALE recalculado no mesmo dia.
Log de deploy mais re-scan confirmado por CVE. Relatórios prontos para ISO 27001, NIST CSF 2.0, PCI DSS 4.0 e BACEN 4.557, sem coleta manual de evidências.
3 filas paralelas, urgência que não interfere na rotina.
Uma das principais dificuldades na gestão de patches é equilibrar urgência com estabilidade operacional. Uma resposta a zero-day não pode esperar o ciclo mensal. Mas o ciclo mensal também não pode ser descartado toda vez que um zero-day aparece. O Patch Management resolve esse conflito com três filas que operam simultaneamente e de forma independente.
Patches convencionais dentro da janela de manutenção configurada. Não é interrompido por urgências, opera em paralelo.
Browsers, VPNs, clientes de e-mail e aplicações de alto risco. Ciclo semanal sem impacto no ciclo mensal.
CVEs com exploit ativo no CISA KEV. Deploy imediato dentro da próxima janela disponível. Não depende do ciclo mensal.
As três filas processam grupos de ativos distintos e não interferem umas nas outras. Um Zero-Day Response em servidores de autenticação ocorre simultaneamente ao ciclo de Manutenção Mensal em servidores de arquivos, sem cancelamento, sem conflito, sem a decisão manual de "qual fila tem prioridade hoje".
Impacto no negócio, o que o re-scan muda.
A validação por re-scan não é um detalhe técnico, é o que transforma o Patch Management de um processo de deploy em um processo de redução de risco comprovada.
MTTR real vs. MTTR declarado
A maioria das organizações mede Tempo Médio de Correção como o tempo entre o ticket de vulnerabilidade ser aberto e fechado. O problema é que o ticket é fechado quando o patch é instalado, não quando a CVE é confirmada remediada. O MTTR que vai para o relatório de compliance mede o processo de TI, não a redução de risco.
O Patch Management calcula o Tempo Médio de Correção real: tempo entre a primeira detecção pelo VulScan e a confirmação pelo re-scan de que a CVE não existe mais no ativo. Essa é a métrica que um auditor de ISO 27001 ou PCI DSS deveria aceitar, e que a maioria das organizações não consegue produzir sem processos manuais extensos.
Loop fechado com o CRQ
Quando o re-scan confirma o fechamento de uma CVE, o módulo CRQ recalcula automaticamente o ALE (Annual Loss Expectancy) de todos os cenários de risco afetados. O CISO pode apresentar ao board: "remediamos essas 12 vulnerabilidades esta semana, a exposição financeira ao cenário de ransomware reduziu de R$ 1,3M para R$ 480K". Essa é a conversa que o board consegue ter.
Zero footprint, sem exceções de segurança
A arquitetura agentless do Patch Management usa os mesmos protocolos de gerenciamento remoto já autorizados pelo time de TI. Nenhum binário permanente nos endpoints. Nenhuma exceção de firewall adicional. Nenhum conflito com soluções de EDR. O deploy ocorre via sessões autenticadas que encerram completamente após a operação.
Compliance, evidências de fechamento, não de instalação.
O re-scan pós-deploy confirma efetividade, não apenas instalação. O histórico de detecção + deploy + confirmação por CVE atende ao requisito de registro de ações do A.8.8.
Definições de filas por score de risco e re-scan de confirmação atendem diretamente ao requisito 6.3.3, com evidência de efetividade que vai além do log de instalação.
O re-scan que confirma ausência da CVE pós-deploy é a evidência direta de "correção eficaz" exigida pelo RS.MI-3, não apenas evidência de tentativa de correção.
O MTTR auditável com confirmação por re-scan e relatórios estruturados por período e tipo de ativo atendem ao modelo de evidências exigido para prestação de contas ao BACEN.
Conclusão, a diferença entre fechar e confirmar que fechou.
O patch instalado é o meio. A CVE não mais detectável no re-scan é o fim. Confundir os dois é o motivo pelo qual tantas organizações têm processos de patch management que parecem funcionar, mas não reduzem risco de forma comprovada.
A janela entre disponibilidade do exploit e aplicação do patch não vai desaparecer, é estrutural. O que é controlável é garantir que, quando o patch é aplicado, a vulnerabilidade efetivamente fecha. E que o fechamento é documentado, auditável e conectado à redução de risco financeiro.
O EcoTrust Patch Management fecha esse loop de ponta a ponta: prioriza, testa, deploya, confirma e calcula. O Tempo Médio de Correção real, do momento de detecção até a confirmação de fechamento, fica disponível no mesmo dia para o CISO apresentar ao board e ao auditor aceitar.
Feche a janela de exposição com confirmação real.
Demonstração ao vivo