Segurança do vibe coding: os riscos que entregas, e como apanhá-los

O vibe coding é seguro?

Não, não por omissão. Investigadores auditaram 200 aplicações de vibe coding publicamente em produção num estudo arXiv de 2026 e encontraram pelo menos uma vulnerabilidade em 91,0% delas, com 65,8% dos 1186 problemas registados classificados como Critical ou High. O vibe coding produz software que funciona de forma fiável, e software seguro apenas por acidente.

91,0%

das 200 aplicações de vibe coding auditadas tinham pelo menos uma vulnerabilidade (Deng, Fan e Meng, arXiv 2606.23130)

11,8%

das soluções dos agentes eram seguras, face a 57% funcionalmente corretas (benchmark SusVibes, Carnegie Mellon e parceiros)

65,8%

das 1186 vulnerabilidades dessa auditoria foram classificadas como Critical ou High

A auditoria é Understanding the (In)Security of Vibe-Coded Applications, de Junquan Deng, Zhiyu Fan e Ruijie Meng, publicada em junho de 2026 e revista pela última vez em setembro. Os autores recolheram 9041 aplicações open source construídas com agentes populares, o Claude Code e o Lovable entre eles, e auditaram depois 200 publicamente em produção. Ligam as 1186 descobertas a oito modos de falha recorrentes e a três limitações dos próprios agentes: defeitos de memória, defeitos de objetivo e defeitos de conhecimento.

A evidência de benchmark aponta na mesma direção. Is Vibe Coding Safe? Benchmarking Vulnerability of Agent-Generated Code in Real-World Tasks, de uma equipa liderada pela Carnegie Mellon, construiu o SusVibes a partir de 186 pedidos de funcionalidade retirados de projetos open source reais, em que um humano tinha feito commit de uma implementação vulnerável. Em 12 configurações de agente de uso corrente, 57% das soluções do SWE-Agent com o Claude 4 Sonnet estavam funcionalmente corretas e 11,8% eram seguras.

A resposta honesta é que o vibe coding é tão seguro quanto os controlos à sua volta, e a maioria das configurações não tem nenhum que atue antes de o código aterrar. Código com aspeto funcional é precisamente o tipo que um revisor apressado deixa passar. Velocidade sem um ponto de controlo de segurança é como se entrega a falha e a funcionalidade no mesmo commit.

O que é o vibe coding?

O vibe coding é construir software dando prompts a um agente de IA em linguagem natural em vez de escreveres o código. Descreves o resultado, o agente gera e edita os ficheiros, e iteras com outro prompt. O autor do código passa a ser o modelo, e o humano revê uma saída que muitas vezes não consegue ler toda.

O termo espalhou-se no início de 2025 para descrever um fluxo em que um programador, ou cada vez mais um não programador, se apoia no agente e aceita o que ele produz desde que o resultado se comporte. Ferramentas como o Claude Code, o Cursor, o Windsurf, o OpenAI Codex e o GitHub Copilot tornaram-no prático: indexam um repositório, editam por toda a árvore, correm comandos e produzem funcionalidades a partir de um parágrafo de intenção. Isso é genuinamente poderoso. É também onde a lacuna de segurança se abre, porque a velocidade que o torna atraente é a mesma que enterra as falhas.

Quais são os riscos de segurança do vibe coding?

São os clássicos do OWASP Top 10, reproduzidos mais depressa do que a revisão consegue acompanhar. A auditoria arXiv de 2026 encontrou-os em controlo de acesso quebrado, injeção e falhas de autenticação. Quatro estão no CWE Top 25 de 2025: injeção SQL em 2.º, autorização em falta em 4.º, injeção de comandos em 9.º, desserialização insegura em 15.º.

Duas destas merecem um olhar mais atento, porque mostram o quão banal é o código gerado. Injeção primeiro. Pede "um endpoint de pesquisa que filtra utilizadores por nome" e o caminho de menor resistência é a concatenação.

# Vulnerable (CWE-89): user input concatenated into SQL
q = f"SELECT * FROM users WHERE name = '{name}'"
db.execute(q)

# Fixed: parameterized query, input never becomes code
db.execute("SELECT * FROM users WHERE name = %s", (name,))

A autorização quebrada é mais subtil, porque a versão vulnerável parece completa. Devolve a forma certa, passa o teste que pede "obter a encomenda 42", e é entregue.

