Gestão de patches: o que é, processo, política e SLA

O que é gestão de patches

Gestão de patches (ou gerenciamento de patches, do inglês patch management) é o processo contínuo de identificar, priorizar, obter, testar, aplicar e verificar correções de software em todos os ativos de uma organização, com prazos definidos por risco e evidência de que cada vulnerabilidade foi de fato fechada.

A definição segue a do NIST, que na SP 800-40 Rev. 4 trata o patch como manutenção preventiva da tecnologia e descreve a gestão de patches corporativa como o processo de identificar, priorizar, adquirir, instalar e verificar a instalação de patches, atualizações e upgrades em toda a organização. A palavra que mais pesa nessa lista é a última: verificar.

Se você quer só o significado do termo, comece por o que é patch. Este guia é para quem precisa montar ou melhorar o processo em uma empresa: as 7 etapas, o que uma política precisa conter, prazos por severidade, o que ISO 27001, NIST, PCI DSS e Banco Central exigem, as métricas que importam e o ponto que quase todo programa esquece, que é a vulnerabilidade sem patch.

Resumo em 5 pontos

1. Gestão de patches é um processo, não uma ferramenta: inventário, priorização, teste, implantação e verificação, com donos e prazos.
2. A fila se ordena por risco real: exploração ativa (CISA KEV), probabilidade de exploração (EPSS), gravidade (CVSS) e criticidade do ativo.
3. A política define SLAs por severidade e o caminho formal para exceções, que precisam de prazo e controle compensatório.
4. Instalar não é fechar: só um novo scan confirma que a vulnerabilidade deixou de existir.
5. Parte do risco não tem patch: configuração insegura, produto sem suporte e falha sem correção do fabricante exigem mitigação rastreada.

Leia também: O que é patch? Significado, tipos e exemplos práticos

Por que a gestão de patches é crítica

O volume de falhas e a velocidade dos atacantes tornaram o processo manual insustentável:

• Volume: segundo a análise de Jerry Gamblin, 48.185 CVEs foram publicados em 2025, 20,6% a mais que em 2024.
• Velocidade: a VulnCheck registrou que 28,3% das vulnerabilidades exploradas no primeiro trimestre de 2025 tiveram exploração em até 1 dia da divulgação do CVE.
• Impacto: o Verizon DBIR 2025 aponta a exploração de vulnerabilidades como vetor inicial de 20% das violações, e mostra que só 54% das vulnerabilidades em dispositivos de borda foram totalmente corrigidas no ano, com mediana de 32 dias.
• Causa evitável: em estudo do Ponemon Institute para a ServiceNow, 60% das violações envolviam uma vulnerabilidade com patch disponível e não aplicado.

A conta é simples: exploração em horas ou dias, correção em semanas. A gestão de patches existe para encurtar esse intervalo sem derrubar a operação.

Gestão de patches x gestão de vulnerabilidades

Os dois processos se sobrepõem, mas não são a mesma coisa.

Na prática, a gestão de vulnerabilidades decide o que corrigir e a gestão de patches executa. Quando as duas áreas usam bases diferentes, aparecem as duas falhas clássicas: patch aplicado em ativo que não era prioridade e vulnerabilidade crítica esquecida porque não havia pacote para ela.

O processo de gestão de patches em 7 etapas

1. Inventário de ativos e software

Não se corrige o que não se conhece. O inventário precisa listar servidores, estações, equipamentos de rede, instâncias em nuvem e o software instalado em cada um, com versão e patches já aplicados. Ativos de shadow IT ficam fora de qualquer campanha se não forem descobertos. Veja como manter essa base atualizada em inventário de ativos agentless.

2. Monitoramento de vulnerabilidades e patches disponíveis

Acompanhe boletins dos fabricantes (como o Patch Tuesday da Microsoft, na segunda terça-feira de cada mês), o catálogo KEV da CISA e os resultados do scan de vulnerabilidades, que cruza o inventário com as falhas conhecidas e aponta o que está pendente em cada ativo.

3. Avaliação e priorização por risco

O CVSS mede gravidade técnica, mas não diz se a falha está sendo explorada nem se o ativo importa. Uma fila madura combina:

• presença no CISA KEV (exploração confirmada);
• probabilidade de exploração (EPSS);
• gravidade técnica (CVSS);
• exposição do ativo (internet ou rede interna) e criticidade para o negócio.

4. Planejamento da campanha

Defina escopo, ordem, janelas de manutenção, responsáveis e plano de rollback. Separe filas: correções urgentes não podem esperar o ciclo mensal, e o ciclo mensal não pode ser cancelado toda vez que surge uma urgência. O tema é aprofundado em campanha de remediação priorizada.

5. Teste em grupo piloto

Aplique primeiro em um grupo de ativos com o mesmo perfil de sistema operacional e software da produção. Defina critérios objetivos de aceite: taxa de sucesso, ausência de falhas, serviços críticos respondendo, conectividade preservada.

6. Implantação em escala

Com o piloto aprovado, expanda por ondas. Monitore o progresso, trate as falhas individualmente e mantenha o rollback pronto caso um serviço crítico fique indisponível.

