PG

Pedro Gontijo21/10/2025 23:50
Compartilhe

Vibe Coding provoca falhas de segurança?

  • #Java
  • #C#
  • #Python
  • #Low-code
  • #Inteligência Artificial (IA)
  • #Segurança da Informação
  • #JavaScript

Vibe Coding provoca falhas de segurança?

 O uso de LLMs e agente de codificação na criação de software é Vibe Coding?

Desde a propagação do termo Vibe Coding, seu significado vem sendo confundido com o uso correto de ferramentas de IA generativa. O conceito de Vibe Coding é a forma de desenvolvimento guiada mais pela intuição e pela sensação de produtividade imediata do que por fundamentos técnicos, documentação, padrões de projeto ou segurança. 

Isto é, nesse modelo de desenvolvimento o pensamento crítico de engenharia que deveria ser empregado não ocorre, ou pelo menos não como deveria, tornando-se uma prática mais emocional e menos sistemática.

Entretanto, não se pode falar que o Vibe Coding é algo necessariamente ruim, ele estimula a experimentação, a prototipagem e o “flow” criativo. O seu problema aparece quando se torna o padrão de produção, sem uma validação ou revisão técnica.

 Como o uso de agentes de codificação e ferramentas Low/No code pode provocar falhas graves de segurança no seu software.

Com o avanço e disseminação do uso de LLMs e agentes de codificação a barreira de entrada para o desenvolvimento de software caiu. 

Trabalhos recentes mostram que a combinação de LLMs e arquiteturas serverless permite que usuários não-técnicos construam aplicações completas, reduzindo a necessidade de conhecimentos de infraestrutura e programação formal (ZHANG et al., 2025).

Em paralelo, estudos sobre ferramentas como Copilot apontam aumento de produtividade e alteração nas práticas de programação, especialmente entre novatos, o que sugere que ferramentas LLM estão democratizando a escrita de código (JAIN et al., 2025).

Ambas as tecnologias, indiscutivelmente trazem ganho de eficiência e produtividade na implementação de novas funcionalidades e serviços de softwares. O que também gera grande interesse na adoção dessas ferramentas. 

Relatórios de mercado projetam ampla adoção de low/no-code e crescimento de iniciativas de ‘citizen development’, o que significa que cada vez mais aplicações corporativas são construídas por pessoas com pouco background em segurança. 

Uma evidência empírica a qual mostra que essa adoção está realmente acontecendo: a pesquisa anual da Stack Overflow registrou um salto no uso/plano de uso de ferramentas de IA no processo de desenvolvimento, chegando a 84% dos respondentes em 2025 (era 76% em 2024), com mais da metade dos desenvolvedores profissionais usando essas ferramentas diariamente (STACK OVERFLOW, 2025). 

Isso indica não apenas maior penetração entre engenheiros, mas também uma difusão rápida do uso de LLMs/assistentes de código em diferentes perfis de criadores de software.

As IAs estão reensinando a programar errado?

 A facilidade em gerar código pode estar ressuscitando vulnerabilidades que já foram consideradas superadas.

Quando se confia num agente de codificação para o ganho de produtividade imediata, tende-se a desprezar a maneira em que esses assistentes são treinados, com milhões de trechos de códigos que contém não apenas boas práticas, mas principalmente más práticas, e muitas vezes, com vulnerabilidades conhecidas. Resultando em um código funcional, mas com sérios problemas de segurança, com as clássicas vulnerabilidades de injeção, XSS e autenticação fraca retomando o protagonismo.

O estudo empírico encontrou que em projetos do GitHub que usaram o GitHub Copilot e ferramentas similares, 29,5% dos códigos escritos em Python e 24,2% em JavaScript continham fraquezas de seguranças detectadas, dentro de 43 categorias de CWE diferentes (FANG et al., 2025).

Foi constatado em outro estudo conduzido para o Veracode’s 2025 GenAI Code Security Report, que utilizou mais de 100 modelos e mais de 80 tarefas específicas, que ao não incluir orientações de segurança, 45% das escolhas feitas pelos modelos foram por uma implementação insegura. Ademais, para vulnerabilidades de XSS e Logs Injection tiveram uma taxa de 86,47% e 87,97%, respectivamente (VERACODE, 2025).

Conjuntamente analisado no estudo, o desempenho de 4 linguagens de programação — Java, Python, C# e JavaScript — revelou o Java tendo a probabilidade significativamente maior de apresentar vulnerabilidades (71,5%) ao ser gerado por modelos de LLMs (VERACODE, 2025).

