Mais rápido que o adversário: fechando a janela de exposição do código ao runtime

A janela desmoronou

Durante anos, o manual do defensor se baseou em uma aposta razoável: encontrar a falha, esperar por um patch ou uma correção e programar a atualização ou remediação. A IA quebrou essa aposta. Agora, um modelo pode ler um patch de segurança, deduzir a falha que ele corrige e produzir um exploit funcional em questão de minutos. A fraqueza subjacente é mais antiga do que a IA atual: há duas décadas, o pesquisador de segurança Halvar Flake criou o BinDiff, uma ferramenta que compara um programa antes e depois de uma correção para revelar a vulnerabilidade exata que foi remediada. Cada correção, na prática, funciona também como um mapa de ataque para todos que ainda não a aplicaram. A IA simplesmente lê esse mapa em minutos, em escala.

A mesma aceleração está remodelando a descoberta, em que a descoberta de vulnerabilidades orientada por IA está revelando falhas em softwares amplamente utilizados mais rápido do que os mantenedores conseguem responder. Ao combinar essas duas tendências, a lacuna se torna avassaladora. Hoje, um exploit costuma aparecer poucas horas depois que uma falha se torna conhecida, enquanto a implantação completa de um patch em um ambiente real ainda leva semanas. Durante quase todo esse período de espera de semanas, exceto pelas primeiras horas, um exploit funcional já está circulando enquanto a organização continua sem uma correção implementada. A exploração e a remediação agora operam em ordens de grandeza diferentes: horas versus semanas.

O tempo até a exploração foi reduzido quase a zero; portanto, qualquer estratégia baseada em vencer uma corrida de patches já está perdida.

O colapso da mediana e da média do tempo para exploração, de 2018 a 2026. Fonte dos dados: Zero Day Clock (em 19 de junho de 2026).

Duas janelas, uma corrida

Imagine duas janelas de tempo. A primeira é a janela de exploração: o tempo que um adversário precisa para transformar uma vulnerabilidade em um ataque funcional. A segunda é a janela de exposição: o tempo de que você precisa para ir da detecção de uma falha em seu próprio ambiente ao seu efetivo fechamento. Você não controla a primeira, mas controla, em grande medida, a segunda. Sofrer ou não uma violação de segurança muitas vezes se resume a uma comparação direta entre ambas.

Para vulnerabilidades conhecidas — falhas que foram divulgadas publicamente e geralmente possuem um identificador CVE e uma correção disponível — a disputa parece viável no papel. Aplique a correção e a janela se fecha. O problema é que a corrida de remediação tem um limite mínimo abaixo do qual não se consegue descer. Testar, preparar e implantar uma correção em um ambiente real leva, na melhor das hipóteses, vários dias, e o Verizon Data Breach Investigations Report de 2026 constatou que o tempo mediano para corrigir totalmente as falhas aumentou para 43 dias no ano passado, com as organizações aplicando apenas cerca de um quarto das correções do catálogo dos EUA de vulnerabilidades conhecidas por serem exploradas. Esse mesmo relatório apontou a exploração de vulnerabilidades como o vetor de entrada mais comum de invasores, superando credenciais roubadas pela primeira vez, e os analistas de resposta a incidentes da Mandiant chegaram ao mesmo veredito, com a exploração liderando como vetor de acesso inicial pelo sexto ano consecutivo.

Reduzir esses 43 dias para uma única semana seria uma conquista real, e ainda assim seria uma derrota, porque a janela de exploração é de apenas algumas horas. Para uma vulnerabilidade zero-day, a situação é ainda pior. Uma zero-day é uma falha que ainda não é pública ou que não conta com uma correção disponível, portanto, os defensores tiveram zero dias para se preparar. Simplesmente não há nada a aplicar. Essa é a armadilha escondida por trás do lema de "corrigir mais rápido": é uma medida útil para erros conhecidos, mas limitada por um piso medido em dias, e não serve de nada diante da parcela crescente de ataques que chegam antes que qualquer solução exista. Competir apenas na velocidade da remediação equivale a tentar superar uma janela que você não controla.

O caminho a seguir não consiste em abandonar a remediação, mas em ampliar o que significa fechar a janela. Você a reduz antes que o código seja enviado, prevenindo falhas de forma antecipada, e novamente em produção, bloqueando exploits em tempo de execução, em vez de confiar apenas em uma correção mais rápida depois que a falha já se tornou pública. Remediar mais rápido é algo que vale a pena fazer, mas isso, por si só, nunca poderá constituir toda a defesa.

