A IA limpa o código e esconde as falhas

Um código pode estar bem escrito e continuar inseguro. A distância entre essas duas condições aparece em um levantamento da Apiiro, empresa de segurança de aplicações, publicado em setembro de 2025. Em repositórios de empresas da Fortune 50, a companhia registrou queda de 76% nos erros triviais de sintaxe em código escrito por IA, acompanhada de aumento de 322% nos caminhos de escalada de privilégio, falhas que podem permitir acesso além do autorizado. Os resultados valem para a amostra analisada. Não medem todo o software produzido com IA.

Esse descompasso ganhou uma leitura de mercado em 22 de setembro de 2026. A Juniper Research alertou que o volume de código gerado com IA pressiona um setor de segurança de aplicações, conhecido como AppSec, ainda concentrado em varrer sistemas e produzir relatórios de falhas. Para quem aprova investimentos em automação do desenvolvimento, a implicação é concreta: acelerar a produção pode aumentar o trabalho necessário para colocar software seguro em operação.

A evidência disponível exige separar três questões: a capacidade de um modelo de gerar código seguro, o efeito dos assistentes sobre o trabalho das equipes e as vulnerabilidades encontradas em projetos publicados. Os estudos medem partes diferentes desse processo. Juntos, ajudam a entender o risco; não permitem calcular uma taxa única de insegurança da programação com IA.

A Veracode oferece uma medida da primeira questão. No relatório de 2026, a taxa média de aprovação em segurança ficou em 56%, ante 55% no primeiro relatório. Cerca de 44% das tarefas avaliadas produziram código com vulnerabilidades. No ranking divulgado em julho de 2026, o GPT-5.5 liderou com 68% de aprovação. Mesmo o melhor resultado deixou quase um terço das tarefas sem passar no teste.

Há uma ressalva decisiva: os testes avaliaram os modelos diretamente, sem instruções específicas de segurança, agentes, ferramentas adicionais ou revisão humana. Portanto, os 44% não representam a proporção de código vulnerável que chega à produção nas empresas. O resultado mostra o que pode sair do modelo antes dessas proteções. E por que elas importam.

No texto que acompanha o relatório, a Veracode descreve modelos próximos de 100% de acerto sintático, mas sem progresso equivalente em segurança. A aparência de correção oferece uma garantia limitada: um programa pode respeitar as regras da linguagem e ainda permitir comportamentos que deveriam ser bloqueados. Para a gestão, usar a qualidade aparente do código como indicador de risco deixa de fora justamente o que os testes procuram avaliar.

O problema se amplia quando muda a forma de entregar as alterações. A Apiiro observou que desenvolvedores com assistência de IA produziam mais commits, mas reuniam as mudanças em menos pull requests, cada um abrangendo mais arquivos e serviços. Pull requests são os conjuntos de alterações submetidos à revisão antes de sua incorporação ao projeto. Na avaliação da empresa, essa concentração dificulta a análise e aumenta o alcance de um erro que passe despercebido.

É nesse ponto que o diagnóstico da Juniper ganha relevância. A consultoria vê no vibe coding uma pressão sobre o modelo de varredura e relatório. O termo designa o uso de IA para ajudar a produzir código a partir de instruções. Identificar uma falha e incluí-la numa lista deixa trabalho por fazer: avaliar sua importância, corrigir o problema e verificar a correção. A implicação é que ampliar a detecção pode ser insuficiente se a capacidade de tratar os problemas não acompanhar o volume de entregas.

Thomas Wilson, autor do relatório da Juniper, descreve uma mudança no próprio processo: a segurança passa de um fluxo de desenvolvimento relativamente controlado para a proteção contínua de um volume maior e mais dinâmico de código. A Juniper recomenda plataformas capazes de identificar vulnerabilidades mais cedo, com automação e segurança desde a concepção. A proposta é incorporar controles ao desenvolvimento acelerado por IA. O comunicado não mede a eficácia dessas plataformas.

Para a empresa que adota assistentes, essa recomendação acrescenta uma dimensão à conta da produtividade. O tempo economizado na escrita precisa ser considerado junto com o esforço de revisão, correção e proteção das entregas. Parte do ganho inicial pode ser consumida na validação, embora os estudos não quantifiquem esse saldo.