Em síntese, a prática do Vibe Coding sem a cultura de segurança carece do rigor que costumava eliminar vulnerabilidades nos anos anteriores. Dessa forma, vulnerabilidades que tendiam a serem solucionadas, mesmo que ainda na lista OWASP Top 10 2021, agora tendem a serem mais frequentes quando o código é feito no “feeling”.

 Do design inseguro ao código descuidado, os códigos modernos repetem as falhas do passado?

Enquanto no OWASP Top 10 2021, vulnerabilidades de Injection, que dessa vez engloba XSS, (OWASP Top 10 2017 A01) caiu para A03, e Falhas de Identificação e Autenticação, (OWASP Top 10 2017 A02) caiu para A07, e surgiram novos focos de vulnerabilidades como o Design Inseguro (A04) e Falhas de Integridade de Software e Dados (A08), além do protagonismo do Controle de Acesso Quebrado, (OWASP Top 10 2017 A05) subindo para A01.

Mudanças essas refletem um amadurecimento da engenharia de software e maior profissionalização no desenvolvimento seguro por parte de desenvolvedores. Vulnerabilidades “simples” vinham sendo mitigadas por boas práticas, frameworks e pipelines automatizados de segurança. As fraquezas de segurança deixara de ser por código mal escrito para serem por arquitetura mal desenhada.

Por consequência, a retomada de vulnerabilidades que estavam em queda no OWASP Top 10, não excluem a ascensão de novos focos como Design Inseguro, são fraquezas inclusivas. Afinal, um Vibe Coder, como é chamado o praticante de Vibe Coding, que não se preocupa em sanitizar/validar payloads para requisições, não se preocupa com desenhar uma arquitetura de software moderna, robusta e segura.

Apesar do foco em aplicações corporativas web, um exemplo concreto dessa regressão pode ser observada em jogos: ferramentas de manipulação de memória e engenharia reversa continuam a explorar vulnerabilidades clássicas mesmo em títulos atuais. 

Como observável no estudo feito de forma empírica, o Cheat Engine e sua VM (DBVM) podem ser usados para elevar privilégios de acesso à memória e contornar detecções (WANG et al., 2025), provando que técnicas antigas ainda funcionam em engines atuais

 Migrar para o Low/No Code não é a solução

Já comprovado anteriormente, o avanço do Low/No Code popularizou a ideia de usuários de negócio criarem aplicações sem formação técnica. O problema é que, ao empoderar pessoas sem formação em engenharia de software, também se democratiza a introdução de vulnerabilidades. 

CWEs divulgadas pela OWASP no Top 10 de Low-Code/No-Code mostram o top 3 crítico, com possibilidades de escalonamento de privilégio no A01, falhas de autenticação e autorização no A02 e vazamento de dados sensíveis no A03 (OWASP Foundation, 2024).

Falhas no manuseio de injeção também são presentes no Top 10 de Low-Code/No-Code da OWASP: aplicações construídas com essas ferramentas frequentemente consultam dados dinamicamente com base na entrada do usuário, ficando expostas a risco de ataques baseados em injeção. 

Ou seja, quando o usuário insere dados em um sistema, esses dados podem ser interpretados como “código a ser executado” em vez de “dados a serem armazenados ou processados”.

Convergindo com o Vibe Coding, o desenvolvimento de aplicações com essas soluções feitas por usuários empresariais, mesmo que de maneira diferente, busca o resultado rápido e ignora os riscos de segurança. O resultado é código funcional, mas também vulnerável, contribuindo para a regressão de segurança em software.

Como as Vulnerabilidades são encontradas e exploradas

O ciclo de descoberta e exploração de vulnerabilidades segue princípios bem estabelecidos e padronizados pela comunidade de segurança: desde o planejamento e reconhecimento até a análise de vulnerabilidades, exploração e atividades pós-teste (NIST SP 800-115, 2008).

Metodologias como o PTES detalham fases práticas: pré-engajamento, coleta de inteligência, modelagem de ameaça, análise, exploração, pós-exploração e reporte, oferecendo guidelines técnicos e operacionais para testar sistemas de forma controlada (PTES, s.d.).

Para aplicações web, guias como o OWASP Web Security Testing Guide (WSTG) traduzem esses princípios em casos de teste concretos (injeção, autenticação, controle de acesso, validação de entrada etc.) e em técnicas aplicáveis tanto em auditorias manuais quanto automatizadas (OWASP WSTG, s.d.).

