Relatório da Azul sobre a lacuna de vulnerabilidades de IA em 2026 constata que as empresas estão ficando para trás na aplicação de correções diante das ameaças de IA

O Relatório de 2026 sobre a lacuna de vulnerabilidades de IA da Azul constata um descompasso entre a velocidade que os líderes de segurança atribuem aos atacantes equipados com IA e o tempo de que suas organizações precisam para aplicar correções. Em uma pesquisa com 300 líderes de segurança dos EUA, 69% disseram que os atacantes poderiam criar um exploit funcional em até três dias, enquanto 44% afirmaram que suas organizações precisam de quatro dias ou mais para corrigir uma vulnerabilidade crítica em todo o ambiente de produção.

A constatação mais marcante do relatório é a experiência que os entrevistados associam a esses atrasos: 85% relataram um incidente, um possível incidente ou um quase incidente atribuível à demora na aplicação de correções. Esse número descreve experiências relatadas, não uma taxa de violações verificada de forma independente — e não comprova que a IA tenha causado esses eventos.

Encomendado pela Azul e realizado pela Censuswide, o estudo se concentra em organizações com ampla implantação de Java. Sua mensagem mais abrangente é operacional: identificar uma vulnerabilidade é apenas o começo. Uma correção precisa passar pelos testes, chegar aos sistemas afetados e eliminar a exposição em todo um parque cuja extensão talvez não seja totalmente conhecida pelas equipes.

Dois relógios que não estão sincronizados

A pesquisa distingue as expectativas dos líderes em relação aos atacantes das capacidades de implantação de suas próprias organizações:

• 69% acreditam que atacantes equipados com IA conseguem criar um exploit em até três dias, incluindo 22% que estimam esse prazo em menos de 24 horas.
• 56% afirmam que conseguem implantar uma correção crítica em todo o ambiente de produção em até três dias: 13% em menos de 24 horas e 43% em um a três dias.
• 44% precisam de mais tempo: 32% levam de quatro a seis dias e 12% precisam de ainda mais tempo.

Esses números representam a distribuição das respostas à pesquisa, não medições de atacantes competindo com organizações específicas em relação às mesmas vulnerabilidades. A diferença justifica preocupações com o nível de preparação, mas não deve ser interpretada como uma janela de exposição precisa de três dias para todas as empresas.

No limite de um dia, observa-se o mesmo desequilíbrio: 22% esperam que os atacantes ajam com essa rapidez, contra 13% que afirmam que sua organização consegue implantar uma correção nesse prazo. Enquanto isso, 59% reconhecem que as ferramentas de ataque com IA aumentam a exposição, mas não mudaram sua postura de segurança.

Os testes são uma parte importante do atraso

Os testes de atualizações do ambiente de execução Java acrescentam quatro dias ou mais ao ciclo de aplicação de correções em 58% das organizações pesquisadas. Isso inclui 36% que relatam de quatro a seis dias e 22% que relatam uma semana ou mais. Outros 33% informam que levam de um a três dias, e 9%, menos de 24 horas. Nenhum entrevistado afirmou que os testes foram dispensados.

Alterações no ambiente de execução podem afetar muitos aplicativos, por isso os testes têm uma finalidade prática: uma atualização de segurança que interrompa um serviço crítico cria outro problema operacional. O relatório argumenta que o escopo das atualizações contribui para essa carga, pois as versões trimestrais completas do OpenJDK podem incluir alterações que não são de segurança junto com as correções de vulnerabilidades.

Separadamente, a Azul avaliou 26 atualizações trimestrais do OpenJDK ao longo de mais de seis anos e classificou seis como causadoras de uma regressão grave. Esse índice de 23% corresponde à avaliação das versões pelo fornecedor, não a uma estimativa baseada em pesquisa sobre a frequência com que o aplicativo de um cliente específico pode apresentar falhas.

Entre os principais obstáculos relatados à aplicação mais rápida de correções, 44% mencionam testes extensivos, 40%, a complexidade ou a idade dos sistemas afetados, e 36%, a visibilidade limitada das vulnerabilidades conhecidas. Atrasos nas correções dos fornecedores foram mencionados por 25%. Esse padrão indica que grande parte do desafio de remediação está no próprio processo de implantação das empresas.