Por que "detectar e corrigir morreu" é apenas uma meia-verdade

Um número cada vez maior de fornecedores de segurança em tempo de execução tem baseado sua proposta em uma afirmação contundente: o modelo de detectar e corrigir morreu. Considerando tudo o que as duas janelas mostram, eles não estão errados ao dizer isso. Se a exploração chega em horas enquanto suas correções levam semanas para serem implantadas, apoiar-se em um ciclo mensal de patches como defesa principal é, como os dados mostram, algo mais próximo de "teatro de segurança" do que de proteção real: uma rotina que parece responsável, mas que já não impede ataques. A conclusão honesta é que é necessária uma forma de deter um exploit em produção, no momento em que ele é executado, sem esperar que uma correção esteja disponível. Essa capacidade é real e fundamental.

O perigo está no passo seguinte que alguns dão: tratar o bloqueio em tempo de execução como substituto de tudo o que acontece antes dele. Essa é a lição errada por dois motivos.

Primeiro, um controle em tempo de execução é a última linha de defesa, não a única. Qualquer camada de detecção apresenta falsos negativos: falhas ou ataques que ela deveria ter detectado, mas não detectou. Se o bloqueio em produção é a única coisa entre um adversário e seus dados, então uma única falha se transforma em uma violação sem nada por trás; você terá apostado toda a defesa em uma única muralha.

Segundo, abandonar a prevenção deixa essa única muralha encarregada de conter uma maré crescente. A IA está gerando mais código, e mais código significa mais vulnerabilidades chegando à produção, mesmo que a taxa por linha permaneça estável. Se você deixar de tentar reduzir a quantidade de falhas enviadas, estará pedindo a uma única camada em tempo de execução que contenha uma inundação em constante crescimento, para sempre. Encontrar e corrigir problemas antes é o que impede que a água suba em primeiro lugar.

Há também uma armadilha mais silenciosa. O discurso de que "detectar e corrigir morreu" pode se distorcer em um sentimento de "então para que se preocupar em corrigir as coisas", quando, na realidade, muitas organizações já têm conhecimento de muito mais vulnerabilidades do que as que remediam. Como argumentamos em uma análise recente sobre quem é responsável por proteger o software desenvolvido por IA, o limitador costuma ser a disciplina e a atribuição de responsabilidades, não a detecção. A defesa em tempo de execução deve reforçar essa disciplina, não dar às equipes uma desculpa para abandoná-la. O slogan está apenas meio certo: o ritmo de aplicação de patches já não é uma defesa, mas a prevenção não está obsoleta. A estratégia é acrescentar uma linha de defesa em tempo de execução, não derrubar as que já estão na frente.

O que realmente significa "deter em tempo de execução"

A capacidade que esses fornecedores vendem já tem nome. Os analistas a chamam de detecção e resposta em aplicações (ADR), e ela é o membro mais recente de uma família que você provavelmente já conhece. A detecção e resposta em endpoints (EDR) monitora a máquina. A detecção e resposta na rede (NDR) supervisiona o tráfego. A detecção e resposta na nuvem (CDR) monitora a conta de nuvem. A ADR supervisiona a própria aplicação enquanto ela está em execução.

Essa última distinção é o ponto-chave, por isso vale a pena esclarecer em que a ADR difere das ferramentas que a acompanham. Um firewall de aplicações web (WAF) monitora a porta de entrada, inspecionando o tráfego no perímetro em busca de padrões maliciosos, mas não tem visibilidade do que acontece dentro da aplicação e costuma ser contornado. A EDR e a CDR observam a máquina ou a nuvem ao redor da aplicação, o que geralmente significa que detectam as consequências de um exploit — por exemplo, o início de um processo suspeito — em vez do exploit em si. O parente antigo mais próximo é a autoproteção de aplicações em tempo de execução (RASP), que de fato tentava monitorar de dentro da aplicação, mas exigia que os desenvolvedores instrumentassem seu próprio código, uma etapa invasiva que se mostrou difícil de adotar em escala, razão pela qual restam poucos produtos RASP.

A estratégia da ADR consiste em obter essa visão a partir do interior da aplicação, até o nível das funções que estão sendo executadas, sem recorrer a essa instrumentação invasiva. Muitas implementações observam o comportamento a partir do nível do sistema operacional, de modo que conseguem saber o que a aplicação está fazendo em tempo real sem tocar no código-fonte e decidir se determinada ação é legítima ou o início de um ataque.