Para os fornecedores, a mesma pressão abre uma oportunidade comercial. A Juniper projeta que o gasto empresarial global com AppSec passe de US$ 11 bilhões em 2026 para perto de US$ 13 bilhões em 2031, avanço acumulado superior a 16% em cinco anos. A consultoria trata o vibe coding como catalisador de investimento e coloca Veracode, Checkmarx e Black Duck nas primeiras posições de seu ranking. O comunicado não separa quanto desse crescimento vem da IA.

Existe também uma questão de confiança. Um estudo de pesquisadores de Stanford, disponibilizado inicialmente em novembro de 2022 e revisado em dezembro de 2023, encontrou código menos seguro entre participantes que usaram um assistente baseado no modelo codex-davinci-002, da OpenAI. Esses participantes também demonstraram maior propensão a acreditar que haviam escrito código seguro.

O experimento usou um modelo anterior aos atuais. Mostra, naquele contexto, que confiança e segurança podem seguir em direções diferentes. A revisão perde eficácia se o profissional atribui ao assistente uma confiabilidade que ainda precisa demonstrar.

Há sinais do problema fora dos testes controlados. Em uma publicação de 13 de abril de 2026, o Georgia Tech informou que o Vibe Security Radar havia confirmado 74 casos de vulnerabilidades associadas a código de IA. Desses, 14 eram classificados como críticos e 25 como de alta gravidade. O projeto identificou 56 casos no primeiro trimestre de 2026, dos quais 35 em março.

O radar examina avisos públicos de vulnerabilidade e o histórico do código para localizar a mudança que introduziu o problema. A associação com IA depende de marcas como registros de coautoria e identificadores das ferramentas. Sem esses sinais, o método pode deixar casos de fora. O levantamento documenta vulnerabilidades em projetos reais, mas não mede a incidência em todo o código gerado por IA nem permite atribuir o crescimento observado exclusivamente à piora dos modelos.

Outra frente está nas dependências: os componentes externos incorporados ao software. Um estudo apresentado na USENIX Security 2025 analisou 576 mil amostras de código, geradas por 16 modelos em Python e JavaScript. Os pesquisadores encontraram referências a pacotes inexistentes e reportaram percentuais médios de pacotes alucinados de pelo menos 5,2% nos modelos comerciais e 21,7% nos modelos abertos avaliados.

O mecanismo de ataque descrito é simples: alguém pode publicar um pacote malicioso com o nome inventado pelo modelo. Se a recomendação se repetir e o desenvolvedor instalar o componente, a dependência fictícia se transforma em uma via de comprometimento. Os percentuais medem recomendações de pacotes. Não contam ataques bem-sucedidos. O risco ajuda a explicar por que validar código também envolve conferir a origem do que ele manda instalar.

Os limites das fontes precisam acompanhar a leitura dos resultados. Apiiro e Veracode vendem segurança de aplicações e têm interesse comercial na expansão desse mercado. Isso não invalida as medições, mas exige atenção à metodologia e ao alcance das conclusões.

A contestação já existe dentro do próprio setor. Em entrevista à CSO, Jeff Williams, cofundador e CTO da Contrast Security, questionou a magnitude dos ganhos de velocidade e do aumento de problemas divulgados pela Apiiro. A empresa respondeu que diferenças de escopo, população e método explicavam a distância em relação a outros estudos, inclusive por considerar dependências e exposição de segredos, além de falhas de código.

Há uma distinção importante nessa disputa: um achado de segurança não equivale automaticamente a uma vulnerabilidade explorável ou a um incidente. Também não há medição específica sobre as empresas brasileiras.

Há também diferenças no diagnóstico. Enquanto a Apiiro destaca a redução de erros de sintaxe acompanhada de mais problemas de arquitetura, a Juniper alerta para a reintrodução de vulnerabilidades básicas. Os resultados podem coexistir: respeitar as regras de uma linguagem de programação não garante a segurança do software.

Dentro das empresas, o teste é medir quanto do tempo ganho na escrita permanece depois da revisão, das correções e da entrada em operação. A velocidade de geração aparece primeiro. O ganho de produtividade precisa sobreviver ao restante do trabalho.