Gerenciamento de patches de terceiros: por que é fundamental e como automatizar a TI

O painel de conformidade de patches indica 96%. O Windows está atualizado, o macOS está atualizado, a equipe de segurança aprova e o relatório é enviado ao auditor. O problema é que esses 96% refletem apenas a situação do sistema operacional. O terminal representado por aquele bloco verde também está executando uma versão do Chrome do final do verão, uma versão do Adobe Reader com três vulnerabilidades (CVEs) publicadas, um cliente do Zoom anterior ao último aviso de segurança e um ambiente de execução do Java que ninguém da equipe se lembrou de verificar nos últimos dezoito meses. Nada disso aparece na pontuação.

Essa é a lacuna que o gerenciamento de patches de terceiros deve preencher e, para a maioria das equipes de TI e MSPs, é a parte do programa de aplicação de patches que, discretamente, recebe financiamento insuficiente em relação ao risco real que representa. O estudo de referência empresarial da Qualys para 2026 estimou o tempo médio de correção para aplicativos complexos de terceiros em cinco meses e dez dias. Os invasores agem em um intervalo de tempo medido em dias, às vezes em horas. Os dois prazos não são compatíveis.

As soluções RMM da Kaseya gerenciam a aplicação de patches em milhões de terminais para MSPs e equipes internas de TI em todo o mundo, oferecendo uma visão operacional clara de onde os programas de aplicação de patches de terceiros se mantêm estáveis sob pressão e onde apresentam falhas. Este guia aborda o que é o gerenciamento de patches de terceiros, por que a logística é mais complexa do que a aplicação de patches no sistema operacional, o que deve ser priorizado, como estruturar o programa do ponto de vista operacional e o que a automação deve oferecer para acompanhar o ritmo de lançamento das atualizações.

O que é o gerenciamento de patches de terceiros?

O gerenciamento de patches de terceiros é a disciplina que consiste em identificar, avaliar, implantar e verificar atualizações para os softwares em execução em seus terminais que não são fornecidos pelo fabricante do sistema operacional. Trata-se de uma categoria ampla. Navegadores, leitores de PDF, clientes de videoconferência, ambientes de execução como Java e .NET, pacotes de produtividade, ferramentas de desenvolvimento, utilitários de compactação e toda a gama de aplicativos empresariais que se acumulam em qualquer ambiente ao longo do tempo.

Isso se enquadra na mesma disciplina mais ampla de gerenciamento de patches que a aplicação de patches no sistema operacional, mas opera sob restrições diferentes. A Microsoft, a Apple e as principais distribuições do Linux disponibilizam suas atualizações por meio de canais padronizados e bem estruturados. Os fornecedores terceirizados, não. Não existe uma “Patch Tuesday” para o Slack. Não há um catálogo central que vincule o cronograma de lançamentos da Adobe ao da Mozilla, ao da Oracle e ao do aplicativo de nicho específico para o setor de negócios que a equipe financeira instalou em 2019. Cada fornecedor lança atualizações em seu próprio ritmo, em seu próprio formato e por meio de seu próprio canal, e alguém precisa acompanhar todos eles ao mesmo tempo.

O termo “terceirizado” tem um papel muito importante aqui. Ele abrange desde um navegador usado por todos os usuários da empresa até uma ferramenta de engenharia com finalidade específica instalada em três máquinas. Ambos se enquadram no mesmo âmbito operacional e ambos podem servir como ponto de entrada para uma violação.

Por que a aplicação de patches de terceiros é mais importante do que nunca

Durante anos, a percepção predominante era de que as vulnerabilidades do sistema operacional eram a principal preocupação, enquanto os aplicativos representavam uma preocupação secundária. Isso já não é verdade há algum tempo. Os dados vêm, gradualmente, confirmando o que os invasores já sabiam.

A pesquisa “State of Patch Management 2025” da Adaptiva, realizada em parceria com a Demand Metric, revelou que 87% das organizações se depararam com vulnerabilidades em aplicativos de terceiros que exigiram a aplicação de patches no ano anterior. Isso não é um caso isolado. É a situação padrão de praticamente todos os ambientes de TI que executam software moderno.