// Vulnerable (CWE-639 IDOR): any logged-in user reads any order
app.get('/orders/:id', auth, async (req, res) => {
  const order = await Order.findById(req.params.id)
  res.json(order)
})

// Fixed: scope the lookup to the caller who owns it
app.get('/orders/:id', auth, async (req, res) => {
  const order = await Order.findOne({ _id: req.params.id, userId: req.user.id })
  if (!order) return res.status(404).end()
  res.json(order)
})

A diferença entre as duas versões é uma cláusula. Um revisor a ler 5000 linhas por dia não vê a cláusula em falta; vê um endpoint que devolve uma encomenda e segue em frente. O mesmo padrão repete-se em todas as linguagens que o agente escreve, tema do nosso olhar mais amplo sobre se o código gerado por IA é seguro.

Uma classe de risco não vem do código. Um agente lê ficheiros, documentação de dependências e descrições de ferramentas, e qualquer uma pode transportar instruções dirigidas ao agente em vez de a ti. A prompt injection é a LLM01, a primeira entrada do OWASP Top 10 for LLM Applications 2025, e é por isso que o passo 10 da checklist abaixo pergunta o que o agente correu, e não só o que escreveu.

Porque é que o vibe coding produz estas falhas?

Porque o prompt otimiza para o comportamento e o modelo otimiza para o padrão mais comum, e nenhum é o mesmo que segurança. Um pedido para pôr o checkout a funcionar não contém instrução para validar input, delimitar autorização ou parametrizar uma query, por isso o agente preenche a lacuna com o que o corpus de treino tornou provável.

Dois mecanismos agravam-se. O problema do corpus: o modelo aprendeu com código público cheio dos clássicos da OWASP, por isso inseguro por omissão é o seu a priori. O problema da ausência: a segurança é normalmente uma verificação que está presente, e um modelo a quem se pede um resultado positivo não acrescenta uma proteção negativa que ninguém pediu. Dizer-lhe que tenha cuidado não corrige nenhum dos dois. A equipa do SusVibes testou exatamente isso, acrescentando pistas de vulnerabilidade ao pedido, e reporta que a estratégia não mitigou os problemas de segurança.

Um terceiro mecanismo decide o resultado, e está do lado humano.

“

A pessoa a dar o prompt consegue dizer se a funcionalidade funciona. Geralmente não consegue dizer se é segura. Essa lacuna, entre a intenção do autor e a capacidade do revisor, é o problema de segurança todo.

É por isto que o vibe coding é estruturalmente diferente de um programador júnior a escrever o mesmo código. O júnior é lento o suficiente para a revisão acompanhar, e o revisor lê código que um humano escreveu à velocidade humana. O vibe coding tira os dois travões: a saída chega à velocidade da máquina, e quem é responsável por ela raramente tem a literacia de segurança para a avaliar. O pull request, o lugar onde a AppSec sempre viveu, torna-se um registo de decisões já tomadas em vez de um ponto de controlo.

O que entra numa checklist de segurança para vibe coding?

Dez passos, ordenados pelo retorno por hora gasta. Os primeiros fecham as classes que os agentes mais omitem, segundo a auditoria arXiv de 2026: controlo de acesso quebrado, injeção e falhas de autenticação. Os restantes são as proteções que impedem o próximo prompt de as reabrir. Corre-os por ordem em qualquer repositório que um agente tenha tocado.

1. Roda todas as credenciais que o agente possa ter lido, e depois analisa o histórico. Uma chave hardcoded é explorável sem ser preciso encontrar um bug, e daí vir primeiro. A CWE-798 sobrevive no histórico do git e em cada fork muito depois de apagares a linha, por isso a rotação vem antes da eliminação, não a seguir.

2. Delimita a quem chama cada endpoint que devolve dados. Abre cada handler gerado e confirma que a pesquisa filtra pelo utilizador autenticado, e não apenas por um id tirado do URL. A CWE-862 e a CWE-639 são a 4.ª e a 24.ª do CWE Top 25 de 2025, e são as falhas que o agente omite de forma mais fiável, porque nenhum teste funcional as pede.

3. Parametriza cada query e cada chamada de shell. Faz grep aos ficheiros gerados à procura de interpolação de strings numa query ou num comando. A CWE-89 é a 2.ª do CWE Top 25 e a CWE-78 é a 9.ª, e ambas estão a uma edição mecânica de serem fechadas.

4. Valida cada corpo de pedido contra um esquema, no bordo. Limites, tipos, allowlists, rejeição em caso de falha. A CWE-20 está a montante da injeção e da desserialização, por isso fechá-la fecha várias classes de uma vez, e é o passo mais barato desta lista para automatizar.

5. Substitui qualquer desserializador que corra sobre bytes não confiáveis. O pickle, o yaml.load e os desserializadores nativos transformam um blob armazenado em execução remota de código. A CWE-502 é a 15.ª do CWE Top 25, e a substituição segura é normalmente um parser tipado que já tens.

6. Tira os armazéns de credenciais do alcance do agente. Sem credenciais em texto simples no workspace que ele lê. Usa um cofre, injeta em tempo de execução, e acrescenta regras deny para ficheiros .env para que o agente não possa incluir inline o que não vê. Roda tudo o que apareceu num registo de sessão.

7. Escreve as tuas regras de segurança onde o agente as lê a cada edição. O Secure Software Development Framework do NIST (SP 800-218, versão 1.1) coloca a documentação dos requisitos de segurança no grupo Prepare the Organization, antes de existir código. A secção seguinte trata do que essas regras devem dizer.

8. Põe um gate SAST no CI e falha o build em alta severidade. Os testes funcionais passam um endpoint vulnerável mas funcional; só uma verificação consciente da segurança o não faz. Isto é deteção e não prevenção, e daí estar aqui e não no topo.

9. Escreve um teste de abuso por cada caminho de dinheiro e por cada caminho de propriedade. Uma quantidade negativa, depois o id de outra pessoa. As falhas de lógica de negócio não têm assinatura para corresponder, por isso um teste que codifica a regra é a única defesa mecânica. Aprofundamos em falhas de lógica de negócio no código gerado por IA.

10. Relê o que o agente correu, não só o que escreveu. Guarda num registo os comandos que executou. Chamadas de shell destrutivas e acessos ad-hoc a uma base de dados em produção nunca aparecem num diff, e uma revisão de código sozinha não os revela.

Os passos 1 a 5 são remediação de uma tarde, num repositório pequeno. Os passos 6 a 10 são o que impede as mesmas classes de voltarem com o próximo prompt.

O que deve dizer um prompt de segurança para vibe coding?

Deve enunciar as regras como restrições que o agente verifica antes de escrever, não como um desejo. Nomeia a interface de query, o helper de autorização e o esquema de input que o teu código já usa, e diz ao agente para recusar a edição se não os conseguir satisfazer. Regras fora do contexto do agente não se aplicam.

A forma útil é específica e mecânica. Instruções vagas ("escreve código seguro") não dão ao modelo nada para verificar. Interfaces nomeadas dão.

# Regras de segurança deste repositório

- Toda a leitura de base de dados passa por `db.query(sql, params)`. Nunca
  interpoles um valor em SQL. Se não conseguires parametrizar, para e diz.
- Todo o handler que devolve um registo filtra por `req.user.id`. Um id tirado
  do URL nunca chega por si só.
- Todo o corpo de pedido é validado pelo seu esquema zod antes de ser usado.
  Rejeita em caso de falha.
- Nunca escrevas uma credencial num ficheiro. Lê-a do ambiente.
- O dinheiro é Decimal128. As quantidades são inteiros estritamente maiores
  que zero.

Onde pões esse ficheiro importa mais do que o que lá está. No estudo controlado da CybeDefend de 24 de agosto de 2026, que correu 30 tickets de programador em triplicado para 90 execuções autónomas e 93 análises de segurança independentes, o braço que guardou estas regras num ficheiro mantido à mão no repositório teve em média 2,27 desvios de regra por ticket portador de regra. O braço sem ferramenta nenhuma teve 2,28. Escrever as regras e não fazer mais nada quase não mudou nada. O braço que recebeu as mesmas regras injetadas no momento da edição teve 0,28.

O mesmo estudo é franco quanto ao limite. Num dos tickets a regra relevante foi servida treze vezes e o agente desmontou na mesma as suas próprias proteções sob a pressão da tarefa. A injeção informa, não impõe, e é por isso que a checklist acima mantém um gate de CI e um humano por trás.

Um scanner SAST apanha vulnerabilidades de vibe coding?

Em parte. Um scanner SAST apanha uma fatia significativa, sobretudo injeção e criptografia fraca, e pertence ao CI em cada pull request. O que lhe escapa é a lógica de negócio: uma quantidade negativa que credita o carrinho é sintaticamente perfeita e não tem assinatura para corresponder. E atua depois de o código já estar escrito.

Esse segundo limite é o estrutural. O SAST, os scanners de segredos e a revisão de código leem código que já existe, e concentram-se no pull request porque é aí que a AppSec sempre viveu. Mas o PR só foi alguma vez um ponto de controlo porque um humano o lia, e à cadência do vibe coding ninguém o lê de ponta a ponta. O scanner torna-se um historiador, a documentar falhas depois de o agente as ter entregado e seguido em frente.

Lê a coluna da direita como o objetivo. Analisar não está errado; está tarde. A imposição agent-time não substitui o scanner, a revisão ou o gate de CI. Põe um controlo à frente de todos eles, de modo que a linha insegura é reescrita antes de ser sugerida, em vez de apanhada três fases depois por uma ferramenta a ler um diff que ninguém teve tempo de ler.

O que procurar numa ferramenta de segurança para vibe coding?

Duas capacidades, e a maioria das ferramentas só tem uma. A deteção encontra padrões conhecidos em código que já existe. A prevenção molda o código enquanto o agente o escreve, carregando as tuas regras no contexto dele antes de cada edição. Pergunta a um fornecedor quando atua o seu controlo: à velocidade do agente, é essa a questão toda.

A metade da deteção é um mercado resolvido. O SAST, a análise de composição de software e a análise de segredos estão maduras, e os fornecedores estabelecidos nesse espaço, a Snyk, a Checkmarx e o Semgrep entre eles, fazem-no bem. O que têm em comum é o momento em que atuam: no CI, sobre um diff, depois de o agente ter seguido em frente. A orientação secure by design da CISA, Shifting the Balance of Cybersecurity Risk, publicada com 17 parceiros internacionais, enquadra o teste de outra maneira e melhor: um fornecedor deve assumir a responsabilidade pelos resultados de segurança do cliente, em vez de lhe entregar uma lista para resolver.

É essa a lacuna que o VibeDefend preenche. É uma CLI npm gratuita que instala em cerca de cinco segundos e liga o Claude Code, o Cursor, o Windsurf, o OpenAI Codex e o GitHub Copilot a quatro camadas de governação que correm dentro do ciclo do agente, de modo que a versão segura do código é a primeira versão. Para a imagem completa em todos os agentes de código de IA, vê o nosso pilar sobre segurança de agentes de código de IA.

npx -y @cybedefend/vibedefend@latest installEscolher EU ou US, confirmar o agenteColocar .cybedefend/config.json no repositórioO próximo prompt está governado

As quatro camadas correspondem aos modos de falha que este guia nomeou. As Business Rules são as convenções extraídas do teu repositório (o dinheiro é Decimal128, a autorização passa por requireOwner), carregadas no agente antes de cada edição para que as falhas de lógica de negócio nunca cheguem a ser escritas. As Security Rules levam o OWASP Top 10 e as famílias de regras de conformidade que ativares para dentro do código à medida que é escrito, de modo que a injeção, a validação em falta e a autorização quebrada encontram uma regra na autoria em vez de uma caixa a marcar na auditoria. O Action Guard interceta chamadas destrutivas antes de dispararem: ao longo do estudo de agosto verificou 1769 comandos de shell e recusou 17, dos quais 1 era uma tentativa real de aceder a uma credencial armazenada, 3 estavam corretos face à política e 13 eram falsos positivos que custaram um turno cada. As Live Findings ligam o agente à plataforma da CybeDefend, com o SAST com alcançabilidade, a SCA, os segredos, o IaC e o CI/CD a correr continuamente, de modo que o agente também tria e corrige as vulnerabilidades que já tens. Nada do teu código atravessa a rede: as decisões acontecem localmente ao lado do agente, e só metadados de governação estruturados (a regra que disparou, o caminho do ficheiro, a severidade, um timestamp) chegam ao backend. As regiões da EU e dos US são fisicamente separadas e escolhes uma na instalação.

Medida nos mesmos 30 tickets, a camada deixou 0,033 novas descobertas de análise estática por tarefa, contra 0,10 sem ferramenta, e todas foram corrigidas dentro da tarefa que as introduziu. Uma ressalva honesta viaja com esse número: o estudo mediu bases de código que começaram limpas, por isso descreve o manter a zero, não a redução de um backlog que já tens.

Perguntas frequentes

O vibe coding é seguro?

