A maioria dos ataques que dão certo não usa uma técnica nova. Usa uma falha que o fabricante já tinha corrigido meses antes. Segundo o relatório mais recente da Verizon sobre violações de dados, a exploração de uma vulnerabilidade de software já responde por 31% das violações registradas no mundo — pela primeira vez, à frente do roubo de senha como a porta de entrada mais comum.
A correção quase sempre já existe antes do ataque acontecer. É por isso que, nos Estados Unidos, o órgão de cibersegurança do governo (CISA) passou a exigir das agências federais um prazo de correção que varia de poucos dias a alguns meses, conforme o risco de cada falha do catálogo de vulnerabilidades que já foram usadas em ataques reais. A regra mais recente do órgão, de junho de 2026, prioriza pelo risco de cada falha — não pela ordem em que a atualização chegou.
Isso importa para quem decide numa empresa porque a conta é sempre mais barata de um lado. Aplicar a atualização custa uma janela de manutenção combinada com antecedência. Não aplicar custa um ataque que usa uma porta que já podia estar fechada — e a diferença quase nunca é técnica. É que ninguém marcou o dia, ninguém testou antes, ou ninguém quis ser a pessoa que autorizou mexer num sistema que "está funcionando".
A falha que já tinha remédio
Uma vulnerabilidade de software é uma brecha no programa que a empresa usa todo dia — um jeito de burlar a segurança que o próprio fabricante não previu. Quando ela é descoberta, o fabricante lança uma correção. A partir desse momento, a falha deixa de ser segredo: ela vira pública, documentada, e qualquer atacante pode ler exatamente o que ela permite fazer.
É esse intervalo — entre a correção existir e a correção estar instalada — que decide o resultado. O levantamento mais recente sobre ataques de sequestro de dados, feito pela empresa de segurança Sophos com 2.158 responsáveis de TI de empresas atingidas por esse tipo de ataque em 17 países, mostra que a exploração de uma vulnerabilidade foi a causa raiz de 18% dos casos no último ano — depois de liderar esse ranking por três anos seguidos, chegando a 32% no levantamento anterior.
A queda é uma notícia boa. Mas o motivo mais citado para a empresa ter sido vítima continua sendo o mesmo há dois anos seguidos: 62% dos entrevistados apontaram uma brecha de segurança conhecida ou desconhecida como o que abriu caminho para o ataque. "Conhecida" é a palavra que dói: quer dizer que alguém, em algum momento, sabia da falha — e ela continuou aberta mesmo assim.
Isso não é exclusividade de empresa grande nem de um setor específico. É o efeito de tratar "está funcionando" como sinônimo de "está seguro". Os dois não têm relação nenhuma entre si: um servidor pode rodar sem travar por anos e, ao mesmo tempo, ter uma porta aberta que o próprio fabricante já avisou para fechar.
Por que o jeito comum não resolve
O jeito comum é deixar a atualização de segurança para depois. Às vezes porque ninguém quer arriscar parar um sistema que está funcionando; às vezes porque a versão do programa do financeiro, do estoque ou da produção "não é homologada" para a versão nova, e trocar de versão parece um projeto grande demais para tratar como rotina.
O problema é que "depois" não tem data marcada. Sem alguém responsável por decidir quando e como aplicar cada atualização, ela entra numa fila que nunca anda — e o servidor que roda há três anos sem reiniciar carrega, junto com essa estabilidade, três anos de correções que nunca chegaram a ser instaladas.
A outra versão do mesmo problema é aplicar a atualização direto no sistema em uso, sem testar antes, e torcer para não dar errado. Quando dá errado uma vez — o sistema trava, um relatório para de fechar, uma integração para de funcionar —, a lição que fica é "atualização é arriscada", e a próxima passa a ser adiada com ainda mais razão. É um ciclo que se alimenta sozinho.
O que precisa existir na prática
Uma TI que trata isso como rotina, e não como emergência, se apoia em mecanismos concretos.
Um inventário de tudo o que a empresa tem rodando. Sem saber quais sistemas, servidores e programas existem — e em que versão —, não dá para saber quais deles têm uma correção disponível esperando para ser aplicada.
Prioridade por risco, não por ordem de chegada. Uma falha que já está sendo usada em ataques reais, num sistema acessível de fora da empresa, pede correção em dias. Uma falha teórica, num sistema isolado, pode esperar a próxima manutenção programada. Tratar as duas do mesmo jeito é o que faz a fila nunca andar.
Uma janela de manutenção combinada com antecedência. Em vez de aplicar a atualização de surpresa, a data é marcada, avisada e planejada para o horário de menor movimento — o que tira o medo de "vai parar o sistema sem aviso".
Teste antes de aplicar no sistema em uso. Um ambiente separado, ainda que simples, onde a atualização é testada antes de chegar ao sistema que a empresa usa todo dia, é o que separa "atualizar com segurança" de "torcer para não dar errado".
Registro de causa e solução em cada chamado. Quando um problema aparece depois de uma atualização, a próxima pessoa não perde tempo reconstruindo o que já foi resolvido uma vez.
É assim que a Skills IT trabalha: com inventário do que cada cliente tem rodando, prioridade de correção por risco e uma janela de manutenção combinada antes de qualquer atualização entrar no sistema em uso.
O ganho para a empresa
O ganho de tratar atualização como rotina não é abstrato. É menos hora de equipe apagando incêndio depois que um sistema para no meio do expediente, e menos risco de um ataque que usa uma porta que já podia estar fechada há meses.
A escala do problema, quando ele dá errado, aparece nos números do setor: o custo médio para recuperar uma empresa de um ataque de sequestro de dados — sem contar o valor de resgate, quando ele chega a ser pago — ficou em US$ 1,7 milhão por incidente no levantamento mais recente da Sophos, um aumento de 11% em relação ao ano anterior. O número não é sobre um caso isolado; é a média entre mais de duas mil empresas atingidas em 17 países.
Tem também um ganho menos visível: previsibilidade. Uma empresa que já sabe quando e como aplica cada atualização não precisa decidir isso em cima da hora, sob pressão, depois que algo já deu errado. A decisão vira calendário, não crise.
E tem o ganho de gente: quando a atualização é testada antes e avisada com antecedência, quem trabalha no sistema não é pego de surpresa, e a área de TI para de ser sinônimo de "quem trava as coisas sem avisar".
Perguntas para levar à próxima reunião
Antes de perguntar de novo "quando vamos atualizar", vale perguntar o que existe para a empresa decidir isso sem depender de sorte:
- Alguém sabe, hoje, quais sistemas têm uma atualização de segurança disponível e ainda não aplicada? Se a resposta exige ligar para alguém e perguntar, o inventário não existe de verdade.
- Existe um critério para decidir o que se corrige primeiro? Sem prioridade por risco, a fila anda pela ordem de chegada — e a falha mais perigosa pode ficar esperando atrás de uma sem importância.
- A atualização é testada antes de chegar no sistema que a empresa usa todo dia? Sem teste, cada atualização é uma aposta.
- Existe uma janela de manutenção combinada, ou cada atualização é uma surpresa? Surpresa é o que transforma manutenção de rotina em motivo de resistência.
- Se uma falha crítica for descoberta hoje num sistema da empresa, quem decide quando ela é corrigida? Se a resposta for "ninguém, ainda não pensamos nisso", esse é o primeiro problema a resolver.