O catálogo de Vulnerabilidades Exploradas Conhecidas (KEV) da CISA conta a mesma história sob outra perspectiva. A lista KEV cataloga vulnerabilidades que estão sendo ativamente utilizadas por invasores, e não apenas aquelas teóricas classificadas pelo CVSS, e uma parcela constante de novas entradas diz respeito a aplicativos de terceiros, e não aos sistemas operacionais principais. Navegadores, leitores de documentos, ferramentas de conferência e bibliotecas de tempo de execução aparecem mês após mês. Eles são amplamente utilizados, recebem atualizações de segurança com frequência, e a lacuna entre o lançamento do fornecedor e a instalação pelo usuário final é onde os invasores atuam.

O ritmo traz mais um desafio. A “Patch Tuesday” da Microsoft de abril de 2026 corrigiu 163 CVEs apenas em sua própria pilha de software. Acrescente a isso a Adobe, a Oracle, o Google, a Mozilla, a Cisco, a Atlassian e uma dúzia de outras empresas — e o volume mensal com o qual qualquer programa de correção de vulnerabilidades deve acompanhar começa a parecer realmente exaustivo. A revisão manual de um fluxo dessa magnitude não é uma estratégia.

O Relatório de Investigações sobre Vazamentos de Dados da Verizon de 2025 identificou a exploração de vulnerabilidades como o vetor de acesso inicial em 20% dos vazamentos — um aumento de 34% em relação ao ano anterior. Esse crescimento não se deve apenas a vulnerabilidades “zero-day” no nível do sistema operacional. Ele reflete a crescente utilização de vulnerabilidades em softwares de terceiros que as organizações nem sabiam que estavam utilizando ou ainda não tinham tido tempo de corrigir.

Desafios do gerenciamento de patches de terceiros

Uma vez que se sabe que o risco é real, a pergunta que surge naturalmente é: por que tantos programas deixam essa vulnerabilidade exposta mesmo assim? A resposta é de natureza técnica, não motivacional. A aplicação de patches em softwares de terceiros é estruturalmente mais difícil do que a aplicação de patches no sistema operacional por quatro razões inter-relacionadas.

Fragmentação dos fornecedores

A infraestrutura de atualizações da Microsoft lida com os softwares da própria Microsoft. A da Apple lida com o macOS. Não existe um canal unificado equivalente para os demais. Cada fornecedor independente de software (ISV) mantém seu próprio portal de lançamentos, seu próprio formato de avisos e seu próprio mecanismo de distribuição. Acompanhar manualmente os lançamentos de 50 ou 100 aplicativos de terceiros significa assinar dezenas de feeds distintos e transformar cada um deles em ação. Essa é uma função em tempo integral para a qual a maioria das equipes não dispõe de pessoal.

Variabilidade da cadência

A “Patch Tuesday” oferece um ritmo conhecido para o Windows. Os lançamentos de terceiros não seguem um padrão definido. Uma correção crítica para um navegador pode ser lançada no meio da semana. Uma atualização de tempo de execução pode ser disponibilizada sem aviso prévio. Uma ferramenta de conferência pode lançar uma versão de segurança no mesmo dia em que um fornecedor de drivers de impressora publica um CVE. O volume não é previsível e o momento de lançamento também não, o que significa que um programa de atualizações baseado em uma cadência mensal, por definição, deixará de incluir rotineiramente atualizações de terceiros que exigem ação imediata.

Diversidade de instaladores

As atualizações do sistema operacional chegam por meio de mecanismos padronizados. Os aplicativos de terceiros utilizam MSI, EXE, MSIX, App-V, atualizadores específicos de fornecedores, instaladores baseados na web e, ocasionalmente, scripts de implantação personalizados. Cada formato possui seus próprios parâmetros de instalação silenciosa, seu próprio comportamento de reinicialização, sua própria lógica de detecção de versão e seus próprios modos de falha. Automatizar de forma confiável em toda essa variedade requer ou uma ferramenta com suporte testado pelo fornecedor para cada aplicativo, ou scripts personalizados mantidos por sua equipe, indefinidamente.

Descoberta

Não é possível aplicar patches no que você nem sabe que existe. Os usuários instalam aplicativos fora dos canais aprovados pela TI. As aquisições trazem consigo conjuntos de softwares não gerenciados. Os departamentos padronizam o uso de ferramentas das quais ninguém informou à equipe de terminais. Sem uma detecção contínua, baseada em agentes, que identifique todos os aplicativos instalados e suas versões em cada dispositivo gerenciado, o programa de aplicação de patches opera com base em um inventário que já está incorreto antes mesmo de começar.

Essas quatro restrições não desaparecem com o esforço. Elas são características do próprio ecossistema de software de terceiros. Um programa que funciona é aquele que é projetado levando-as em conta, em vez de tentar contorná-las.

Quais aplicativos vale a pena priorizar em primeiro lugar?

Nem todo aplicativo de terceiros apresenta o mesmo risco — e tratá-los como uma lista genérica faz com que os programas acabem tendo a mesma exposição que se não houvesse nenhum programa. A abordagem correta é classificá-los em níveis com base na área de implantação, no histórico de exploração e na proximidade com a borda da rede; em seguida, concentrar a frequência das verificações e o SLA no nível mais alto.

Os navegadores estão no topo de quase todas as listas. O Chrome, o Edge, o Firefox e o Brave estão instalados em todos os terminais, exibem, por definição, conteúdo não confiável da internet e recebem atualizações de segurança várias vezes por mês. Além disso, costumam adiar a aplicação das atualizações até a reinicialização, o que significa que um patch disponível só é aplicado quando o usuário fecha a janela. Um SLA de 24 a 48 horas para atualizações críticas de navegadores, com cumprimento obrigatório, é uma meta básica razoável.

Em seguida, vêm os leitores de PDF e documentos. O Adobe Acrobat e o Reader apresentam um longo histórico de vulnerabilidades críticas (CVEs) e têm sido alvo, há muito tempo, de documentos maliciosos enviados por e-mail. Manter uma versão atualizada em todos os terminais é a medida mais econômica e eficaz para reduzir as taxas de sucesso das cargas de phishing disponível para a maioria das equipes.

Os ambientes de execução constituem o terceiro grupo. Java, OpenJDK, os ambientes de execução do .NET e vários motores de JavaScript servem de base para aplicativos de negócios que podem não ser visíveis às ferramentas de segurança como dependências distintas. Uma vulnerabilidade em um ambiente de execução afeta todos os aplicativos desenvolvidos com base nele, e o alcance do impacto pode ser grande, mesmo quando o próprio ambiente de execução parece pouco conhecido.

Os clientes de videoconferência e colaboração estão em um quarto nível. O Zoom, o Teams (em sua versão de instalação independente), o Slack e ferramentas semelhantes estão instalados em todos os lugares, interagem com links e arquivos externos não confiáveis e são atualizados com frequência. Sua superfície de ataque é semelhante à de um navegador, mesmo que sua visibilidade no inventário de ativos seja diferente.

Utilitários de compactação, ferramentas de arquivamento, dependências de desenvolvedores e a ampla gama de aplicativos de negócios completam o restante. Cada um deles representa uma parcela significativa do risco, e a estrutura adequada para classificá-los é o mesmo modelo baseado em risco que deve reger a aplicação de patches no sistema operacional: gravidade (CVSS), status de exploração (listagem KEV, feeds de inteligência de ameaças, exploits públicos) e contexto de negócios (exposição à Internet, dados confidenciais, potencial de movimento lateral). Para saber mais sobre como integrar essa estrutura a um programa mais amplo, consulte as práticas recomendadas para gerenciamento de patches.

Melhores práticas para a aplicação de patches de terceiros: como criar um programa

Um programa de aplicação de patches de terceiros que funcione adequadamente segue o mesmo fluxo geral do processo mais amplo de gerenciamento de patches, mas a implementação em cada etapa precisa levar em conta a complexidade adicional que o software de terceiros traz.

A descoberta deve ser contínua, orientada por agente e exaustiva. Uma auditoria semanal de software no cadastro de ativos não é suficiente. O agente deve identificar todos os aplicativos instalados, todas as versões e todas as instâncias instaladas pelos usuários em todos os terminais gerenciados, com atualizações quase em tempo real. Sempre que essa visibilidade falhar, o programa de aplicação de patches ficará cego exatamente nessa medida.

O monitoramento segue o mesmo princípio. Depois de saber o que está instalado, você precisa de um feed que informe quando cada fornecedor lança uma atualização de segurança, de preferência classificada por gravidade. Criar esse feed internamente para cinquenta fornecedores dá muito trabalho. A solução mais viável é uma ferramenta de aplicação de patches cujo fornecedor adicione novos lançamentos a um catálogo testado poucas horas após a publicação pelo fornecedor, para que a equipe utilize um único feed em vez de cinquenta.

A priorização é o ponto em que a aplicação de patches de aplicativos de terceiros mais frequentemente diverge da aplicação de patches do sistema operacional na prática operacional. A classificação por níveis de risco acima se reflete diretamente na sua estrutura de SLA, que deve estar explicitamente definida na sua política de gerenciamento de patches. Uma política que identifique os aplicativos de terceiros, os classifique em níveis de gravidade com SLAs definidos e exija exceções documentadas elimina a priorização implícita do tipo “primeiro o sistema operacional, depois os de terceiros”, que é a causa dessa lacuna.

Os testes são realmente diferentes. Os patches do sistema operacional são validados pela Microsoft, pela Apple ou pelo mantenedor do Linux em questão antes do lançamento. Os patches de terceiros são validados pelo ISV e, idealmente, pela equipe de controle de qualidade do catálogo da sua plataforma de aplicação de patches. O risco restante é a interação entre aplicativos: uma atualização do navegador que altera o comportamento de renderização e causa falhas em um aplicativo web interno, uma atualização do runtime Java que revela problemas de compatibilidade com um pacote de linha de negócios, uma versão do Teams que afeta uma integração personalizada. Um pequeno grupo piloto de terminais representativos, com uma espera de 24 a 48 horas para atualizações de rotina e um teste rápido (smoke test) para vulnerabilidades ativamente exploradas, detecta a maior parte desses problemas antes que cheguem à produção.

A implantação transfere a atualização testada para o restante do ambiente, de acordo com as janelas de manutenção definidas, com lógica de repetição de tentativa para endpoints que estavam offline na primeira tentativa e caminhos de reversão em caso de falhas. Essa é a parte do programa que apresenta falhas mais visíveis quando executada manualmente, pois o volume de trabalho consome as horas disponíveis e o tratamento de exceções sobrecarrega o trabalho de rotina.

A verificação fecha o ciclo. O indicador de conformidade que importa para você é a versão instalada, e não o status da implantação. Um relatório de implantação pode indicar “enviado”, enquanto uma falha silenciosa do instalador deixa a versão antiga no dispositivo. A verificação, por aplicativo e por dispositivo, da versão em execução é o que indica se a correção foi realmente aplicada.

A geração de relatórios deve ser feita por aplicativo, e não por dispositivo. Um dispositivo com o Chrome atualizado, mas com o Java três versões atrasado, não está em conformidade de forma alguma aceitável para um auditor. Os relatórios devem ser segmentados por aplicativo, por nível de gravidade e por violação do SLA, com os detalhamentos por cliente de que os MSPs precisam para as certificações destinadas aos clientes.

Por que o gerenciamento automatizado de patches de terceiros é essencial

A conta não bate sem isso. Cinquenta aplicativos de terceiros, dezenas de lançamentos por mês por cada grande fornecedor, centenas ou milhares de terminais, ritmos de atualização dos fornecedores que não se alinham e SLAs medidos em horas para os patches de maior risco. Nenhuma equipe vai conseguir manter tudo isso funcionando manualmente — e as que tentam acabam ficando para trás primeiro no que diz respeito ao software de terceiros, porque é aí que o custo de ficar para trás é menos visível no dia a dia.

O gerenciamento automatizado de patches libera a equipe das tarefas rotineiras: detectar que um aplicativo precisa de uma atualização, baixar o pacote testado do catálogo, fazer a implantação por meio de instalação silenciosa durante a janela de manutenção acordada, lidar com reinicializações e repetir tentativas em caso de falhas. Os profissionais continuam envolvidos no tratamento de exceções, nas aprovações das janelas de mudança para sistemas sensíveis e na pequena porcentagem de aplicativos que realmente exigem intervenção manual.

Vale a pena destacar dois aspectos específicos da automação de terceiros, pois eles não recebem atenção suficiente no debate mais amplo sobre automação.

O primeiro é a qualidade do catálogo. A automação só é tão boa quanto o catálogo de aplicativos que a alimenta. Uma plataforma que leva duas semanas para empacotar uma atualização crítica do navegador tem, durante esse intervalo, o mesmo valor de segurança que a ausência total de uma plataforma. As perguntas que vale a pena fazer ao avaliar qualquer recurso de aplicação de patches de terceiros são: quantos aplicativos são suportados de fábrica, com que rapidez o catálogo reflete novos lançamentos dos fornecedores (especialmente para atualizações de segurança) e qual processo de controle de qualidade é aplicado a cada pacote antes que ele chegue aos terminais de produção?