Um exemplo prático torna isso tangível. O Log4Shell foi a falha de 2021 no Log4j, uma biblioteca de registro usada em inúmeras aplicações Java, que permitia que atacantes executassem código arbitrário simplesmente registrando uma string maliciosa. O mecanismo abusava de um recurso chamado JNDI, que normalmente realiza buscas de diretório inofensivas pela rede. Uma defesa em tempo de execução não tenta reconhecer a string maliciosa, que pode ser ofuscada indefinidamente. Em vez disso, observa o comportamento: no momento em que o componente JNDI deixa de realizar buscas legítimas e começa a buscar e executar código remoto, essa ação específica é bloqueada, enquanto o restante da biblioteca de registro continua funcionando. Nenhum patch é necessário, porque a defesa se dirige ao comportamento do exploit em vez de a uma assinatura conhecida, o que também explica por que essa abordagem pode deter uma verdadeira zero-day nunca vista antes.

No que diz respeito às duas janelas, esse é o extremo de produção da sua janela de exposição: a última linha de defesa contra aquilo que a prevenção não deteve antes que o código fosse enviado.

A IA redefine os dois lados da linha

Começamos falando de um colapso, e a IA é seu motor. As mesmas ferramentas que ajudam os defensores estão, nas mãos de pessoas mal-intencionadas, descobrindo e transformando falhas em armas em um ritmo que nenhuma equipe humana consegue igualar, seja na forma de agentes de pentest por IA ou em sistemas avançados como o Claude Mythos da Anthropic. Esse é o lado ofensivo da corrida e a razão pela qual a janela de exploração continua diminuindo. Mas a IA também faz algo mais sutil. Ela não apenas acelera ataques contra seu software; ela também se torna uma nova peça de software que você precisa defender.

As organizações estão implantando agentes de IA que leem dados, invocam ferramentas, executam código e tomam medidas por conta própria. Isso adiciona uma nova superfície de ataque que não existia há alguns anos, e ela tem duas camadas. Os próprios modelos podem ser manipulados — o campo do aprendizado de máquina adversarial — em que entradas especificamente projetadas fazem um modelo se comportar de forma incorreta. E os sistemas de agentes construídos sobre esses modelos introduzem uma camada operacional: no fundo, cada ferramenta chamada por um agente é uma chamada de função, e o tecido conectivo que expõe essas ferramentas é cada vez mais o Model Context Protocol (MCP), um padrão aberto para conectar modelos a sistemas externos.

A principal ameaça na camada do agente é a injeção indireta de prompts, em que um invasor insere instruções maliciosas em conteúdos que o agente lerá — uma página web, um documento ou um ticket de suporte — e o agente as segue como se tivessem vindo de seu operador. Quando esse agente pode executar código ou chamar ferramentas sensíveis, uma injeção bem-sucedida não produz apenas uma frase errada. Ela pode desencadear ações reais, chegando até mesmo à execução de código escolhido pelo atacante. As conexões adicionam seu próprio risco, já que os servidores MCP e suas configurações tornam-se componentes que podem ser abusados como qualquer outro.

Eis por que isso se encaixa na mesma conversa sobre defesa em tempo de execução. Uma vez que um agente age, seu comportamento é, em última instância, código sendo executado em um sistema, o que significa que uma defesa em tempo de execução faz a mesma pergunta do exemplo do Log4Shell: esta função está fazendo o que deveria fazer, ou algo a sequestrou para executar um exploit? Uma injeção de prompts que termina na execução de código malicioso pode ser detectada da mesma forma que uma chamada JNDI suspeita. E, com a mesma clareza, essa nova superfície deve ser analisada antes de ser implantada, não apenas monitorada depois, o que coloca a IA plenamente dentro do modelo que combina prevenção antecipada (shift left) e tempo de execução para o qual estamos caminhando.

A IA amplia a corrida no lado ofensivo e adiciona um novo alvo a defender, mas, como as ações de um agente se traduzem em código em execução, a pergunta em tempo de execução nunca muda: este comportamento é legítimo ou é o início de um ataque?

A resposta está em todo o ciclo de vida, não em uma única etapa

Ao juntar todas as peças, a estratégia deixa de ser uma escolha entre antecipar a segurança e defender em tempo de execução. São as duas coisas, mirando o mesmo objetivo: uma janela de exposição mais curta. Elas dividem o trabalho. À esquerda, identificam-se e corrigem-se vulnerabilidades antes que elas sejam enviadas, de modo que, para elas, a janela nunca chega a se abrir. Em produção, detectam-se, bloqueiam-se e respondem-se aos exploits que conseguem passar, fechando a janela para as falhas que a prevenção deixou escapar, inclusive aquelas sem patch aplicável. Nenhuma das duas opções, sozinha, é suficiente: a prevenção evita que as janelas se abram, e o tempo de execução fecha as que conseguem se abrir.