Relatos de incidentes e lacunas no inventário exigem interpretações distintas

Cinquenta e cinco por cento relatam um incidente confirmado atribuível à demora na aplicação de correções, e 53% relatam um quase incidente. Os entrevistados podiam selecionar várias respostas, portanto esses números se sobrepõem e não devem ser somados. O índice mais abrangente de 85% destacado no relatório também inclui possíveis incidentes.

A pesquisa não comprova que todos esses eventos envolveram vulnerabilidades do Java. Os participantes trabalham em organizações com uso intensivo de Java, mas o estudo inclui perguntas sobre a aplicação de correções de software em geral, além de perguntas específicas sobre ambientes de execução Java.

O inventário é outro desafio. Apenas 19% afirmam que pelo menos 90% do parque de ambientes de execução Java em produção está no nível mais recente de correções de segurança. Isso significa que 81% ficam abaixo desse limite; não significa que 81% não tenham ambientes de execução atualizados. Cerca de uma em cada cinco organizações afirma que metade ou menos do parque está atualizado.

Separadamente, 51% reconhecem ter visibilidade parcial ou limitada dos ambientes de execução Java críticos, incluindo instâncias incorporadas, legadas e não gerenciadas. Encontrar um ambiente de execução vulnerável dentro de um aplicativo empacotado ou contêiner pode ser mais difícil do que identificar uma instalação gerenciada centralmente. Uma correção não consegue eliminar a exposição em um sistema que o processo de implantação nunca alcança.

O que a tecnologia da Azul acrescenta à discussão

A oferta de atualizações de segurança da Azul limita determinadas versões a correções de segurança em uma base OpenJDK previamente estabilizada. A empresa oferece atualizações trimestrais, mensais direcionadas e fora do ciclo regular, com o objetivo de reduzir a quantidade de mudanças não relacionadas que as empresas precisam avaliar ao implantar uma correção urgente.

Essa é uma intervenção técnica mais restrita do que eliminar a necessidade de controle de mudanças. Limitar as alterações no código pode reduzir o escopo da validação, mas as verificações específicas de cada aplicação, a responsabilidade pela implantação e a preparação para reversões continuam sendo importantes. A Azul patrocina o relatório e vende produtos voltados aos problemas que ele mede.

As ferramentas de inventário Java e de vulnerabilidades da empresa abordam o outro lado do fluxo de trabalho: identificar ambientes de execução, versões e exposição, para que uma nova divulgação de vulnerabilidade possa ser associada aos sistemas afetados. O relatório não apresenta uma comparação controlada que demonstre quanto as organizações pesquisadas melhorariam com a adoção desses produtos.

“Nossa pesquisa mostra que os líderes de segurança entendem a ameaça: a conscientização já não é o problema; a execução é”, afirmou Scott Sellers, cofundador e CEO da Azul.

Transformar a intenção de aplicar correções em um processo mensurável

Para o próximo ano, 32% apontam a aplicação de correções com mais rapidez e frequência como sua principal estratégia para reduzir a exposição, enquanto 26% preferem um inventário melhor de software e ambientes de execução. Outros 17% priorizam a detecção e a resposta, em vez de aplicar correções mais rapidamente.

A pesquisa sugere acompanhar todo o percurso, da divulgação à correção: quais sistemas são afetados, quem é responsável por eles, quais testes são necessários e se a correção realmente chegou à produção. Um prazo só é útil quando as equipes conseguem verificar a conclusão em todo o ambiente relevante.

Os resultados dos EUA vêm de um trabalho de campo realizado de 3 a 7 de agosto de 2026 com líderes de segurança de organizações com pelo menos 1.000 funcionários e uso significativo de Java/JVM em produção. São respostas autodeclaradas de uma população definida, e não um censo de empresas nem uma medição direta do desenvolvimento de exploits.

O Relatório sobre a lacuna de vulnerabilidades de IA de 2026 completo detalha as conclusões e a metodologia. Sua implicação mais clara é que a velocidade de aplicação de correções e a visibilidade dos ambientes de execução precisam melhorar em conjunto: uma correção rápida tem valor limitado se a organização não consegue identificar todas as implantações afetadas nem confirmar que a atualização chegou a elas.