Integrar essas referências metodológicas é importante porque elas mostram que existem procedimentos consolidados para identificar e validar falhas. E que, quando esses procedimentos são ignorados em favor da entrega imediata (ou automatizados sem curadoria), o risco de reproduzir vulnerabilidades históricas aumenta substancialmente (NIST SP 800-115, 2008; PTES, s.d.; OWASP WSTG, s.d.).

 Fase 1: Reconhecimento

Do ponto de vista ofensivo, todo ataque começa antes de qualquer tentativa direta: começa no reconhecimento.

O atacante coleta sinais públicos como subdomínios, cabeçalhos HTTP, arquivos estáticos, repositórios de código, dependências e metadados de infraestrutura, e constrói um inventário de superfícies expostas. 

Em ambientes moldados por Vibe Coding e LLMs, esse reconhecimento é facilitado, pois modelos de IA tendem a gerar estruturas, nomes de variáveis e rotas com padrões altamente previsíveis. É comum encontrar endpoints como /api/users, /auth/login, /health, gerados automaticamente por templates ou scaffolds sem modificações/regularidades que reduzem o custo de descoberta e tornam os projetos “padronizados” mais fáceis de mapear (OWASP WSTG, s.d.).

Além disso, repositórios públicos de projetos criados com Copilot e agentes autônomos contêm footprints semelhantes, facilitando a correlação de vulnerabilidades entre projetos diferentes, algo que o atacante pode automatizar com varreduras baseadas em IA.

 Fase 2: Enumeração

Após o reconhecimento, vem a enumeração, o processo de coletar e confirmar comportamentos suspeitos.

O atacante, agora com hipóteses sobre pontos fracos, busca respostas sutis: variações no tempo de resposta, diferenças no tamanho de pacotes, códigos de status inconsistentes ou mensagens de erro reveladoras.

Aqui, o impacto do Vibe Coding é visível: códigos gerados por IA muitas vezes não tratam erros de forma consistente, retornam stack traces completos, mensagens verbosas ou respostas sem mascaramento. Isso fornece ao atacante feedback imediato sobre a tecnologia, framework e versão em uso (OWASP WSTG, s.d.).

Ferramentas automatizadas, inclusive baseadas em IA, como scanners de fuzzing inteligente, conseguem correlacionar esses padrões com falhas conhecidas (CWE), acelerando o processo de enumeração (MITRE CWE, s.d.).

Em suma, a falta de padronização segura na geração automática de código é o novo elo fraco da enumeração moderna.

 Fase 3: Validação

Na fase de validação, o atacante transforma um indício em uma prova. É o momento de verificar se uma entrada realmente é vulnerável, mas sem disparar alarmes.

Em sistemas construídos por assistentes de código, vulnerabilidades de validação tendem a ocorrer em camadas superficiais (fronts gerados por frameworks) ou camadas esquecidas (APIs de integração sem autenticação adequada).

O problema é que a IA tende a generalizar o comportamento seguro sem compreender contexto. Por exemplo, ela pode “aprender” que validar uma entrada com uma simples verificação de tipo é suficiente, mas ignorar restrições de negócio, encoding ou escaping, abrindo brechas para injeção de SQL, XSS ou command injection. A validação falha, portanto, é o resultado direto do código sintaticamente correto, porém semanticamente inseguro (OWASP WSTG, s.d.).

 Fase 4: Exploração em cadeia

Ataques reais raramente dependem de uma única falha. Eles se baseiam em cadeias de vulnerabilidades, explorando a interdependência de componentes. Por exemplo: uma rota pública mal configurada que expõe variáveis de ambiente, uma dependência vulnerável instalada automaticamente por um gerenciador de pacotes, uma falta de validação em endpoint de upload, que por fim resulta em execução remota de código.

Ambientes de Vibe Coding e Low/No Code tornam essas cadeias mais prováveis porque os padrões de geração de código e integração são repetidos mecanicamente.

O atacante, por sua vez, utiliza o mesmo raciocínio automatizado, empregando agentes de ataque baseados em IA que testam combinações e cadeias com velocidade e persistência superiores às humanas (PTES, s.d.; NIST SP 800-115, 2008).

Essas cadeias exploratórias, agora potencializadas por IA ofensiva, evidenciam um paradoxo: quanto mais automatizado o desenvolvimento, mais automatizada também se torna a exploração.

Conclusão

É perceptível que o avanço de agentes de codificação e plataformas de desenvolvimento assistidas por inteligência artificial transformou profundamente a forma como o software é concebido. Da mesma forma ferramentas de Low/No Code obtêm altas taxas de novos usuários. Entretanto, como demonstrado ao longo deste trabalho, o fenômeno do Vibe Coding, caracterizado pela priorização da intuição e da velocidade de entrega em detrimento da engenharia sistemática, expõe uma regressão preocupante nas práticas de segurança. Ambas as práticas sem uma cultura de segurança criam um ambiente fértil para a reincidência de vulnerabilidades já conhecidas e amplamente documentadas nas listas da OWASP (2021), incluindo injeções, falhas de autenticação e controles de acesso quebrados.

