A Corrida Armamentista da IA: Como LLMs Introduzem Vulnerabilidades no Código e Como Outros LLMs as Encontram

512K+ Alcance em 30 dias RUVDS.com 3.372,08 Classificação 149.079 Inscritos Inscrever-se rRenegat 1 hora atrás A Corrida Armamentista da IA: Como LLMs Introduzem Vulnerabilidades no Código e Como Outros LLMs as Encontram Média 12 min 3.4K Blog da empresa RUVDS.com Inteligência Artificial Aprendizado de Máquina * Segurança da Informação * Programação * Visão geral Seu agente de IA acabou de emitir uma linha. E parece… suspeito? Um ponteiro sem verificação para NULL , serialização via pickle sem validação e lógica de banco de dados não protegida contra injeções de SQL. É fácil notar uma ou duas dessas armadilhas, mas e se houver mais de 5 mil linhas? E quantos colegas clicaram em Aprovado sem a devida atenção? O problema não é nem mesmo que a IA pode errar, mas que ela faz isso com confiança e em escala industrial. Auditorias de segurança e revisões de código costumavam procurar uma agulha em um palheiro, mas com a velocidade atual de escrita de código com a ajuda de agentes de IA e a quantidade de linhas que precisam ser verificadas, o monte de palha clássico se tornou palha em uma esteira de alta velocidade. As agulhas não foram a lugar nenhum, elas ainda estão na palha, que agora está se movendo. A ironia da situação é que a ferramenta capaz de desmontar essa montanha de lixo potencialmente vulnerável acaba sendo a mesma inteligência artificial. Por que vasculhar a palha com as mãos se você pode colocar um ímã? Palha e ímãs agora estão competindo na corrida armamentista de IA no código . Por um lado, LLMs que geram vulnerabilidades com velocidade incrível e consistência de ferro. E, por outro lado, LLMs que procuram essas vulnerabilidades. E ambos podem ser produtos das mesmas empresas. Engraçado, não é? A escala da catástrofe: não “pode ser”, mas “provavelmente” O tema da segurança do código de IA não é novo. Um grupo de pesquisadores liderado por Pierce publicou um artigo em 2022 “Adormecido no Teclado? Avaliando a Segurança das Contribuições de Código do GitHub Copilot” , onde testou o Copilot em 89 cenários relevantes para CWE Top 25. Como o modelo foi treinado em código aberto do GitHub contendo erros, ele inevitavelmente adota padrões inseguros. Para análise, os autores criaram 89 cenários , que levaram à geração de 1689 programas . Como resultado: 40% do código gerado é vulnerável . “C” se saiu pior - 50,29% de falhas. Python - 38,35%. Foi revelado que se um código vulnerável já estivesse presente no arquivo, a probabilidade de o Copilot oferecer uma nova função vulnerável aumentava drasticamente. Ou seja, bugs geraram novos bugs, que então geraram novos bugs, e assim por diante. Poderia-se atribuir tudo ao antigo modelo da era dos dinossauros (no momento da pesquisa, o Copilot estava funcionando na família de modelos OpenAI Codex, que são descendentes do modelo GPT-3 , especialmente treinado em código de repositórios GitHub). Mas em 2023, foi realizada uma replicação da pesquisa. O objetivo dos autores era verificar como a segurança do GitHub Copilot melhorou com o lançamento de novas versões do modelo e atualizações de segurança do GitHub. Os autores se concentraram em replicar a pesquisa anterior, limitando a área de análise à linguagem Python . E sim, ficou melhor, mas não muito: a porcentagem de propostas de código vulneráveis diminuiu para 27,25% . Quase um terço do código ainda está cheio de buracos. A coisa mais engraçada é que, em alguns cenários, a nova versão do Copilot ofereceu mais vulnerabilidades do que a antiga. Mas tudo isso é lirismo e dados desatualizados. Agora - mais recente. O relatório Veracode de 2025 testou mais de 100 LLMs em quatro idiomas. Este relatório se concentra em avaliar a segurança do código gerado por IA em resposta a tarefas específicas sem especificar parâmetros de segurança. Neste ponto, o código de IA deixou de ser exótico e se tornou parte do desenvolvimento diário. A segurança do código criado por IA foi investigada para 80 tarefas típicas em quatro idiomas Java, JavaScript, C#, Python, relacionadas a quatro tipos de vulnerabilidades: injeção de SQL, XSS, injeção de log e criptografia insegura. Resultado: 45% do código é vulnerável . Java falhou com estrondo - apenas 28,5% dos fragmentos gerados não continham problemas. No estudo, os autores associam isso ao fato de que Java tem uma longa história como uma linguagem de desenvolvimento do lado do servidor, e ela surgiu antes que a injeção de SQL fosse reconhecida como uma ameaça séria. Portanto, a amostra de treinamento para Java contém muito mais exemplos com vulnerabilidades do que para outras linguagens mais modernas. Não fui eu quem inventou isso, o trabalho original diz isso Texto original. Trecho. Nós acreditamos que isso reflete novamente a natureza dos dados de treinamento. Java tem uma longa história como uma implementação do lado do servidor linguagem, e precede o reconhecimento de injeção de SQL como uma vulnerabilidade. A IA em geral lidou bem com injeções de SQL (80,4% de código seguro), mas extremamente mal - com XSS (13,5%) e Injeção de Log (12%) Foi descoberto que tamanho não importa (ufa, pelo menos aqui). O aumento do número de parâmetros do modelo (de <20B para >100 B) praticamente não afeta a segurança do código gerado. E como é a imagem em projetos reais? Essa informação também existe. Pesquisa Código de IA na Natureza é dedicado ao estudo da presença real e da influência do código criado por IA em projetos abertos. Os autores analisaram commits de 1.000 dos maiores repositórios do GitHub de 2022 a 2025, bem como mais de 7.000 alterações de código relacionadas a recentes vulnerabilidades CVE . Para isso, foi criado um sistema de detecção especial (Cascade-Aggregation Framework) para distinguir o código de IA do código humano. (IA que procura IA. A mesma palha e agulhas, só que de perfil). O código gerado por IA já representa uma parte significativa do volume total de novo código, mas sua introdução ainda é estruturada. A IA se concentra no código de cola (o chamado glue code), testes, refatoração, documentação e outro código de modelo, enquanto a lógica principal e as configurações críticas para a segurança ainda são escritas principalmente por pessoas. Foi notado que algumas famílias CWE são encontradas desproporcionalmente frequentemente no código marcado como gerado por IA. Ou seja, padrões de código inseguros quase idênticos são repetidos em projetos completamente diferentes devido ao uso dos mesmos modelos durante a geração. Vulnerabilidades introduzidas por IA, em 86,8% dos casos estão relacionados a ataques de rede , o que é maior do que em humanos (80,8%). Além disso, o nível de introdução de IA em Java (25,45%) e C (27,33%) é notavelmente menor do que em TypeScript ou C#, devido aos rigorosos requisitos de estabilidade do sistema. Além disso, como você já entendeu de estudos anteriores, em linguagens de programação “antigas”, a IA falha com muito mais frequência. Mas há também uma boa tendência. Embora a IA introduza vulnerabilidades, ela também ajuda a corrigi-las. Para uma demonstração visual, o estudo tem gráficos semelhantes: Os gráficos refletem a essência da “corrida armamentista de IA” de 2022 a 2025. Em resumo: Gráfico A (Volume de trabalho): A área sombreada mostra a proporção de código de IA em projetos. Vê-se que em 2022, a proporção de IA era de cerca de 65%. E em julho de 2025, as redes neurais escrevem cerca de 50% do código. Gráfico B (Ataque vs. Defesa): A linha vermelha mostra com que frequência a IA cria vulnerabilidades, a verde - com que frequência ela ajuda a corrigi-las. O fato de a linha verde estar acima significa que, globalmente, a IA corrige mais bugs do que introduz. E a subida acentuada da curva verde em 2025 é o momento do lançamento de uma nova geração de agentes de IA autônomos, que começaram a detectar e corrigir falhas em massa. Gráfico C (Criticidade dos erros): Compara a gravidade dos bugs de acordo com o padrão CVSS. A linha contínua - IA e a linha pontilhada - uma pessoa vão quase lado a lado no nível de 7-7,5 pontos. No estudo, isso é interpretado como as redes neurais fazendo as mesmas vulnerabilidades perigosas e críticas que os programadores vivos, e não apenas pequenas deficiências. Também são destacadas 3 fases de interação entre IA e humanos. Fase 1: Assistente de IA. Começou com o lançamento em massa do GitHub Copilot. Esta é a fase de experimentos em massa, quando os desenvolvedores começaram a alimentar as redes neurais com tudo. Fase 2: Desenvolvimento conjunto. Período de equilíbrio. O efeito uau passou, a IA se tornou uma ferramenta familiar e os desenvolvedores aprenderam a trabalhar com ela. Uma paradigma foi construído: a IA escreve um rascunho - uma pessoa verifica. Fase 3: Agentes de IA autônomos. Um momento de transição associado ao aparecimento de agentes LLM avançados, capazes de analisar código, construir gráficos de chamadas e escrever patches de forma autônoma. Para mim, notei o momento em que, a julgar pelo gráfico (b), na terceira fase, os desenvolvedores tiraram as mãos do volante e entregaram o controle aos agentes de IA, com isso o indicador de bugs começou a crescer e quase atingiu o nível de 2022. Mas vale a pena notar que a detecção de bugs se tornou muito melhor. Há mais correções de bugs antigos do que a criação de novos. A rede neural não pensa E segue modelos. Este é o principal problema dos LLMs modernos - sua fundamental incapacidade de análise lógica profunda, que os pesquisadores chamam de “efeito papagaio”. GPT-4o falhou em uma tarefa elementar para determinar o tamanho do buffer. Quando uma letra (G) foi removida deliberadamente do alfabeto padrão no prompt, a IA em 58,4% dos casos teimosamente emitiu um tamanho de 26 em vez de 25, apenas seguindo o padrão aprendido e ignorando o contexto real. Com criptografia, também houve problemas. A implementação do algoritmo SHA-1 gerada por IA foi compilada com sucesso, mas emitiu valores de hash incorretos para quaisquer dados de entrada. Se uma pessoa não verificar intencionalmente o código quanto à adequação, o erro pode passar despercebido e chegar à produção. A situação piora ainda mais quando o desenvolvedor entra em um diálogo iterativo com a rede neural, tentando refinar o código. Pesquisa do processo de múltiplas edições revelou o “paradoxo da degradação”: a segurança do código cai rapidamente à medida que ele é “melhorado”. Em apenas cinco iterações a quantidade de vulnerabilidades críticas em arquivos inicialmente seguros aumenta em 37,6% . A estratégia mais destrutiva foi a tentativa de otimizar o desempenho - em 42,7% dos casos a busca da IA para tornar o código mais rápido levou a erros de memória fatais, como buffer overflow ou use-after-free . Em 2026, pouca coisa mudou Porque o problema não é a falta de conhecimento , mas na arquitetura. Foi estabelecido que os modelos “sabem” como escrever com segurança, na fase de revisão de código, eles encontram erros, mas suprimem esse conhecimento no processo de geração para cumprir o formato ou brevidade (o chamado Format-Reliability Gap). Por exemplo, Llama-3.1-8 B-Instruct em 90% dos testes de revisão de código marca corretamente a função sprintf como perigosa e recomenda o uso de sNprintf . No entanto, em 93% dos casos de geração de código, o mesmo modelo usa sprintf auto-adverso (adversarial) geração de código. Essa falha está relacionada à execução da tarefa em condições de requisitos conflitantes, e não à falta de conhecimento: quando os prompts incluem requisitos de formatação ou restrições estruturais, o modelo prioriza a conformidade com o formato, e não o raciocínio sobre segurança. Olhe para a imagem. Eixo vertical esquerdo (Precisão da Sonda %): Mostra a precisão do trabalho de “sondas” especiais (classificadores lineares) que tentam encontrar sinais de segurança nas camadas internas do modelo. Linha azul contínua (Sonda de Contexto): Mostra que já na 0ª camada o modelo distingue 100% o contexto seguro do inseguro. Linha azul tracejada (Sonda Comportamental): Com uma precisão de 91,9%, prevê a escolha final do modelo (código seguro ou inseguro) por seus estados internos, mesmo antes que o código seja escrito. Eixo vertical direito ( ): Mostra a probabilidade real de um “token seguro” aparecer na saída do modelo, medido pelos métodos Logit Lens e Tuned Lens. Linhas vermelhas (Lente Logit/Afinada): Permanecem praticamente no nível zero (cerca de 0,15%) ao longo de quase toda a rede (camadas 0–30) e aumentam drasticamente para 37–42% apenas na camada final 31 Os autores realizaram uma análise da saída por camadas. Eles projetaram o fluxo residual (residual stream) de cada camada através da matriz de desembutimento para olhar para a distribuição de probabilidade para a função sNprintf . A probabilidade permanece abaixo de 0,01% da camada 0 à camada 28, sobe para 0,15% na camada 30 e, em seguida, salta para 36,9% na camada 31: um aumento de 250 vezes em uma etapa. Para os curiosos A propósito, você pode aprender muitas coisas interessantes sobre embeddings de meu artigo . O conhecimento sobre segurança é codificado, começando com a 0ª camada. Ao longo de quase toda a profundidade da rede, esse conhecimento permanece “computacionalmente inerte”. O modelo carrega esse conhecimento dentro de si, mas ele não afeta a previsão do próximo token. Nesse momento, a rede neural está ocupada planejando a sintaxe e cumprindo as instruções de formato (“escreva brevemente”, “apenas a implementação”). Somente na última camada, a probabilidade de escolher uma função segura aumenta repentinamente 250 vezes. A descoberta prova que as redes neurais cometem erros não por causa de estupidez ou falta de treinamento, mas por causa da supressão arquitetônica do conhecimento . O que isso significa na prática? Como o conhecimento sobre segurança está fisicamente presente no modelo, ele não precisa ser retreinado (o que é caro e repleto de esquecimento de outras habilidades). Os pesquisadores propuseram um método de “intervenção cirúrgica” : adicionar vetores de controle (os chamados steering vectors) precisamente na 31ª camada. Essa ação pontual permite que você use o conhecimento oculto do modelo e reduz o número de vulnerabilidades em 74% com quase zero atrasos no trabalho LLMs contra-atacam: IA procura vulnerabilidades no código Tudo bem, chega de coisas ruins. Porque a mesma tecnologia que gera buracos também os tapa. E aqui começa a parte mais interessante. 2026 nos encontrou com a notícia de que a empresa Anthropic criou uma arma cibernética na pessoa do modelo Claude Mythos . A rede neural mostrou uma capacidade assustadora de criar autonomamente cadeias complexas de exploits. Durante os testes, o modelo conseguiu descobrir e explorar de forma independente vulnerabilidades de dia zero em todos os principais sistemas operacionais e navegadores. O que antes exigia semanas de trabalho de especialistas de classe mundial, agora é feito pela IA em poucas horas e custa menos de US$ 1.000 por API. O modelo encontra erros que permaneceram despercebidos por décadas: por exemplo, uma vulnerabilidade de 27 anos em OpenBSD , um sistema conhecido por sua segurança. E outra brecha de 16 anos na biblioteca de mídia FFmpeg. Claude Mythos não está planejado para ser disponibilizado ao público em geral e a licença foi emitida para uso por um número limitado de empresas. A era em que as redes neurais eram apenas assistentes na escrita de código acabou oficialmente. Entramos na fase de auditoria de agência, onde a IA assume o papel de um especialista em segurança em toda a regra. Quando uma série de ataques cibernéticos é realizada em seu aplicativo da web com gatinhos, iniciada por uma inteligência artificial sedenta por sangue e bugs, fica claro - você não está mais no topo da cadeia de segurança cibernética. As forças humanas não serão suficientes para lidar com tal monstro sob nenhuma circunstância. (Somente se você encher seus data centers com água, caso contrário, nenhuma chance) Para que seu código seja durável, ele terá que ser entregue à inteligência artificial para bombeamento. Projeto TitanCA , que resultou da colaboração entre a Singapore Management University e a agência GovTech, representa um novo padrão na detecção de ameaças. A principal característica arquitetônica deste sistema é a orquestração de agentes especializados, o que é muito mais eficaz do que escalar um único modelo monolítico. Quatro módulos, cada um afiado para sua própria etapa: planejamento, navegação de código, análise, validação de descobertas. Matcher (VulCoCo): Um módulo de IA que procura “clones” de vulnerabilidades já conhecidas em um enorme banco de dados contendo cerca de 40.000 amostras. Ele maximiza a cobertura, identificando até mesmo semelhanças superficiais. Filtro (R2 Vul): Este agente é treinado para distinguir raciocínio fundamentado de alucinações lógicas. Ele constrói uma cadeia de inferências, provando por que o código pode ser perigoso. Inspetor (VulTrial): A etapa mais inovadora, usando a metáfora de um processo judicial . Aqui, um conselho de quatro agentes é convocado: o “Especialista em Segurança” apresenta evidências de culpa do código, o “Autor do Código” defende sua decisão, o “Moderador” resume a disputa e o “Conselho de Revisores” emite um veredicto final. Adaptador (PairVul): O toque final, permitindo que o sistema se adapte aos idiomas e estruturas específicos de uma organização específica, aprendendo com seus erros. Como resultado, após analisar mais de 127.000 repositórios GitHub , temos 203 vulnerabilidades de dia zero confirmadas , o que levou à publicação de 118 novos CVE. 35% das descobertas são críticas, 91% são de baixa complexidade de ataque. Ou seja, você não precisa de muita inteligência para usá-los. A OpenAI não fica para trás. Apresentado Aardvark - um agente de pesquisa de IA para encontrar vulnerabilidades com base no GPT-5. Aardvark é integrado diretamente no pipeline de desenvolvimento CI/CD. Funciona de acordo com o seguinte algoritmo: Construindo um modelo de ameaças: O agente analisa todo o repositório para entender a arquitetura do projeto e o que ele está tentando proteger. Verificação contínua: Ele rastreia cada novo commit, comparando as alterações com o modelo de ameaças e o histórico do projeto. Validação em uma sandbox: Depois de detectar uma área suspeita, Aardvark tenta reproduzir a exploração da vulnerabilidade em um ambiente isolado . Isso reduz muito o nível de ruído e falsos positivos que as ferramentas tradicionais sofrem. Patching automático: Depois de confirmar a ameaça, o agente, usando os recursos do OpenAI Codex, oferece uma correção pronta. O desenvolvedor só precisa aprovar o patch com um clique Durante os testes de benchmark, Aardvark identificou com sucesso 92% das vulnerabilidades conhecidas e sintéticas . Sim, a mesma empresa cujos modelos geram código vulnerável, agora venderá uma ferramenta para verificá-lo. Aardvark está atualmente em fase de teste beta fechado. Ferramentas que podem ser aplicadas hoje Para aqueles que estão ansiosos para procurar vulnerabilidades, compilei uma lista de soluções que já estão disponíveis para uso. garak — um scanner de vulnerabilidade LLM de código aberto da NVIDIA. Ele não é tão afiado para código de IA quanto para red-teaming dos próprios modelos generativos. Uma enorme base de testes. Ele verifica o modelo quanto a alucinações, invasões de prompts do sistema e vazamento de dados. SecurePilot — um scanner gratuito para código gerado por IA. Ele se posiciona como uma ferramenta para corrigir “código ruim” gerado por Copilot, ChatGPT ou Claude.165+ regras, 10 idiomas. LLM Armor — Focado em proteger aplicativos que usam LLMs, de acordo com a classificação OWASP Top 10 para LLM . Funciona como um escudo/filtro. Ele verifica os prompts de entrada quanto a injeções e as respostas de saída quanto ao vazamento de dados confidenciais. Kereva Scanner — Um scanner especializado para código Python que procura vulnerabilidades precisamente nos locais de chamadas de bibliotecas de IA (OpenAI SDK, LangChain, etc.). Nenhum deles, é claro, é uma panacéia, e não tão OP quanto Aardvark e TitanCA. Bem, o que posso dizer… Seu agente de IA é um sabotador! (estou brincando) (ou talvez não esteja) Há cada vez mais palha, a esteira está ficando mais rápida e os ímãs estão ficando mais fortes. Uma pessoa neste sistema atua como observador. Se a esteira travar ou a palha for substituída por palha, ela terá que reagir. Acho que não vamos excluir completamente uma pessoa desse processo por muito tempo. A única conclusão é: desenvolver e aprender constantemente coisas novas, porque mesmo as redes neurais mais inteligentes precisam das pessoas mais inteligentes. © 2026 LLC “MT FINANCE” Tags: vulnerabilidades inteligência artificial vibe-coding copilot claude claude code llm erros de programadores bugs ruvds_artigos Hubs: Blog da empresa RUVDS.com Inteligência Artificial Aprendizado de Máquina Segurança da Informação Programação +9 2 0 512K+ Alcance em 30 dias RUVDS.com Telegram VKontakte X 32K+ Alcance em 30 dias 63 Karma @rRenegat Usuário Inscrever-se Comentar Melhor do dia Semelhante