O segundo é a superfície de dependência. Um patch inadequado do sistema operacional tende a causar falhas no sistema operacional. Um patch de terceiros defeituoso tende a causar falhas no aplicativo que depende dele, o que pode afetar um fluxo de trabalho específico da empresa, uma integração ou uma ferramenta de produtividade utilizada por toda a empresa. A mitigação é a mesma de qualquer programa de aplicação de patches — anéis de implantação, períodos de espera e reversão automatizada. No entanto, a tolerância operacional à falha é menor, pois os usuários percebem uma falha no Adobe Reader mais rapidamente do que percebem uma atualização do kernel.

A perspectiva da conformidade

As estruturas de conformidade deixaram de fingir que o software de terceiros é uma questão à parte. O Requisito 6.3.3 da PCI DSS 4.0 abrange todos os componentes do sistema, o que inclui aplicativos, e não apenas sistemas operacionais. O Anexo A, seção 8.8, da ISO 27001:2022 trata da gestão de vulnerabilidades técnicas sem exceções. A Regra de Segurança da HIPAA tem sido interpretada em ações de fiscalização de forma a abranger a aplicação de patches em aplicativos como parte de medidas de proteção “razoáveis e apropriadas”. A NIS2, em vigor em todos os Estados-membros da UE, exige comprovação do tratamento oportuno de vulnerabilidades, sem distinguir entre sistema operacional e aplicativo. O Critério CC7.1 dos Serviços de Confiança do SOC 2 abrange o monitoramento e a correção de novas vulnerabilidades em todo o sistema.

A implicação prática é a mesma em todos os casos. Uma auditoria que analise seu programa de aplicação de patches e identifique navegadores não gerenciados, leitores de PDF sem patches ou ambientes de execução do Java em fim de vida útil resultará em constatações, independentemente de quão impecável pareça seu relatório de conformidade do Windows. A defesa contra essa constatação são as evidências operacionais: relatórios de conformidade por aplicativo, registros de implantação datados, exceções documentadas e SLAs cumpridos na prática, e não apenas no papel.

Como a Kaseya simplifica a aplicação de patches de terceiros

A aplicação de patches de terceiros não é uma questão de conhecimento. Toda equipe de TI e todo MSP sabem que os aplicativos precisam receber patches. Trata-se de um problema operacional, e esse problema operacional é estrutural: mais fornecedores, mais frequências de atualização, mais formatos de instaladores, maior área de detecção e um fluxo de trabalho padrão que prioriza a aplicação de patches no sistema operacional, pois isso é mais fácil de monitorar.

A maneira de resolver isso é deixar de tratar o catálogo de terceiros como um programa paralelo e integrá-lo à mesma estrutura do trabalho que já está em execução. Mesmo inventário. Mesma classificação de riscos. Mesmos SLAs na política. Mesmos anéis de implantação. Mesma automação. Mesmos relatórios de conformidade por aplicativo. As ferramentas subjacentes devem oferecer suporte a um catálogo de terceiros testado, acompanhando o ritmo de lançamento real dos fornecedores, mas o projeto do programa não é um programa diferente. É o mesmo programa, com escopo completo.

Esse princípio de design é a base sobre a qual as soluções RMM da Kaseya são construídas: a aplicação de patches no sistema operacional, em softwares de terceiros e no firmware é realizada por meio de um único agente, uma única estrutura de políticas, um único conjunto de janelas de manutenção e uma única visão de conformidade. O módulo de Gerenciamento Avançado de Software do Datto RMMé o recurso de terceiros mencionado, ampliando a cobertura de patches para mais de 200 aplicativos prontos para uso, com um catálogo testado em milhões de dispositivos antes do lançamento e em constante crescimento.

O módulo também oferece suporte à instalação e desinstalação de aplicativos por meio da mesma estrutura de políticas, o que preenche uma lacuna que a maioria das ferramentas de aplicação de patches deixa em aberto: aplicativos em fim de vida útil que precisam ser removidos, e não apenas atualizados, antes que sejam explorados. Para os MSPs, isso se traduz em configuração de políticas e relatórios de conformidade por cliente a partir de um único console. Para as equipes internas de TI, trata-se de uma visão unificada do estado das atualizações do sistema operacional e de terceiros, com a trilha de auditoria exigida pelas estruturas de conformidade, gerada como um subproduto do fluxo de trabalho, em vez de um exercício trimestral de coleta de evidências.

A alternativa é deixar uma superfície de ataque documentada exposta, enquanto o painel de atualizações do sistema operacional permanece no verde. Essa é exatamente a brecha da qual os invasores se valem — e os dados atuais sobre explorações sugerem que eles estão certos nisso.