Em cerca de 60% das violações, já existia uma correção disponível quando os atacantes conseguiram entrar. Essa conclusão vem do relatório de julho de 2026 da J.P. Morgan, “Patchmageddon”, e muda a questão de saber se existe uma correção para quanto tempo demora a implementá-la.
Essa janela está a encolher rapidamente. O mesmo relatório descreve ferramentas de IA capazes de fazer engenharia inversa de uma correção recém-lançada e transformá-la num exploit funcional em minutos. Cada dia em que uma correção disponível permanece por implementar é um dia em que os atacantes a podem explorar.
Para aplicações de terceiros geridas no Microsoft Intune, muitos desses dias são gastos com o empacotamento. As equipas de TI descarregam o instalador, criam o pacote, escrevem regras de deteção, testam e atribuem, e depois repetem tudo para cada aplicação e cada lançamento. O resultado é a aplicação tardia de patches que ninguém tinha planeado.
Eis a rapidez com que a janela de exploração está a fechar-se, onde o empacotamento de aplicações no Intune abranda o processo e o que é necessário para colmatar essa lacuna.
Com que rapidez os atacantes exploram agora novas vulnerabilidades
A exploração de vulnerabilidades é agora a forma mais comum de os atacantes conseguirem acesso. De acordo com o Verizon Data Breach Investigations Report de 2026, a exploração representou 31% do acesso inicial em violações, face a 20% no ano anterior.
Muitos desses ataques começam de imediato. Mais de um quarto das vulnerabilidades recém-listadas como exploradas no primeiro semestre de 2026 já estavam sob ataque no dia em que se tornaram públicas, de acordo com o Zero Day Clock.
A aplicação de patches não acompanhou o ritmo. A Verizon concluiu que as organizações demoraram, em mediana, 43 dias a corrigir totalmente vulnerabilidades conhecidas que estavam a ser exploradas, acima dos 32 dias, e que apenas cerca de um quarto delas foram totalmente corrigidas.
As vulnerabilidades antigas também continuam em jogo. Numa única semana no final de agosto de 2026, a vulnerabilidade típica visada pelos atacantes tinha sido tornada pública há quatro anos, de acordo com o Zero Day Clock.
Um ciclo de correção medido em semanas deixa as aplicações de terceiros expostas durante o período de maior risco. Uma atualização que nunca é lançada deixa-as expostas durante anos.
Porque é que os patches disponíveis ficam por aplicar
Se as correções existem, porque é que tantas continuam por implementar? Segundo o Relatório Open Source Landscape 2026 da TuxCare, 61% dos incidentes de segurança entre utilizadores empresariais de open source envolveram correções que estavam disponíveis, mas nunca foram aplicadas. As restrições de tempo de inatividade foram o motivo mais comum para os atrasos, referidas por 43% dos inquiridos.
Esse inquérito centrou-se em ambientes open source, mas as mesmas causas surgem sempre que as equipas de TI implementam atualizações:
Receio de estragar alguma coisa. Uma atualização que interrompe uma aplicação crítica para a empresa ou força um reinício não planeado torna-se um incidente por si só. Quando não foram feitos testes, esperar parece mais seguro do que implementar.
Poucas pessoas com as competências certas. Empacotar corretamente uma aplicação Win32 exige conhecimentos especializados. Quando esse conhecimento está nas mãos de uma ou duas pessoas, cada atualização fica à espera da sua disponibilidade.
Cada atualização é um projeto em si. Fornecedores terceiros lançam atualizações segundo os seus próprios calendários, e cada lançamento exige a mesma preparação antes de poder avançar. O trabalho raramente se agrupa de forma organizada, por isso a fila cresce mais depressa do que diminui.
Nenhuma prova de que os patches foram aplicados. Sem confirmação ao nível do dispositivo, a equipa de TI não consegue identificar que endpoints continuam a executar a versão vulnerável, e as falhas passam despercebidas até alguém ir procurá-las.
Onde o empacotamento de aplicações no Intune atrasa a aplicação de patches de terceiros
Embora o Intune trate bem das atualizações do Windows e do Microsoft 365, as aplicações de terceiros são mais difíceis de gerir. O Enterprise App Management da Microsoft ajuda ao disponibilizar um catálogo de aplicações Windows preparadas da Microsoft e de terceiros que o Intune consegue manter atualizadas. No entanto, o catálogo inclui apenas aplicações que a Microsoft preparou, e a Microsoft não garante que uma aplicação solicitada venha a ser adicionada.
As aplicações fora do catálogo, as aplicações personalizadas e internas, e os tenants sem Enterprise App Management continuam a seguir o processo Win32 padrão.
Para cada nova versão, esse processo costuma ser assim:
Transfira o instalador do fornecedor e confirme que é a versão e arquitetura corretas.
Encontre os comandos de instalação e desinstalação silenciosas. O Intune exige que as aplicações Win32 sejam instaladas sem interação do utilizador, por isso alguém tem de perceber que parâmetros cada instalador suporta.
Empacote o instalador como um ficheiro .intunewin com a Microsoft Win32 Content Prep Tool.
Escreva regras de deteção para que o Intune possa confirmar que a aplicação foi instalada corretamente.
Configure a substituição para que a nova versão substitua a antiga.
Teste o pacote num dispositivo suplente ou numa máquina virtual antes de chegar aos utilizadores.
Atribua a aplicação aos grupos certos.
Verifique a implementação e resolva problemas em quaisquer dispositivos que tenham falhado.
Depois, o fornecedor envia outra atualização e o ciclo recomeça. Multiplique esses passos por todas as aplicações de terceiros no ambiente e por cada nova versão que cada uma lança, e a implementação de aplicações Win32 no Intune torna-se um backlog permanente. É nesse backlog que “available” se transforma em semanas.
O que é necessário para um processo mais rápido de aplicação de patches de terceiros
O relatório da J.P. Morgan recomenda que as organizações utilizem as versões mais recentes do software e encurtem os prazos de teste e implementação de patches. No caso das aplicações de terceiros no Intune, isso resume-se a alguns requisitos operacionais:
Um inventário atualizado das aplicações de terceiros. Todas as decisões de aplicação de patches começam por saber que aplicações e versões estão em execução em que dispositivos.
Fontes de instalação fiáveis e verificadas. Obter instaladores a partir de fontes validadas reduz o risco de implementar um pacote adulterado ou malicioso.
Empacotamento automatizado. Os comandos de instalação e desinstalação silenciosas, as regras de deteção e a substituição devem ser gerados automaticamente para cada versão, sem scripts escritos manualmente.
Deteção automática de novas versões. Quando um fornecedor lança uma atualização, o novo pacote deve ser criado sem esperar que alguém repare no lançamento.
Testes automatizados e análise de segurança antes da implementação. Testar cada compilação numa máquina limpa elimina uma das principais razões pelas quais as equipas adiam as atualizações.
Implementação faseada. Implementar primeiro num grupo piloto limita o impacto caso uma atualização venha a causar problemas.
Controlos do utilizador final. Adiamentos, avisos de reinício e períodos de tolerância permitem distribuir atualizações sem interromper alguém a meio de uma tarefa.
Estado da implementação e visibilidade de auditoria. Os relatórios por dispositivo confirmam que cada patch foi realmente aplicado e deixam um registo para auditorias.
Perguntas para medir a sua janela de aplicação de patches de terceiros
Antes de alterar ferramentas ou processos, é útil saber em que ponto a sua equipa se encontra hoje. Estas perguntas mostram quão ampla é, na realidade, a sua janela de exposição:
Quantos dias passam entre a disponibilização pelo fornecedor e a atribuição no Intune das suas 10 principais aplicações de terceiros? Este número é a sua janela real de aplicação de correções e, muitas vezes, é mais longa do que as equipas esperam.
Quantas pessoas na equipa conseguem empacotar corretamente uma aplicação Win32? Se a resposta for uma ou duas, cada atualização depende da sua disponibilidade.
Quando foi a última vez que adiou uma atualização porque os testes não estavam concluídos? Atrasos frequentes indicam um estrangulamento nos testes, não no agendamento.
Consegue comprovar que uma correção chegou a todos os dispositivos? Sem confirmação por dispositivo, uma atualização que parece concluída pode ainda deixar endpoints expostos.
Como o empacotamento agêntico encurta o caminho entre a versão e a implementação
O relatório da J.P. Morgan destaca um ponto que é fácil perder de vista no meio dos alertas: as mesmas ferramentas de IA usadas para encontrar e explorar vulnerabilidades também podem ajudar a corrigi-las. O empacotamento agêntico aplica essa ideia à parte mais lenta da aplicação de patches de terceiros.
Num fluxo de trabalho de empacotamento agentic, agentes de IA assumem as etapas repetitivas do empacotamento de aplicações no Intune. Leem o instalador, determinam os comandos de instalação e desinstalação silenciosas, criam o pacote e geram a lógica de deteção. Cada compilação é depois testada numa máquina limpa, e os resultados seguem para um administrador analisar antes de qualquer publicação no Intune.
Veja o empacotamento agêntico em ação a 21 de outubro
Um patch que já existe só é tão útil quanto o tempo que demora a chegar a todos os dispositivos. No caso das aplicações de terceiros no Intune, grande parte desse tempo é gasta no empacotamento.
O empacotamento agêntico elimina o trabalho repetitivo de cada lançamento, para que as novas versões possam avançar pelos testes e para uma implementação faseada sem ficarem à espera numa fila.
A Splashtop vai realizar um webinar de 30 minutos, “From Manual to Agentic Packaging: Simplifying App Deployment with Microsoft Intune,” no dia 21 de outubro, às 8h PT / 11h ET. O Microsoft MVP Maxime Guillemin e o Head of Product da Splashtop, Brandon Shopp, vão mostrar como a IA e os fluxos de trabalho agentic reduzem o esforço e os erros de packaging, incluindo uma demonstração de agentic packaging em ação.