A literatura recente (VERACODE, 2025; Security Weaknesses of Copilot-Generated Code in GitHub Projects: An Empirical Study, 2025; he Effects of GitHub Copilot on Computing Students’ Programming Effectiveness, Efficiency, and Processes in Brownfield Programming Tasks, 2025) reforça que, embora os modelos generativos proporcionem ganhos de produtividade, sua ausência de compreensão contextual e semântica conduz à produção de código funcional, mas inseguro. Essa realidade evidencia que a automação, quando não acompanhada de curadoria humana, reproduz as mesmas fragilidades que a engenharia de software levou décadas para mitigar.

Para mitigar esses riscos, é imprescindível reintroduzir práticas fundamentais de segurança em todas as etapas do ciclo de desenvolvimento, mesmo em ambientes automatizados. Isso envolve: (i) validação e sanitização sistemática de entradas; (ii) integração de ferramentas de análise estática (SAST) e dinâmica (DAST) nos pipelines de CI/CD; (iii) auditoria contínua de dependências e configurações; e (iv) capacitação constante das equipes em Codificação Segura e Modelagem de Ameaças.

Além disso, recomenda-se o fortalecimento de políticas de hardening de prompts e instruções de modelos, de modo que as práticas de segurança não sejam omitidas em função de conveniência ou desempenho. A maturidade do desenvolvimento assistido por IA, portanto, não depende apenas da evolução tecnológica dos modelos, mas da capacidade das organizações de manterem o controle técnico e ético sobre eles.

Conclui-se, assim, que o futuro do desenvolvimento seguro não reside em rejeitar o Vibe Coding, mas em discipliná-lo: transformar a experimentação criativa em um processo auditável, resiliente e sustentado por uma cultura de segurança robusta. Somente a partir dessa convergência entre automação e responsabilidade será possível consolidar um ecossistema de software verdadeiramente seguro, inovador e confiável.

Referências

FANG, X. et al. Security Weaknesses of Copilot-Generated Code in GitHub Projects: An Empirical Study. arXiv preprint arXiv:2503.11289, 2025.

JAIN, R. et al. The Effects of GitHub Copilot on Computing Students’ Programming Effectiveness, Efficiency, and Processes in Brownfield Programming Tasks. arXiv preprint arXiv:2502.08123, 2025.

OWASP Foundation. OWASP Top 10: The Ten Most Critical Web Application Security Risks – 2021. OWASP, 2021. Disponível em: https://owasp.org/Top10. Acesso em: 18 out. 2025.

OWASP Foundation. OWASP Top 10 for Low-Code/No-Code Applications Security Risks – 2024. OWASP, 2024. Disponível em: https://owasp.org/www-project-top-10-low-code-no-code-risks. Acesso em: 20 out. 2025.

STACK OVERFLOW. Developer Survey 2025: Key Trends in AI-Assisted Development. Stack Overflow Insights, 2025. Disponível em: https://survey.stackoverflow.co/2025. Acesso em: 18 out. 2025.

VERACODE. 2025 GenAI Code Security Report. Burlington, MA: Veracode, 2025. Disponível em: https://www.veracode.com/state-of-software-security. Acesso em: 18 out. 2025.

WANG, J. et al. VIC: Evasive Video Game Cheating via Virtual Machine Introspection. Proceedings of the 34th USENIX Security Symposium, 2025.

ZHANG, Y. et al. LLM4FaaS: No-Code Application Development using LLMs and FaaS. arXiv preprint arXiv:2501.04567, 2025.

NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY (NIST). Technical Guide to Information Security Testing and Assessment (SP 800-115). Gaithersburg: NIST, 2008. Disponível em: https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-115.pdf. Acesso em: 21 out. 2025.

PENETRATION TESTING EXECUTION STANDARD (PTES). Penetration Testing Execution Standard. [S. l.], [s. d.]. Disponível em: http://www.pentest-standard.org/index.php/PTES_Technical_Guidelines. Acesso em: 21 out. 2025.

OPEN WEB APPLICATION SECURITY PROJECT (OWASP). Web Security Testing Guide (WSTG). [S. l.], [s. d.]. Disponível em: https://owasp.org/www-project-web-security-testing-guide/. Acesso em: 21 out. 2025.

Compartilhe
Comentários (0)