A segurança do código gerado por IA é hoje a única parte do desenvolvimento assistido que não melhorou. A discussão sobre se estes modelos conseguem escrever código que funciona acabou, e a resposta foi sim: os modelos actuais produzem código sintacticamente correcto quase 100% das vezes. Isso fecha a pergunta que as equipas de engenharia passaram dois anos a fazer e, sem alarido, substitui-a por outra mais difícil. Correcto segundo quem, e seguro contra o quê?

O 2026 GenAI Code Security Report da Veracode, publicado a 28 de Julho de 2026, põe um número nessa distância. Entre os modelos testados, a taxa média de aprovação em segurança é de 56%. Na primeira edição do mesmo relatório era de 55%. Um ano de evolução dos modelos produziu cerca de um ponto percentual de melhoria.

Dito ao contrário: cerca de 44% das tarefas de geração de código introduziram uma vulnerabilidade de risco.

A falha é desigual, e é aí que está o que interessa

Uma média esconde aquilo sobre que um responsável de engenharia precisa de agir. O relatório separa os resultados por classe de fraqueza, e a amplitude é suficiente para mudar a forma como uma equipa revê código.

Onde os modelos se saem bem: o uso de algoritmos criptográficos passa a 87% e a injecção de SQL a 83%. São as vulnerabilidades com décadas de documentação, com formas idiomáticas claras e com exemplos abundantes. Os modelos aprenderam-nas a fundo.

Onde falham gravemente: o cross-site scripting passa a apenas 15% e a injecção em registos a 12%. Quase nove vezes em cada dez, o código gerado traz o defeito.

Vale a pena demorar-se neste padrão. As vulnerabilidades que uma organização está mais inclinada a dar por resolvidas — por serem antigas, conhecidas e bem documentadas — são precisamente aquelas em que o modelo se porta bem. As falhas concentram-se nas fraquezas que dependem do contexto, em que a segurança depende de onde veio o dado e para onde vai. Nenhum reconhecimento local de padrões responde a isso: é uma propriedade do sistema, não do excerto.

A consequência prática é desconfortável. Uma revisão de segurança genérica, com os pesos que historicamente se lhe deram, procura no sítio errado — inspecciona justamente as classes que o modelo já acerta.

Os modelos de raciocínio ajudam menos do que o discurso comercial sugere

O relatório compara também categorias de modelos, e as diferenças são menores do que o posicionamento faz supor. Os modelos de raciocínio ficam nos 56%, contra 51% dos restantes. Os especializados em programação ficam nos 51%; os generalistas nos 52%. O melhor chega aos 68%, enquanto mais de metade dos testados fica entre os 50% e os 53%.

Vale a pena reler os dois números do meio. Os modelos especializados em programar pontuaram abaixo dos generalistas. Especialização em escrever código não produziu especialização em escrever código seguro, o que faz sentido assim que se diz em voz alta: o objectivo de treino premeia código que funciona, e código inseguro funciona.

Trocar de modelo não é, portanto, uma estratégia de segurança. É, quando muito, alguns pontos percentuais num número que precisa de andar muito mais.

Porque é que o número quase não mexeu num ano

Entre as duas edições, a indústria lançou modelos bastante mais capazes. A correcção sintáctica aproximou-se do tecto. Os indicadores de raciocínio e de uso de ferramentas melhoraram de forma visível. A segurança passou de 55% para 56%.

A leitura mais plausível é que a segurança não é uma capacidade que esteja a ser optimizada, porque não é o que as avaliações dominantes medem. Um modelo é premiado por produzir código que satisfaz o pedido. Uma vulnerabilidade satisfaz o pedido. Enquanto o objectivo não mudar, o número tem pouca razão para subir — e o planeamento deve assumir que não sobe.

O que isto muda na prática

Se gerar é praticamente gratuito e quase sempre sintacticamente válido, o limite da entrega passa inteiramente para a verificação. A revisão deixa de ser uma formalidade aplicada a trabalho humano e passa a ser a única coisa entre uma taxa de 56% e a produção.

Para quem dirige engenharia, isso implica três mudanças concretas. A revisão de segurança tem de ser medida e não presumida, porque a falha é invisível no momento em que o código nasce — parece certo. Tem de ter peso nas classes de fraqueza onde os modelos falham de forma demonstrável, em vez de se espalhar por uma lista escrita para padrões de erro humano. E tem de correr na linha de montagem, em vez de depender de quem calhar pegar no pedido de integração.

Nada disto é argumento contra o desenvolvimento assistido por IA. É argumento de que a segurança do código é uma propriedade do processo à volta do modelo, e não do modelo — e que as organizações que a tratam como decisão de compra estão a medir a coisa errada. O código vai compilar. O risco nunca foi esse.

Fonte: Veracode, 2026 GenAI Code Security Report, 28 de Julho de 2026.