É também aqui que a detecção deixa de ser a parte difícil. Como já argumentamos anteriormente, a IA está tornando a descoberta de vulnerabilidades abundante e barata, o que significa que o diferencial já não é quantos problemas você consegue detectar, mas quão rapidamente consegue agir sobre eles: priorizando o que realmente apresenta riscos, remediando e verificando se a correção de fato reduziu a exposição ao risco. Esse circuito fechado, e não o volume bruto de detecção, é o que move sua janela de exposição.

Esse é o modelo para o qual a Fluid Attacks vem apontando há anos: já combinamos ferramentas automatizadas, IA e pentesters humanos para encontrar e ajudar a remediar vulnerabilidades ao longo do ciclo de vida do software, com uma plataforma única para priorizá-las e acompanhá-las até seu fechamento. Estender essa mesma filosofia ao tempo de execução, para que a prevenção e a defesa em produção compartilhem uma única visão contínua do risco, é o passo natural e a direção para a qual o AppSec como um todo está se encaminhando.

Conheça seu terreno

A frase mais citada de Sun Tzu é também a mais prática: conheça o inimigo e conheça a si mesmo, e você não precisará temer nem cem batalhas. Dedicamos este post à primeira metade: o adversário e a velocidade do ataque. A segunda metade, conhecer a si mesmo, é onde a maioria dos programas perde silenciosamente. Você não consegue encurtar a janela de exposição de uma aplicação que esqueceu que estava executando, de uma dependência que não sabia que havia implantado ou de um serviço pelo qual ninguém se responsabiliza. Eles permanecem expostos, quer você os monitore ou não.

Sun Tzu era igualmente insistente quanto ao terreno: um comandante que não conhece o território, seus desfiladeiros, pântanos e terrenos elevados, não consegue mover um exército por ele com confiança. No software, seu terreno é o inventário completo e atual daquilo que você realmente executa: aplicações, APIs, componentes e o código aberto e de terceiros que eles contêm. Sem esse mapa, a prevenção não tem para onde apontar e a defesa em tempo de execução apresenta pontos cegos por padrão. Com ele, você consegue ver onde o risco se concentra e agir primeiro, o que é precisamente a vantagem que a velocidade deveria proporcionar.

Por isso, um inventário confiável não é um elemento opcional ou secundário em um programa de segurança. É o terreno sobre o qual toda a corrida acontece. Você não consegue defender, priorizar ou superar um adversário em um terreno que não mapeou, o que torna saber o que você executa a condição prévia para qualquer outro movimento.

Vença a janela, não o patch

Não há linha de chegada nessa corrida. A janela de exploração continuará diminuindo à medida que a IA se tornar mais barata e rápida, e nenhum controle individual, por melhor que seja, a fechará de forma permanente. Isso não é motivo para desespero. É uma razão para mudar a forma como medimos o sucesso. Remediar mais rápido continuará permitindo que você vença corridas individuais, mas não pode ser a base: um exploit pode existir poucas horas depois que uma falha se torna conhecida, às vezes até antes, e uma zero-day não deixa margem para aplicar nada a tempo. Portanto, pare de medir o sucesso pela rapidez com que você aplica patches ou remedia, e comece a medir com que frequência um atacante encontra algo explorável em produção. Isso, e não a velocidade de remediação, é o que decide se você sofrerá uma violação de segurança.

Manter-se à frente significa rejeitar a falsa escolha. Previna o que for possível à esquerda, para que menos falhas cheguem à produção. Defenda em tempo de execução, para que o exploit que conseguir passar, ou a zero-day sem patch, seja detido enquanto é executado. E mapeie seu terreno primeiro, para que cada movimento tenha um alvo claro. Esse é o modelo integral, do código ao tempo de execução, sobre o qual a Fluid Attacks foi construída e que continua expandindo, porque ser mais rápido que o adversário não é um slogan; é todo o nosso trabalho.

Essa corrida agora também passa diretamente pelos seus sistemas de IA. À medida que agentes e aplicações de grandes modelos de linguagem assumem trabalho real, protegê-los se torna parte do mesmo esforço: proteger suas IAs e as aplicações de LLM e de IA generativa que você coloca em produção. Fale conosco para encurtar sua janela de exposição, do código ao tempo de execução.