Remediação automática de vulnerabilidades, com ou sem patch

O que é remediação automática de vulnerabilidades

Remediação automática de vulnerabilidades é o processo em que uma plataforma recebe a falha priorizada, escolhe e constrói a correção adequada (patch, mudança de configuração, mitigação ou workaround), aplica no ativo com testes e rollback e confirma por re-scan que a vulnerabilidade deixou de existir. Instalar o pacote é só um dos caminhos; o resultado que conta é a falha fechada.

A definição importa porque o mercado usa o termo de forma frouxa. Muita ferramenta chama de "remediação automática" o que é distribuição automática de patch: pegar o pacote que o fabricante publicou e empurrar para os endpoints. Isso resolve uma parte do problema, a parte que já tem pacote pronto. Configuração insegura, CVE sem correção publicada e servidor que não pode ser atualizado agora continuam na fila humana.

Este guia explica o que separa remediação de distribuição de patch, os quatro caminhos de correção, como o ciclo funciona etapa por etapa, o que deve continuar com aprovação humana e como medir se a automação está funcionando. Para a base do processo, veja o guia de gestão de patches.

Resumo em 5 pontos

1. Remediar não é instalar pacote. É fazer a vulnerabilidade deixar de existir, com o caminho que funcionar naquele ativo.
2. O tempo do atacante encolheu. O tempo médio até a exploração caiu para 5 dias em 2023, segundo a Mandiant, e a correção manual não acompanha.
3. Parte das falhas não tem patch. Zero-day, fim de suporte e vulnerabilidade de configuração exigem mitigação ou mudança de estado, não pacote.
4. Sem re-scan, não há prova. Patch instalado com processo antigo em memória não fecha a CVE; só a nova varredura confirma.
5. Automatize a execução, governe a decisão. Staging, rollback e critérios de parada automáticos; aceitação de risco e exceções com dono humano.

Leia também: Patch management automatizado: o que automatizar e o que não

Por que a correção manual não acompanha a exploração

A conta da remediação é de velocidade de execução. Os dados recentes mostram uma distância grande entre o tempo que o atacante precisa e o tempo que as empresas levam:

• 5 dias: tempo médio até a exploração das vulnerabilidades divulgadas em 2023, contra 32 dias em 2021 e 2022 e 63 dias em 2018 e 2019, segundo a análise de time-to-exploit da Mandiant (Google Cloud).
• 32,1%: fatia das vulnerabilidades do catálogo de exploradas com evidência de exploração no mesmo dia da publicação da CVE ou antes dela no primeiro semestre de 2025, contra 23,6% em 2024, segundo a VulnCheck.
• 54% e 32 dias: no Verizon DBIR 2025, só cerca de 54% das vulnerabilidades de dispositivos de borda (VPN, firewall) foram totalmente corrigidas ao longo do ano, com mediana de 32 dias para chegar lá.
• Mais de 60%: das vulnerabilidades do CISA KEV encontradas em 1,4 milhão de organizações seguiam sem correção depois do prazo da CISA, e mesmo as críticas levavam em média quatro meses e meio para serem remediadas, segundo a Bitsight.

O gargalo raramente é detecção. O que consome semanas é o trabalho entre o achado e a correção rodando: pesquisar o que corrige, obter o pacote ou desenhar a mitigação, testar, agendar, aplicar e conferir. É esse trabalho que a remediação automática ataca.

A pressão regulatória vai na mesma direção. Em junho de 2026, a CISA publicou a BOD 26-04, que substituiu a BOD 22-01 e passou a exigir das agências federais americanas correção em 3 dias para as combinações de maior risco (por exemplo, vulnerabilidade no KEV que dá controle total do sistema) e em 14 dias para a maior parte das demais do KEV. No Brasil, a Resolução CMN 4.893 exige que instituições financeiras mantenham política de segurança cibernética com controles que incluem testes e varreduras para detecção de vulnerabilidades, e o auditor pergunta o que foi feito com o que a varredura encontrou.

Remediação não é só patch: os quatro caminhos de correção

A pergunta certa não é "qual patch aplicar?", e sim "o que faz esta vulnerabilidade deixar de existir neste ativo?". Há quatro respostas possíveis, e uma plataforma de remediação precisa saber usar todas.

