Não há dúvida de que o cenário do código gerado por IA evoluiu a um ritmo sem precedentes no ano passado. A ascensão da codificação Vibe, em que os desenvolvedores usam grandes modelos de linguagem (LLM) para criar código funcional, mudou fundamentalmente a forma como o software é construído.
CTO EMEA na Veracode.
No entanto, menos atenção tem sido dada à segurança do código produzido. O resultado? Montanhas de código de produção que realmente funcionam, mas que injetam e espalham enormes vulnerabilidades de segurança.
Ao mesmo tempo, os LLMs permitem que os invasores identifiquem e explorem essas falhas com mais rapidez do que nunca. Com as capacidades defensivas a ficarem para trás, o fosso entre atacantes e defensores está a aumentar num momento crítico, à medida que as empresas dependem cada vez mais da IA.
A segurança é mais plana na maioria dos modelos de IA
Apesar dos recentes e rápidos avanços superficiais nos modelos de IA e na sua capacidade de gerar código funcional, há evidências crescentes de que a segurança não acompanhou o ritmo.
Estudos recentes mostram que a maioria das ferramentas de IA generativa (GenAI) produzem falhas de segurança significativas, incluindo modelos populares como Claude da Anthropic, Gemini do Google e Grok da xAI.
Em todos os modelos, linguagens, CWEs (contagens de vulnerabilidades comuns) e tarefas, apenas cerca de 55% das tarefas de geração geram código seguro, o que significa que os LLMs estão introduzindo uma vulnerabilidade detectável do OWASP Top 10 quase na metade das vezes.
Surpreendentemente, este aumento do risco de fragilidade foi agnóstico em diferentes tipos de modelos, sem diferença significativa entre modelos menores e maiores.
Embora a capacidade de gerar código sintaticamente correto tenha melhorado drasticamente, a segurança permanece estagnada. Dimensionar os modelos ou atualizar os dados de treinamento não é suficiente para melhorar significativamente os resultados de segurança.
Uma exceção notável são os modelos GPT-5 da OpenAI, que realizam etapas extras para pensar nos problemas antes de gerar o código. Esses modelos alcançaram taxas de aprovação de segurança significativamente mais altas, de 70% ou mais, em comparação com 50-60% das gerações anteriores.
Em contraste, o chat GPT-5, uma variante não fundamentada, permaneceu em 52%, sugerindo que o alinhamento do raciocínio, e não a escala do modelo, impulsiona estes ganhos. Os exemplos de ajuste do OpenAI aqui podem incluir código seguro de alta qualidade ou ensinar explicitamente os modelos a raciocinar sobre compensações de segurança para uma taxa mais alta.
Também surgiram tendências específicas na linguagem. Muitos modelos de IA têm desempenho muito pior em tarefas de geração de código Java do que qualquer outra linguagem de codificação, com taxas de aprovação de segurança abaixo de 30%, enquanto Python, C# e JavaScript geralmente ficam entre 38% e 45%.
Ao mesmo tempo, os modelos mais recentes, especialmente aqueles ajustados ao raciocínio, estão a ter melhor desempenho na geração de código seguro em C# e Java, provavelmente refletindo o foco dos laboratórios de IA nas principais linguagens de negócios.
Por que a segurança do LLM é interrompida?
A raiz do problema está na natureza dos dados de treinamento, que consistem em amostras de código público extraídas da Internet. Os dados resultantes incluem exemplos seguros e inseguros, incluindo projetos intencionalmente vulneráveis como o WebGoat, um aplicativo Java seguro usado para treinamento em segurança.
Os modelos então tratam todos esses exemplos como formas legítimas de satisfazer uma solicitação de codificação, aprendendo modelos que não distinguem entre implementações seguras e inseguras.
Como a maioria dos LLMs treina com base nesses dados disponíveis publicamente, existem padrões semelhantes na forma como eles criam riscos de segurança. Como os dados permanecem inalterados ao longo do tempo e são cada vez mais compostos por códigos sintéticos e gerados por IA, o desempenho da segurança dos modelos estagnou ao longo das gerações de modelos.
Isso também ajuda a explicar por que o Java é particularmente problemático. Java tem uma longa história como linguagem de implementação do lado do servidor e é anterior à ampla aceitação de vulnerabilidades como injeção de SQL.
Seus dados de treinamento devem, portanto, ter muito mais vulnerabilidades de segurança do que outras linguagens como C# ou Python, tornando os modelos significativamente piores em tarefas específicas de Java.
Ponto cego de segurança da codificação do ambiente
Essas descobertas levantam sérias preocupações sobre a crescente popularidade do desenvolvimento assistido por IA e da codificação ambiental. Embora essas práticas acelerem a produtividade, os desenvolvedores raramente especificam restrições de segurança quando exigem LLMs, o que melhoraria drasticamente a segurança do código gerado.
Por exemplo, um desenvolvedor pode solicitar a um modelo que crie uma consulta ao banco de dados sem especificar se ela deve ser construída usando uma instrução preparada (segura) ou concatenação de strings (insegura).
Isto deixa essas decisões para os LLMs, que, segundo os resultados, fazem a escolha errada quase metade das vezes. É preocupante que esta questão mostre poucos sinais de melhoria.
E os perigos já estão a surgir na prática. Um incidente recente com a ferramenta de codificação de IA na plataforma Replit resultou na eliminação de todo o banco de dados de produção ao vivo em um congelamento de código – um alerta severo sobre o que pode dar errado quando o código gerado por IA é confiável sem salvaguardas suficientes.
Implicações para desenvolvedores e organizações
Dadas estas deficiências persistentes, confiar apenas em melhorias do modelo não é uma estratégia de segurança viável. Embora os novos modelos de raciocínio ofereçam uma clara vantagem, o desempenho da segurança permanece altamente variável e mesmo os modelos com melhor desempenho introduzem vulnerabilidades em quase um terço dos casos.
Os assistentes de codificação de IA são ferramentas poderosas, mas não podem substituir desenvolvedores qualificados ou programas de segurança abrangentes.
Uma abordagem em camadas para o gerenciamento de riscos é essencial: manter a verificação e a validação contínuas usando análise estática (SAST) e análise de composição de software (SCA), independentemente da origem do código, e o bloqueio proativo de dependências maliciosas são essenciais para evitar que vulnerabilidades cheguem aos caminhos de produção.
As ferramentas de remediação baseadas em IA também apoiam os desenvolvedores, fornecendo orientação em tempo real e remediação automatizada, mas a responsabilidade pela implantação segura permanece humana.
O custo oculto do código gerado por IA
Os assistentes de codificação de IA e os fluxos de agentes representam o futuro do desenvolvimento de software e continuarão a evoluir em ritmo acelerado. Mas embora os LLMs sejam adeptos da criação de código funcionalmente correto, eles continuam a criar vulnerabilidades de segurança em uma taxa alarmantemente alta – um problema que não será fácil de resolver.
O desafio para cada organização é garantir que a segurança evolua juntamente com estas novas capacidades. Para lidar com isso, são necessários treinamentos específicos em segurança, alinhamento de raciocínio e aceitação de que a segurança não pode ser assumida, se quisermos evitar o acúmulo de dívidas de segurança.
Até que os laboratórios de IA priorizem a segurança em seus processos de treinamento e alinhamento, os desenvolvedores e as equipes de segurança deverão tratar o código gerado por IA como uma entrada inerentemente não confiável – um princípio a ser considerado na codificação ambiente cotidiana.
Apresentamos o melhor software de proteção de endpoint.
Este artigo foi produzido como parte do canal Expert Insights da TechRadarPro, onde apresentamos as melhores e mais brilhantes mentes da indústria de tecnologia atualmente. As opiniões expressas aqui são de responsabilidade do autor e não necessariamente da TechRadarPro ou Future plc. Caso tenha interesse em participar, mais informações aqui:
