Resposta rápida
A maioria dos programas de patch cobre só o sistema operacional e os aplicativos que a própria TI instalou — o resto segue sem atualização até um incidente forçar alguém a olhar.
- 56% das organizações ainda temem estar expostas a vulnerabilidades conhecidas e não corrigidas
- Só 49% incluem aplicativos de terceiros no processo de patch, mesmo com 74% já tendo sofrido uma vulnerabilidade vinda de um app de terceiro
- A lacuna raramente é a ferramenta — é decidir, entre times, quem é dono de quê
Todo relatório de patch parece limpo à primeira vista. Marcações verdes, percentual de conformidade lá em cima, painel fechado por mais uma semana.
Faça uma pergunta mais difícil e o quadro muda: corrigido comparado a quê — o sistema operacional, ou cada executável rodando naquela máquina?
Para a maioria das equipes de TI, a resposta honesta é o sistema operacional, mais o que a própria TI empurrou.
Tudo o mais — o editor de PDF que um designer instalou há dois anos, o cliente de transferência de arquivos que o financeiro usa uma vez por trimestre, a extensão de navegador que ninguém lembra de ter aprovado — está rodando com prazo de validade vencendo.
Um ciclo de patch não é um evento só. São dezenas deles, sobrepostos, um por fornecedor, e a maioria nunca teve um chamado aberto para começo de conversa.
O ciclo de patch que nunca termina de verdade
A gestão de patches ficou mais rápida. A fatia de organizações que aplica atualizações em até seis dias após o lançamento quase quadruplicou entre 2023 e 2026 — de 15% para 59%, segundo o State of Patch Management Report 2026, da Adaptiva em parceria com a Demand Metric, com mais de 200 profissionais de segurança e TI entrevistados.
A velocidade subiu. A confiança não acompanhou no mesmo ritmo.
O gargalo é coordenação, não ferramenta
Mais de 60% das organizações ainda dependem de etapas manuais em algum ponto do ciclo de patch, e só 8% relatam execução totalmente autônoma hoje, segundo o mesmo relatório. O resto fica no meio do caminho — automatizado o bastante para parecer moderno, manual o bastante para deixar brechas na passagem de bastão entre segurança, operações de TI e quem quer que seja dono de um aplicativo específico.
É nessa passagem de bastão que o software de terceiro escapa. Ninguém é dono dele de forma clara, então ninguém agenda a atualização.
| Camada de software | Costuma ser coberta? | Quem é dono | Se ficar de fora |
|---|---|---|---|
| Atualizações do sistema operacional | Sim, automatizado | TI / ferramenta de patch | Raro — detectado rápido |
| Apps essenciais (navegador, cliente VPN, suíte de escritório) | Geralmente | TI | Ocasional, pego em auditoria |
| Software de nicho ou de área específica (leitores de PDF, plugins, utilitários) | Muitas vezes não | Quem instalou | Silencioso — só aparece depois de um incidente |
| Ferramentas instaladas pelo próprio usuário / shadow IT | Quase nunca | Usuário final | Invisível para a TI por completo |
O que um relatório de patch “verde” não mostra
Quais máquinas realmente terminaram a instalação
Um envio marcado como “concluído” não é o mesmo que uma instalação concluída em todo endpoint. Notebooks que estavam em suspensão, fora da VPN ou no meio de uma reinicialização no momento errado saem silenciosamente da contagem — e ficam de fora até alguém rodar uma segunda varredura.
Quais aplicativos nunca entraram no escopo
Uma política de patch construída em torno do sistema operacional e de uma lista curta de apps aprovados vai reportar 100% de conformidade contra essa lista — e não dizer nada sobre tudo o que fica de fora dela.
Quem autorizou a exceção, e por quê
Toda frota tem máquinas rodando uma versão antiga porque atualizar quebra algum fluxo de trabalho. Essa exceção costuma ser um acordo verbal, não uma aceitação de risco documentada e com prazo.
Quanto tempo a janela de exposição durou de verdade
“Corrigido” mostra o estado final. Não mostra quantos dias a vulnerabilidade ficou aberta antes disso, nem se algo tocou a máquina durante essa janela.
Um auditor não pergunta se existe uma política de patch. Ele pede para provar quais máquinas foram cobertas, em qual data, e o que aconteceu com as que ficaram de fora. “Acreditamos que a conformidade é alta” é opinião. Um registro de implantação com carimbo de data por dispositivo é evidência.
Um painel de 100% de conformidade só mede o software que alguém decidiu contar.
Não é falta de disciplina, é falta de visibilidade
A maioria das equipes de TI responsáveis por patch não é relapsa. Elas trabalham a partir de um inventário incompleto, atualizando o que conseguem enxergar e torcendo para que o resto seja pequeno demais para importar.
Raramente é. Todo notebook acumula software que ninguém registrou: instalações de teste que nunca foram removidas, ferramentas que um terceirizado deixou para trás, utilitários baixados para resolver um problema pontual em 2024 e que ainda rodam em 2026.
Coordenar “quem é dono de quê” entre segurança, operações de TI e chefes de área só funciona se existir uma lista compartilhada e atualizada para coordenar em torno dela. Sem isso, os 74% que apontam coordenação como maior desafio estão coordenando em torno de um palpite.
Fechando a lacuna, em ordem
- Inventariar antes de aplicar patch.Levantar uma lista completa e atual do software instalado em cada endpoint — não só o que a TI implantou de propósito.
- Priorizar por exposição, não por fornecedor.Um leitor de PDF pouco conhecido com um CVE público pesa mais do que um app popular com histórico limpo.
- Atribuir um dono a cada categoria.Sistema operacional, apps essenciais e software de terceiro precisam de um nome associado, não da suposição compartilhada de que outra pessoa cuida disso.
- Empurrar a partir de uma plataforma central, e depois confirmar.Uma implantação marcada só como “enviada” não é o mesmo que uma confirmada instalada em cada máquina — feche esse ciclo com um processo de distribuição de software centralizada que reporta de volta por dispositivo.
A confirmação silenciosa por dispositivo importa mais do que o envio em si. Uma ferramenta de implantação que só registra “tarefa enviada” não consegue dizer quais máquinas offline, no meio de uma atualização ou bloqueadas por política nunca receberam o patch de fato — e são exatamente essas que um invasor encontra primeiro.
Como a INGITE ajuda
Cloud Software Deployment
Empurre software, patches e atualizações para toda a frota a partir de um único console, com confirmação por dispositivo em vez de uma suposição de “tarefa enviada” — incluindo os aplicativos de terceiros que a maioria dos ciclos de patch deixa passar.
Cloud EndPoint Security
Veja quais endpoints estão realmente expostos, conecte essa visão ao status real de implantação, e transforme “acreditamos que a conformidade é alta” em um número defensável numa auditoria.
Você sabe mesmo o que ainda está sem patch na sua frota?
Antes do próximo relatório de patch sair, responda com honestidade:
- Sua política de patch lista todo aplicativo da frota, ou só os que a TI instalou?
- Você consegue apontar, agora, cada máquina que não confirmou instalação bem-sucedida no último ciclo?
- Se um app de terceiro num notebook de colaborador tivesse um CVE público hoje, você saberia que ele está lá?
- Sua lista de exceções atual está registrada, datada e com dono — ou vive na memória de alguém?
Se a resposta honesta a mais de uma dessas for “não”, o problema não é esforço. É que ninguém consegue aplicar patch em software que não enxerga.
O que é gestão de patches de aplicativos de terceiros?
Por que relatórios de patch mostram alta conformidade mesmo com vulnerabilidades em aberto?
Quantas organizações aplicam patch em aplicativos de terceiros?
Qual é o maior desafio na gestão de patches hoje?
Aplique patch no que você realmente enxerga
Uma plataforma de implantação que confirma cada instalação, em cada dispositivo, incluindo o software que ninguém lembra de ter aprovado.