7. Verificação e fechamento

Execute um novo scan nos ativos corrigidos. Pacote instalado não garante falha fechada: um serviço que não reiniciou continua rodando a versão antiga em memória, e uma CVE com mais de um vetor pode seguir aberta por outro caminho. Registre a data de aplicação e a data da confirmação por CVE. Esses dois registros alimentam as métricas e servem de evidência em auditoria.

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

Política de gestão de patches: o que precisa conter

A política transforma o processo em regra da empresa. Sem ela, cada exceção vira negociação. Use o checklist abaixo como modelo.

• Objetivo e escopo: quais ambientes, sistemas operacionais, aplicações, equipamentos de rede e nuvem estão cobertos.
• Papéis e responsabilidades: quem prioriza (segurança), quem aplica (operações), quem aprova janelas (donos de sistema) e quem aceita risco (gestão).
• Fontes de informação: boletins de fabricantes, CISA KEV, scans e inteligência de ameaças.
• Critério de priorização: como KEV, EPSS, CVSS e criticidade do ativo definem a severidade interna.
• SLA por severidade: prazo máximo, contado da publicação do patch ou da detecção.
• Janelas de manutenção: regulares e emergenciais, com regra de comunicação.
• Teste e rollback: grupo piloto, critérios de aceite e plano de reversão.
• Exceções: justificativa, controle compensatório, dono e data de revisão.
• Vulnerabilidades sem patch: como mitigar e como rastrear até a correção definitiva.
• Verificação: novo scan obrigatório antes de encerrar o item.
• Métricas e relatórios: indicadores, periodicidade e destinatários.
• Revisão da política: ao menos uma vez por ano ou após incidente relevante.

Exemplo de SLA por severidade

Os prazos abaixo são uma referência de mercado, não uma norma. Ajuste à capacidade da equipe e ao apetite de risco aprovado pela gestão.

O que as normas e reguladores exigem

Nenhuma norma diz "instale todos os patches", mas todas pedem um processo de correção baseado em risco e com evidência.

O ponto comum é a prova. Um log dizendo que o pacote foi instalado mostra uma tentativa; um re-scan sem a CVE mostra que a falha fechou. Para instituições reguladas pelo Banco Central, a Resolução CMN 5.274/2025 detalhou os controles mínimos da 4.893 e tornou explícita a avaliação e correção de vulnerabilidades. Para o contexto do setor, veja gestão de vulnerabilidades na área financeira e o guia da ISO 27001.

Métricas da gestão de patches

Sem métrica, não há como saber se o processo melhora. As essenciais:

O MTTR só é confiável quando parte de datas reais de execução e de confirmação, não da data de fechamento do chamado. Veja outros indicadores em indicadores de gestão de vulnerabilidades.

Erros comuns na gestão de patches

1. Priorizar só por CVSS: a fila fica cheia de "críticos" que ninguém explora, enquanto uma falha média do KEV espera.
2. Fechar o chamado sem novo scan: o painel mostra 100% e o ambiente continua vulnerável.
3. Uma fila só: a urgência atropela o ciclo mensal, ou o ciclo mensal atrasa a urgência.
4. Ignorar terceiros e firmware: navegadores, VPNs, clientes de e-mail e equipamentos de rede ficam para depois.
5. Exceção sem prazo: o aceite de risco vira permanente.
6. Tratar como "sem solução" o que não tem patch: a vulnerabilidade fica aberta esperando o fabricante.

Patch de catálogo e vulnerabilidade sem patch

As ferramentas tradicionais de patch management trabalham sobre um catálogo: sabem distribuir o pacote que o fabricante publicou. Mas uma parte relevante da exposição não se resolve assim:

• falha divulgada sem correção do fabricante, inclusive zero-days;
• produto fora de suporte, que não recebe mais patches;
• ativo que não pode ser atualizado agora, por dependência de aplicação legada;
• exposição de configuração, como serviço aberto, cifra fraca ou permissão excessiva.

Para esses casos, a correção é uma mudança de configuração, uma mitigação recomendada pelo fabricante, um workaround ou um patch virtual, sempre com dono, prazo e acompanhamento até a correção definitiva. O detalhamento está em vulnerabilidade sem patch e em remediação automática de vulnerabilidades.

Leia também: Vulnerabilidade sem patch: como mitigar até a correção definitiva

Manual, automatizado ou autônomo

O processo de 7 etapas vale para qualquer nível de maturidade. O que muda é quem executa:

• Manual: a equipe faz cada etapa, com planilhas e scripts. Funciona em ambientes pequenos e quebra com volume.
• Automatizado: a ferramenta executa regras definidas por pessoas, como "aplicar patches críticos no grupo piloto na terça e no restante na quinta". Detalhes em patch management automatizado.
• Autônomo: o sistema decide a fila, testa, expande e confirma o resultado, parando e notificando quando algo foge do esperado. Veja patch autônomo.

Para comparar fabricantes com critérios objetivos, consulte o guia de ferramentas de gerenciamento de patches.

Como o AutoPatch executa a gestão de patches

