IA
Embora ainda se discuta sobre os reais benefícios dos assistentes de IA no ambiente de trabalho, é no desenvolvimento de software que sua adoção vem ocorrendo de forma mais confiante e acelerada. Nesse contexto, os LLMs assumem múltiplos papéis: desde a refatoração de código e geração de documentação até a criação completa de aplicativos. No entanto, os desafios tradicionais de segurança da informação na programação agora se somam às vulnerabilidades específicas dos modelos de IA. Nesse ponto de convergência, novos bugs e problemas têm surgido praticamente todas as semanas.
Código gerado por IA vulnerável
Quando um LLM gera um código, pode introduzir bugs ou falhas de segurança. Isso ocorre porque esses modelos são treinados com dados públicos da Internet, que incluem milhares de exemplos de códigos mal escritos ou inseguros. Um estudo recente da Veracode revelou que os principais modelos de IA já produzem código que compila com sucesso em 90% dos casos. Há menos de dois anos, esse número era inferior a 20%. No entanto, essa melhoria na execução não se traduz em segurança: aproximadamente 45% desse código ainda apresenta vulnerabilidades clássicas listadas no OWASP Top 10, e praticamente não houve avanços nesse aspecto nos últimos dois anos. A pesquisa analisou mais de cem LLMs populares e trechos de código em Java, Python, C# e JavaScript. Isso significa que, independentemente de a IA ser usada para “completar código” de forma automática (como no Windsurf) ou para fazer “vibe coding” (como no Lovable), o aplicativo final precisa obrigatoriamente passar por testes rigorosos de segurança. Porém, na prática, isso raramente acontece. Segundo um estudo da Wiz, 20% dos aplicativos criados com vibe coding apresentam vulnerabilidades críticas ou erros graves de configuração.
Um dos exemplos dessas falhas é o do aplicativo de relacionamento exclusivamente para mulheres, Tea, que ganhou notoriedade após dois grandes vazamentos de dados. No entanto, este aplicativo é anterior ao vibe coding. A Justiça determinará se a IA teve responsabilidade pelos vazamentos do Tea. Já no caso da startup Enrichlead, não há dúvidas: a IA foi a responsável. O fundador afirmou nas redes sociais que 100% do código da plataforma havia sido gerado pela Cursor AI, “sem uma única linha escrita manualmente”. Apenas alguns dias após o lançamento, o serviço já apresentava falhas básicas de segurança, permitindo acesso indevido a recursos pagos e modificações de dados por qualquer usuário. O projeto foi encerrado depois que o fundador não conseguiu elevar o nível de segurança do código usando apenas o Cursor. Mesmo assim, ele continua lançando novos projetos baseados em vibe coding.
Vulnerabilidades comuns em códigos gerados por IA
Embora a programação assistida por IA exista há apenas um ano ou dois, já existem dados suficientes para identificar os erros mais comuns. Normalmente, incluem:
- Falta de validação de dados de entrada, ausência de sanitização de dados de entrada do usuário para remover caracteres estranhos e outros erros básicos que levam a vulnerabilidades clássicas, como cross-site scripting (XSS) e injeção de SQL.
- Chaves de API e outros segredos inseridos diretamente no código da página, ficando visíveis para os usuários.
- Lógica de autenticação implementada inteiramente no lado do cliente, no próprio código do site em execução no navegador. Essa lógica pode ser facilmente modificada para burlar qualquer verificação.
- Erros de registro, desde filtragem insuficiente ao registrar informações nos logs até a completa ausência de logs.
- Funções excessivamente poderosas e perigosas: os modelos de IA são otimizados para gerar um código de saída que resolva uma tarefa da maneira mais curta possível. Porém, o caminho mais curto muitas vezes é inseguro. Um exemplo clássico é o uso da função eval para realizar operações matemáticas com base em dados fornecidos pelo usuário. Isso permite a execução arbitrária de código no aplicativo gerado.
- Dependências desatualizadas ou inexistentes. O código gerado por IA geralmente faz referência a versões antigas de bibliotecas, utiliza chamadas de API obsoletas ou inseguras ou até tenta importar bibliotecas fictícias. Esse último caso é particularmente perigoso, pois invasores podem criar uma biblioteca maliciosa com um nome “plausível”, e o agente de IA acabará incluindo-a em um projeto real.
Em um estudo sistemático, os autores verificaram um código gerado por IA em busca de fragilidades incluídas na lista MITRE CWE Top 25. As mais comuns foram: CWE-94 (injeção de código), CWE-78 (injeção de comando do sistema operacional), CWE-190 (estouro de inteiro), CWE-306 (ausência de autenticação) e CWE-434 (upload irrestrito de arquivos).
Um exemplo marcante de CWE-94 foi o comprometimento recente da plataforma Nx, que já abordamos anteriormente. Agentes mal-intencionados conseguiram inserir um cavalo de Troia em uma ferramenta popular de desenvolvimento ao roubar um token que permitia a publicação de novas versões do produto. O roubo do token explorou uma vulnerabilidade introduzida por um fragmento de código simples gerado por IA.
Prompts perigosos
O conhecido ditado entre desenvolvedores, “feito exatamente conforme a especificação”, também se aplica ao trabalhar com um assistente de IA. Se o prompt para criar uma função ou aplicativo for vago e não mencionar aspectos de segurança, a probabilidade de gerar um código vulnerável aumenta consideravelmente. Um estudo dedicado constatou que mesmo instruções genéricas como “garanta que o código siga as melhores práticas de segurança” são capazes de reduzir pela metade a taxa de vulnerabilidades.
A abordagem mais eficaz, no entanto, é usar orientações detalhadas de segurança específicas para cada linguagem, com referência às listas de erros do MITRE ou OWASP. Uma grande coleção dessas instruções de segurança da Wiz Research está disponível no GitHub; recomenda-se adicioná-las aos prompts do sistema dos assistentes de IA por meio de arquivos como claude.md, .windsurfrules ou similares.
Degradação da segurança durante revisões
Quando um código gerado por IA é revisado repetidamente por meio de prompts de acompanhamento, a segurança dele tende a se deteriorar. Em um estudo recente, pesquisadores fizeram com que o GPT-4o modificasse um código escrito anteriormente até 40 vezes, enquanto verificavam cada versão em busca de vulnerabilidades após cada rodada de modificações. Após apenas 5 iterações, o código apresentou 37% mais vulnerabilidades críticas do que a versão inicial. O estudo testou quatro estratégias de prompting, três delas com ênfases diferentes: (i) desempenho, (ii) segurança e (iii) novas funcionalidades; a quarta utilizava prompts vagos e pouco claros.
Quando os prompts focaram na adição de novas funcionalidades, surgiram 158 vulnerabilidades, incluindo 29 críticas. Quando o prompt enfatizou a codificação segura, o número caiu significativamente, mas ainda assim incluiu 38 novas vulnerabilidades, sendo sete delas críticas.
Curiosamente, os prompts “com foco em segurança” resultaram no maior percentual de erros em funções relacionadas à criptografia.
Sem considerar o contexto do setor
Em setores como finanças, saúde e logística, há requisitos técnicos, organizacionais e legais que devem ser considerados durante o desenvolvimento de aplicativos. Os assistentes de IA não estão cientes dessas restrições. Esse problema é frequentemente chamado de “falta de profundidade”. Como consequência, métodos de armazenamento e processamento de dados pessoais, médicos ou financeiros exigidos por regulamentos locais ou setoriais não são refletidos no código gerado por IA. Por exemplo, um assistente pode escrever uma função matematicamente correta para calcular juros de depósitos, mas ignorar regras de arredondamento impostas por órgãos reguladores. No setor de saúde, as regulamentações costumam exigir registro detalhado de cada tentativa de acesso a dados, algo que a IA não implementará de forma automática no nível de detalhamento necessário.
Configuração incorreta de aplicativos
As vulnerabilidades não se limitam ao código criado por vibe coding. Muitas vezes, os aplicativos gerados por esse método são desenvolvidos por usuários inexperientes, que ou não configuram o ambiente de execução, ou fazem isso seguindo recomendações fornecidas pela própria IA. Isso resulta em configurações perigosas, como:
- Bancos de dados necessários para o aplicativo são criados com permissões de acesso externo excessivamente amplas. Esse tipo de erro leva a vazamentos como os dos casos do Tea/Sapphos, nos quais o invasor nem sequer precisa usar os aplicativos para baixar ou excluir todo o banco de dados.
- Aplicativos corporativos internos ficam acessíveis ao público sem qualquer necessidade de autenticação.
- Os aplicativos recebem permissões elevadas para acessar bancos de dados críticos. Combinadas com vulnerabilidades inerentes ao código gerado por IA, essas permissões facilitam ataques de injeção de SQL e similares.
Vulnerabilidades das plataformas
A maioria das plataformas de vibe coding executa aplicativos gerados com prompts diretamente nos seus próprios servidores. Isso cria uma dependência do desenvolvedor em relação à plataforma, incluindo a exposição a suas vulnerabilidades e dependência de suas práticas de segurança. Por exemplo, em julho foi descoberta uma vulnerabilidade na plataforma Base44 que permitia que invasores não autenticados acessassem qualquer aplicativo privado.
Ameaças na fase de desenvolvimento
A simples presença de um assistente com amplos direitos de acesso no computador do desenvolvedor já cria riscos. Veja alguns exemplos:
A vulnerabilidade CurXecute (CVE-2025-54135) permitia que invasores instruíssem a popular ferramenta de desenvolvimento com IA, Cursor, a executar comandos arbitrários no computador do desenvolvedor. Para isso, bastava que houvesse um servidor Model Context Protocol (MCP) ativo conectado ao Cursor, o que poderia ser usado por terceiros para obter acesso. Essa é uma situação comum: servidores MCP concedem aos agentes de IA acesso a mensagens do Slack, tarefas no Jira e assim por diante. A injeção de prompts pode ser realizada por qualquer um desses canais.
A vulnerabilidade EscapeRoute (CVE-2025-53109) permitia a leitura e gravação de arquivos arbitrários no disco do desenvolvedor. A falha existia no popular servidor MCP da Anthropic, que permite que agentes de IA escrevam e leiam arquivos no sistema. As restrições de acesso do servidor simplesmente não funcionavam.
Um servidor MCP malicioso, que permitia a agentes de IA enviar e receber e-mails via Postmark, encaminhava simultaneamente toda a correspondência para um endereço oculto. Previmos o surgimento desses servidores MCP maliciosos como este ainda em setembro.
Uma vulnerabilidade na interface da linha de comando Gemini permitia a execução de comandos arbitrários quando o desenvolvedor simplesmente pedia ao assistente de IA para analisar o código de um novo projeto. A injeção maliciosa era acionada de um arquivo readme.md.
A extensão Q Developer da Amazon para o Visual Studio Code temporariamente incluiu instruções que apagavam todos os dados do computador do desenvolvedor. Um invasor explorou um erro dos próprios desenvolvedores da Amazon e conseguiu inserir esse prompt malicioso no código público do assistente sem precisar de privilégios especiais. Felizmente, um pequeno erro de codificação impediu sua execução.
Uma vulnerabilidade no agente Claude Code (CVE-2025-55284) permitia a exfiltração de dados do computador do desenvolvedor por meio de solicitações DNS. A injeção de prompt, que se baseava em utilitários comuns executados automaticamente sem confirmação, podia ser incorporada em qualquer código analisado pelo agente.
O agente autônomo de IA Replit excluiu os bancos de dados principais de um projeto em desenvolvimento porque decidiu que o banco precisava de uma limpeza. Isso violou uma instrução direta que proibia modificações (code freeze). Por trás desse comportamento inesperado da IA havia uma falha arquitetural fundamental. Na época, o Replit não tinha separação entre os bancos de dados de teste e produção.
Uma injeção de prompt inserida em um comentário de código-fonte levou o ambiente de desenvolvimento Windsurf a armazenar automaticamente instruções maliciosas na sua memória de longo prazo, o que permitiu roubar dados do sistema ao longo de meses.
No incidente de comprometimento do Nx, ferramentas de linha de comando para Claude, Gemini e Q foram usadas para procurar senhas e chaves que pudessem ser roubadas de um sistema infectado.
Como usar um código gerado por IA com segurança
O nível de risco associado a um código gerado por IA pode ser bastante reduzido, embora não completamente eliminado, por meio de uma combinação de medidas organizacionais e técnicas:
- Implementar a revisão automática do código gerado por IA conforme ele é escrito, utilizando ferramentas SAST otimizadas.
- Incorporar requisitos de segurança nos prompts do sistema em todos os ambientes de IA.
- Realizar revisões detalhadas de código com especialistas humanos experientes, apoiados por ferramentas de análise de segurança baseadas em IA para aumentar a eficácia.
- Treinar os desenvolvedores para escrever prompts de forma segura e, de maneira mais ampla, oferecer formação aprofundada sobre o uso seguro de IA.