Não por omissão. Uma auditoria arXiv de 2026 a 200 aplicações de vibe coding em produção encontrou pelo menos uma vulnerabilidade em 91,0% delas, e o benchmark SusVibes concluiu que apenas 11,8% das soluções dos agentes eram seguras, face a 57% funcionalmente corretas. Torna-se seguro de fazer quando acrescentas um controlo que atua no momento da autoria, dás ao agente as tuas regras no contexto dele, manténs um humano no circuito, e proteges os pull requests com SAST. Sem isso, entrega o OWASP Top 10 à velocidade da máquina.

Quais são as vulnerabilidades de vibe coding mais comuns?

As classes recorrentes são segredos hardcoded (CWE-798), autorização quebrada e IDOR (CWE-862, CWE-639), injeção (CWE-89 para SQL, CWE-78 para comandos), validação de input em falta (CWE-20), desserialização insegura (CWE-502), e falhas de lógica de negócio. A auditoria arXiv de 2026 encontrou as suas 1186 descobertas concentradas em controlo de acesso quebrado, injeção e falhas de autenticação. Nenhuma é nova: são os clássicos da OWASP, reproduzidos mais depressa do que a revisão consegue acompanhar.

Porque é que o código gerado por IA tem tantas falhas de segurança?

Dois mecanismos agravam-se e um terceiro decide. O modelo aprendeu com um corpus público cheio de padrões inseguros, por isso inseguro por omissão é o seu a priori. A segurança é normalmente uma proteção que está presente, e um modelo a quem se pede um resultado positivo não acrescenta uma verificação negativa que ninguém pediu. Depois, quem dá o prompt vê se a funcionalidade funciona mas raramente se é segura, por isso a falha passa a revisão. Acrescentar pistas de vulnerabilidade ao pedido não resolveu o problema nos testes do SusVibes.

Um não programador consegue fazer vibe coding com segurança?

Apenas com um controlo que não dependa de a pessoa ler as implicações de segurança, porque é exatamente essa a competência que um não programador não tem. Um scanner que produz descobertas a triar assume que o leitor as consegue interpretar. Uma camada agent-time que carrega as regras no agente e reescreve a linha insegura antes de ela aterrar remove essa dependência: o padrão seguro passa a ser o valor por omissão do agente, e a segurança deixa de assentar na capacidade de quem dá o prompt para detetar uma autorização em falta.

O vibe coding é seguro para uma aplicação em produção?

Não sem os controlos da checklist acima. A auditoria arXiv de 2026 olhou para aplicações publicamente em produção, e não para projetos de brincar: 91,0% das 200 que auditou tinham pelo menos uma vulnerabilidade, com cerca de dois terços das descobertas classificadas como Critical ou High. A produção agrava exatamente as classes que os agentes omitem: um endpoint sem delimitação expõe registos reais de clientes, e uma chave hardcoded num repositório público é explorável no instante em que lhe fazes push.

Um scanner SAST apanha vulnerabilidades de vibe coding?

Apanha uma fatia significativa delas, sobretudo injeção e criptografia fraca, e pertence ao CI em cada pull request. O que falha em grande parte é a lógica de negócio, porque um desconto de quantidade negativa ou um reembolso que salta a verificação de propriedade é sintaticamente perfeito e semanticamente errado, sem assinatura para corresponder. É também reativo: atua depois de o código ser escrito, o que à velocidade do vibe coding significa depois da entrega. Combina a deteção no CI com a prevenção no momento da autoria.

Qual é o controlo mais eficaz para vibe coding seguro?

Mover o ponto de controlo de segurança do pull request para o prompt. A deteção que corre depois de o código existir lê sempre histórico, porque ninguém revê milhares de linhas geradas de ponta a ponta. No estudo controlado da CybeDefend, as regras guardadas num ficheiro do repositório deixaram 2,27 desvios por ticket portador de regra, contra 2,28 sem ferramenta nenhuma, enquanto as mesmas regras injetadas no momento da edição deixaram 0,28. Tudo o resto é defesa em profundidade por trás disso.

Por onde começo a proteger um projeto de vibe coding existente?

Começa pelos passos 1 a 3 da checklist acima: roda as credenciais que o agente possa ter lido e analisa o histórico à procura de mais, audita cada endpoint que devolve dados em busca de uma verificação delimitada a quem chama, e fecha os pontos de injeção. Acrescenta ao CI um gate de SAST que falha em alta severidade, e põe uma camada agent-time à frente para que o código novo seja governado à medida que é escrito. Para de acrescentar falhas primeiro, depois reduz o backlog que os prompts iniciais deixaram para trás.