O AutoPatch é o módulo de execução da remediação na plataforma EcoTrust e cobre as etapas de 4 a 7 do processo, com o mesmo patamar operacional das grandes plataformas do mercado:

• Fila ordenada por risco: recebe o achado priorizado do VulScan, com CVSS, EPSS, CISA KEV e criticidade do ativo. CVEs do KEV vão direto para a fila Zero-Day.
• Três filas paralelas: Regular (manutenção mensal), Prioritária (semanal, para navegadores, VPNs e clientes de e-mail) e Zero-Day (emergencial), sem que uma interrompa a outra.
• Grupo piloto com critérios automáticos: pelo menos 95% de sucesso, zero falhas, serviços críticos respondendo e conectividade ativa. Se algo falhar, a campanha para e o responsável é notificado.
• Rollback automático se um serviço crítico ficar indisponível.
• Windows, Linux e macOS no mesmo fluxo de campanha.

O que diferencia o módulo está em dois pontos. Primeiro, ele constrói a correção também quando não há patch de fabricante: mudança de configuração, mitigação ou workaround, com o item rastreado até a correção definitiva. Segundo, a aplicação acontece sem agente nos endpoints, por WMI/WinRM no Windows e SSH no Linux e no macOS, com acesso à rede pelo EcoTrust Connect. Ao final, um re-scan confirma que a CVE fechou, e o registro de aplicação e de confirmação por CVE alimenta o Tempo Médio de Correção medido no Flow e serve de evidência para ISO 27001 A.8.8, NIST CSF e Banco Central. 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.

Perguntas Frequentes

O que é gestão de patches?

É o processo de identificar, priorizar, testar, aplicar e verificar correções de software em todos os ativos da empresa, com prazos definidos por risco. O objetivo é fechar vulnerabilidades antes que sejam exploradas, sem interromper a operação.

Qual a diferença entre gestão de patches e gestão de vulnerabilidades?

A gestão de vulnerabilidades descobre e prioriza as falhas do ambiente. A gestão de patches executa a correção e confirma o resultado. A primeira decide o que corrigir; a segunda faz a correção acontecer. Vulnerabilidades sem patch exigem que as duas trabalhem juntas.

Quais são as etapas da gestão de patches?

Inventário de ativos, monitoramento de patches e vulnerabilidades, priorização por risco, planejamento da campanha, teste em grupo piloto, implantação em escala e verificação por novo scan, com registro das datas de aplicação e de confirmação.

Qual o prazo ideal para aplicar patches de segurança?

Não há prazo único. Uma referência comum é tratar vulnerabilidades com exploração ativa em horas ou poucos dias, críticas em até 15 dias, altas em até 30 e médias em até 90. O PCI DSS 4.0 exige patches para vulnerabilidades críticas em até um mês da publicação.

O que a ISO 27001 exige sobre patches?

O controle A.8.8 da ISO/IEC 27001:2022 pede que a organização obtenha informações sobre vulnerabilidades técnicas, avalie sua exposição e tome medidas apropriadas. Na auditoria, isso se traduz em processo documentado, prazos e registros de correção e de verificação.

O que fazer quando não existe patch para a vulnerabilidade?

Aplicar uma medida alternativa (mudança de configuração, mitigação indicada pelo fabricante, workaround ou patch virtual), registrar como exceção com dono e prazo, e acompanhar até a correção definitiva. Deixar o item parado esperando o fabricante é o erro mais caro.

Conclusão: gestão de patches é fechar a vulnerabilidade, não instalar o pacote

Gestão de patches é um processo de 7 etapas com uma política por trás: inventário, priorização por risco, campanha, piloto, implantação, verificação e métricas. As normas, da ISO 27001 à Resolução CMN 5.274, pedem o mesmo: prazos coerentes com o risco e prova de que a correção funcionou.

Dois pontos separam um programa maduro dos demais. O primeiro é medir o fechamento, não a instalação, com re-scan e datas reais. O segundo é não deixar a vulnerabilidade sem patch fora do processo. É nesses dois pontos que o AutoPatch atua: constrói a correção, aplica sem agente e confirma com re-scan.

---

Referências

• NIST, "SP 800-40 Rev. 4: Guide to Enterprise Patch Management Planning: Preventive Maintenance for Technology", 2022. csrc.nist.gov
• NIST, "Cybersecurity Framework 2.0", PR.PS-02, 2024. nist.gov/cyberframework
• 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. pcisecuritystandards.org
• Conselho Monetário Nacional, Resolução CMN 4.893/2021 e Resolução CMN 5.274/2025. bcb.gov.br
• CISA, "Known Exploited Vulnerabilities Catalog" e "BOD 26-04: Prioritizing Security Updates Based on Risk", 2026 (substituiu a BOD 22-01). cisa.gov
• Jerry Gamblin, "2025 CVE Data Review", 2026. jerrygamblin.com
• VulnCheck, "Exploitation Trends Q1 2025", 2025. vulncheck.com
• Verizon, "2025 Data Breach Investigations Report", 2025. verizon.com/business/resources/reports/dbir
• Ponemon Institute e ServiceNow, "Costs and Consequences of Gaps in Vulnerability Response", 2019. servicenow.com