O patch de fabricante é o único caminho que uma ferramenta de catálogo cobre. Os outros três dependem de entender a vulnerabilidade no contexto do ativo, e é neles que fica o backlog que "não anda".

Mitigação e workaround têm um cuidado próprio: são provisórios. Uma remediação bem feita mantém o item aberto e rastreado até a correção definitiva, em vez de dar a falha por encerrada. O tema está detalhado em vulnerabilidade sem patch: como mitigar até a correção.

Leia também: Vulnerabilidade sem patch: mitigação, workaround e patch virtual

Remediação automática, patch automatizado e orquestração: qual a diferença

Três categorias de ferramenta disputam o mesmo vocabulário. Separar o que cada uma entrega evita comprar a errada. A última coluna mostra a EcoTrust, identificada como autora deste artigo, com base só nas páginas públicas do AutoPatch.

Na prática, uma empresa madura usa as três camadas. A orquestração conduz o fluxo entre times, o patch automatizado cobre o volume rotineiro e a remediação automática resolve o que o catálogo não alcança e prova o resultado. A diferença entre automatizar uma regra e deixar a plataforma decidir a fila e expandir o deploy está em patch autônomo.

Como funciona a remediação automática, etapa por etapa

Um ciclo completo de remediação automática segue sete etapas. A ordem importa: a construção da correção vem antes da aplicação, e a validação vem por último.

1. Receber o achado priorizado. A falha chega com contexto de risco: CVSS, probabilidade de exploração (EPSS), presença no CISA KEV e criticidade do ativo. Sem priorização, automação só acelera a correção do que não importa.
2. Definir a fila. CVE com exploração ativa não pode esperar o ciclo mensal. Filas separadas (rotina, prioritária e emergencial) permitem responder ao urgente sem cancelar a manutenção.
3. Escolher o caminho e construir a correção. Patch e versão corretos para aquele sistema, mudança de configuração, mitigação ou workaround. É a etapa que a fila humana normalmente absorve.
4. Testar em grupo piloto. A correção roda primeiro em ativos com o mesmo perfil da produção, com critérios automáticos de aceitação: taxa de sucesso, serviços críticos respondendo, conectividade ativa.
5. Aplicar com rollback. Expansão para o restante dos ativos dentro da janela. Se um serviço crítico cair, a correção é revertida e a campanha para, com notificação ao responsável.
6. Validar por re-scan. Nova varredura nos ativos corrigidos. Se a CVE sumiu, o item fecha com data e hora. Se persiste, volta para a fila com o contexto do que foi tentado.
7. Registrar o dado de execução. Quando o deploy aconteceu e quando a validação confirmou, por CVE e por ativo. É o insumo do Tempo Médio de Correção (MTTR) e a evidência para auditoria.

Por que a validação por re-scan é obrigatória

Aplicação bem-sucedida e vulnerabilidade corrigida não são a mesma coisa. Três situações comuns mostram a diferença:

• Processo antigo em memória. O pacote foi atualizado em disco, mas o serviço não reiniciou e continua rodando a versão vulnerável.
• Instância errada. A correção entrou em uma instalação, enquanto a vulnerável é outra cópia da biblioteca empacotada dentro de uma aplicação.
• Mais de um vetor. A mitigação bloqueou um caminho de exploração, mas a CVE continua alcançável por outro.

Mitigações também falham. No caso Log4Shell (CVE-2021-44228), a configuração log4j2.formatMsgNoLookups, recomendada nos primeiros dias, se mostrou insuficiente e a orientação passou a ser atualizar a biblioteca. Em janeiro de 2024, a Ivanti avisou que uma condição de corrida ao aplicar o XML de mitigação do Connect Secure podia deixar o equipamento vulnerável. Em ambos os casos, só a verificação depois da aplicação revelava o problema.

A evidência que importa para o auditor é a ausência da CVE após a intervenção, não o log da intervenção. É também o que a ISO/IEC 27001:2022 pede no controle A.8.8 (gestão de vulnerabilidades técnicas), com ações registradas e eficácia avaliada, e o que o NIST CSF 1.1 descrevia em RS.MI-3: vulnerabilidades novas mitigadas ou documentadas como risco aceito.

O que automatizar e o que manter com aprovação humana

Automação total não é o objetivo. O objetivo é tirar da fila humana o trabalho repetitivo e deixar com pessoas as decisões que exigem contexto de negócio. Use este checklist para desenhar a fronteira:

• Automatizar: coleta e correlação dos achados, ordenação da fila por risco, escolha do pacote e da versão, construção de mudanças de configuração padronizadas.
• Automatizar: staging em grupo piloto, critérios de aceitação, expansão dentro da janela aprovada e rollback quando um serviço crítico cai.
• Automatizar: re-scan, fechamento do item e registro de datas por CVE.
• Aprovar previamente (política): janelas de manutenção por grupo de ativos, ativos excluídos da automação, limites de reinicialização.
• Manter com decisão humana: aceitação de risco residual, exceções de prazo, mitigação que desliga funcionalidade de negócio, mudanças em sistemas sem grupo piloto equivalente.
• Manter com dono nomeado: cada mitigação e workaround, com prazo para a correção definitiva.

A regra prática: a máquina executa dentro de uma política que pessoas aprovaram e para quando algo sai do esperado.

Como os fabricantes tratam a remediação além do patch

O mercado de patch se dividiu em duas abordagens. A primeira automatiza a distribuição de atualizações publicadas: o Windows Autopatch da Microsoft gerencia atualizações do ecossistema Microsoft em anéis de implantação, a Tanium oferece patch autônomo com implantação em anéis, e a Ivanti vende gerenciamento autônomo de patches com priorização por risco e tarefas paralelas, inclusive para zero-day. É uma camada essencial para o volume rotineiro.

A segunda vai além do pacote. A Vicarius descreve o vRx como solução que combina patch automatizado, um motor de scripts para vulnerabilidades complexas ou de configuração e o x_protect, uma proteção sem patch que funciona como controle compensatório até a correção. A Qualys lançou em 2024 o TruRisk Eliminate, com o TruRisk Mitigate, que aplica mudanças de configuração recomendadas por fabricantes, CISA e pesquisa própria via scripts para Linux e Windows, e o TruRisk Isolate, que coloca ativos de risco em quarentena.

Ao avaliar qualquer fornecedor, inclusive os que já estão no seu ambiente, faça as mesmas perguntas:

1. Corrige vulnerabilidade de configuração ou só instala pacote?
2. O que acontece com uma CVE sem patch publicado: vira ticket ou recebe mitigação aplicada?
3. Exige agente instalado em cada endpoint?
4. Tem grupo piloto, critério de parada e rollback automático?
5. Confirma o fechamento por nova varredura ou só pelo log de instalação?
6. Registra data de aplicação e data de confirmação por CVE?

Para uma comparação estruturada de ferramentas, veja ferramentas de gerenciamento de patches.

Remediação automática no EcoTrust AutoPatch

Aplicando os mesmos critérios ao AutoPatch, o módulo de remediação autônoma da EcoTrust: ele recebe o achado priorizado do VulScan, com CVSS, EPSS, CISA KEV e criticidade do ativo, ordena a fila e constrói a correção para aquela vulnerabilidade naquele ativo, seja patch de fabricante, mudança de configuração, mitigação ou workaround.

• Configuração e CVE sem patch: sim. A construção da correção não depende de haver pacote publicado; mitigações e workarounds ficam rastreados até a correção definitiva.
• Agente nos endpoints: não. A aplicação usa protocolos nativos (WMI e WinRM no Windows, SSH no Linux e no macOS), com acesso à rede pelo EcoTrust Connect, sem binário permanente após a sessão.
• Piloto, parada e rollback: staging em grupo piloto com critérios automáticos; se algo falha, a campanha para e o responsável é notificado; rollback automático se serviço crítico ficar indisponível.
• Filas: três filas paralelas (Regular, Prioritária e Zero-Day); CVEs no CISA KEV vão para a Zero-Day independentemente do score.
• Prova de fechamento: re-scan nos ativos corrigidos; se a CVE persiste, o item volta para a fila com contexto.
• Dado de execução: data do deploy e data da confirmação por CVE, consumidas pelo Flow, onde o MTTR é medido, e evidência para ISO 27001, PCI DSS 4.0 e BACEN.

A frase que resume a diferença: ferramentas de patch distribuem o que o fabricante publicou; o AutoPatch fecha a vulnerabilidade, com ou sem patch, e prova com re-scan. O detalhamento técnico está no white paper do AutoPatch.

Leia também: Gestão de patches: guia completo de processo, política e SLA

Como medir se a remediação automática funciona

