Será que a programação Vibe é realmente segura? Este artigo da CMU estuda principalmente a "Análise Comparativa de Vulnerabilidades em Código Gerado por Agentes com Base em Tarefas do Mundo Real". Embora os agentes de IA estejam apresentando um desempenho cada vez melhor em termos de "funcionalidade" do código gerado, eles são surpreendentemente vulneráveis em termos de "segurança". Mesmo em códigos que funcionam perfeitamente, mais de 80% contêm vulnerabilidades de segurança graves. Contexto: O que é "Codificação Vibracional"? Por que é perigosa? "Vibe Coding" é um paradigma de programação emergente: em vez de escrever código linha por linha, os programadores usam linguagem natural para fornecer instruções vagas ou de alto nível, que são então usadas por um Agente LLM para concluir automaticamente tarefas de codificação complexas. Situação atual: Este método melhora significativamente a eficiência, e 75% dos entrevistados o utilizam. Risco potencial: Os usuários geralmente consideram apenas se o código "funciona" (funcionalidade), raramente tendo a capacidade ou a disposição de investigar se o código é "seguro". O artigo destaca que essa confiança cega está introduzindo riscos de segurança significativos no ambiente de produção. Metodologia de pesquisa: Benchmark SUSVIBES Para verificar a segurança, a equipe criou um novo conjunto de benchmarks chamado SUSVIBES. Fonte real: Ao contrário dos testes anteriores, que analisavam apenas arquivos/funções simples, o SUSVIBES extraiu 200 requisitos de funcionalidades complexas de projetos de código aberto reais (GitHub) que historicamente apresentaram vulnerabilidades de segurança. Processo de teste: • Encontre uma vulnerabilidade que já tenha sido corrigida (por exemplo, uma versão que corrigiu a injeção de SQL). • Reverter o código para o estado anterior à correção e fazer com que o Agente de IA reimplemente a funcionalidade. • Verificação dupla: Execute tanto "testes funcionais" (para verificar se a função está implementada) quanto "testes de segurança" (para verificar se a vulnerabilidade original é reproduzida). Descoberta principal: O fenômeno perturbador de "notas altas, habilidades baixas" A equipe testou as estruturas de agentes mais avançadas (SWE-Agent, OpenHands) e os modelos mais avançados (Claude 4 Sonnet, Gemini 2.5 Pro, Kimi K2). Os resultados são extremamente alarmantes: Poderoso, mas extremamente inseguro: A combinação com melhor desempenho (SWE-Agent + Claude 4 Sonnet) resolveu 61% das tarefas (funcionando corretamente). No entanto, desses códigos que funcionam corretamente, apenas 10,5% são seguros. Em outras palavras, mais de 80% do "bom código" contém, na verdade, vulnerabilidades graves (como condições de corrida, escalonamento de privilégios, ataques de injeção, etc.). Diferenças entre modelos: • Soneto 4 de Claude: O mais poderoso, mas também o que gera mais vulnerabilidades. • Gemini 2.5 Pro: Embora a taxa de aprovação da função seja baixa (19,5%), é relativamente seguro entre os problemas que consegue resolver (classificado como o modelo relativamente mais "seguro"). • Kimi K2: Nível intermediário. A mensagem de segurança é inválida. Os pesquisadores tentaram dizer à IA: "Por favor, tenha cuidado" e "Por favor, verifique se há vulnerabilidades no CWE". • Resultado: Além de a segurança não ter melhorado significativamente, a IA tornou-se hipersensível e até mesmo funções normais não puderam ser escritas corretamente (a taxa de aprovação da função caiu cerca de 6%). Estudo de caso: Como surgiu a vulnerabilidade? O artigo fornece um exemplo vívido (a função de verificação de senha no framework Django): • Tarefa: Implementar uma função verify_password. A abordagem da IA: O código é muito bem escrito e a lógica está correta. No entanto, ao encontrar usuários inválidos, a IA retorna diretamente False em nome da "eficiência". • Consequências de segurança: Isso cria uma vulnerabilidade de **canal lateral de temporização**. Os hackers podem determinar a existência de um nome de usuário no sistema detectando pequenas diferenças nos tempos de resposta. Conclusão: A IA frequentemente se concentra apenas na "correção lógica" e falha completamente em compreender os princípios mais profundos da "engenharia de segurança" (como a comparação em tempo constante). Resumo e recomendações: Este artigo serve como um alerta para a atual febre da programação de IA. Para desenvolvedores: Nunca confie cegamente em código gerado por IA, especialmente em módulos sensíveis como autenticação, criptografia e análise de dados. "Funciona" significa "seguro". Para empresas: Ao adotar ferramentas de programação com IA (como Cursor, Claude Code), é obrigatório introduzir revisões de segurança humanas ou varreduras de segurança automatizadas (SAST/DAST), e não depender apenas de testes unitários. Direção futura: Simples instruções não resolvem problemas de segurança; precisamos de uma nova geração de agentes especificamente treinados para segurança. Documento original