Remediação automática se justifica por resultado medido. Quatro indicadores bastam para começar:

Compare esses números com os prazos que você assumiu: o requisito 6.3.3 do PCI DSS 4.0 pede patches críticos de segurança instalados em até um mês após a publicação, e a BOD 26-04 serve de referência para o que é "rápido" em vulnerabilidade explorada. A forma de organizar essas ondas de correção está em campanha de remediação.

Perguntas Frequentes

Remediação automática de vulnerabilidades é a mesma coisa que patch automático?

Não. Patch automático distribui pacotes que o fabricante publicou. Remediação automática escolhe o caminho que fecha a falha (patch, configuração, mitigação ou workaround), aplica e confirma por re-scan. Todo patch automático é uma forma limitada de remediação, mas o contrário não vale.

É seguro aplicar correções sem intervenção humana?

É seguro quando a automação roda dentro de uma política aprovada: janelas definidas, grupo piloto com critérios de aceitação, rollback automático e parada com notificação quando algo falha. Decisões de risco residual, exceções e mitigações que afetam funcionalidade de negócio devem continuar com aprovação humana.

O que fazer quando a vulnerabilidade não tem patch?

Aplique a mitigação indicada no aviso do fabricante ou na CISA (desligar o componente, restringir acesso, mudar configuração), valide que o vetor foi bloqueado, registre o risco residual com um dono e mantenha o item aberto até a correção definitiva. O passo a passo está em vulnerabilidade sem patch.

Remediação automática precisa de agente instalado nos computadores?

Depende da ferramenta. Muitas soluções de patch usam agente em cada endpoint. Outras, como o AutoPatch, aplicam a correção por protocolos nativos de gerenciamento remoto (WMI, WinRM e SSH), sem software permanente no ativo.

Como provar para a auditoria que a vulnerabilidade foi corrigida?

Com o re-scan após a intervenção e o registro por CVE da data de aplicação e da data de confirmação. Log de instalação prova tentativa; ausência da CVE na nova varredura prova correção, que é o que a ISO 27001 A.8.8 e os auditores de PCI DSS e BACEN buscam.

Conclusão: remediar é fechar a falha, não instalar o pacote

A diferença entre distribuir patch e remediar vulnerabilidade é a diferença entre registrar uma tentativa e eliminar uma exposição. Com exploração em dias e uma parte relevante das falhas sem pacote disponível, o backlog que não anda é justamente o que o catálogo do fabricante não cobre.

Remediação automática bem feita constrói a correção certa para cada caso, testa antes de expandir, para quando algo falha e prova o resultado com nova varredura. Comece pelas filas de maior risco, defina a fronteira entre o que a máquina executa e o que as pessoas decidem, e meça MTTR com a data de confirmação, não com a data do ticket.

---

Referências

• Mandiant, "How Low Can You Go? An Analysis of 2023 Time-to-Exploit Trends", Google Cloud, 2024. cloud.google.com
• VulnCheck, "State of Exploitation 1H 2025", VulnCheck, 2025. vulncheck.com
• Verizon, "2025 Data Breach Investigations Report", Verizon Business, 2025. verizon.com
• Bitsight TRACE, "Bitsight Reveals More Than 60 Percent of Known Exploited Vulnerabilities Remain Unmitigated", Bitsight, 2024. bitsight.com
• CISA, "BOD 26-04: Prioritizing Security Updates Based on Risk", CISA, 2026. cisa.gov
• Tenable, "CISA BOD 26-04 FAQ", Tenable, 2026. tenable.com
• CISA, "ED 24-01: Mitigate Ivanti Connect Secure and Ivanti Policy Secure Vulnerabilities", CISA, 2024. cisa.gov
• Qualys, "Qualys Expands TruRisk Eliminate Platform", Qualys, 2024. qualys.com
• Vicarius, "vRx: patch management, scripting engine e patchless protection", Vicarius. vicarius.io
• Microsoft, "Windows Autopatch overview", Microsoft Learn. learn.microsoft.com
• ISO/IEC 27001:2022, controle A.8.8: gestão de vulnerabilidades técnicas. iso.org
• PCI Security Standards Council, "PCI DSS v4.0", requisito 6.3.3, 2022. pcisecuritystandards.org
• Conselho Monetário Nacional, "Resolução CMN nº 4.893/2021", Banco Central do Brasil, 2021. bcb.gov.br