O que é Vibe Coding Security? Riscos, Exemplos e Como Manter-se Seguro

A codificação Vibe é a novidade do momento. Talvez já a tenha visto em ação:

• Um vendedor cria a sua própria ferramenta com IA.
• Um designer envia alterações na interface do utilizador diretamente para o GitHub.
  
• Uma equipa de marketing escreve software de campanha em vez de renovar um contrato com um fornecedor.
  

Como Steve Yegge disse no podcast The Pragmatic Engineer, a IA abriu novas portas. O código já não vem apenas dos programadores. Qualquer pessoa com um prompt pode lançar uma aplicação. A maioria das pessoas que faz isso nem sabe que está a programar por intuição. Elas estão apenas a descrever o que querem em linguagem simples e a deixar a IA gerar o código. Essa mudança alterou quem cria software e a rapidez com que ele é lançado. Essa velocidade é empolgante, mas também traz um problema sério. A maior parte desse código está a ser executada às cegas, sem revisões, sem testes e sem segurança.

O que é a codificação Vibe?

A codificação Vibe consiste em descrever o que se deseja em linguagem simples e deixar que uma IA gere o código para si. Plataformas como Lovable, Windsurf e Replit apresentam-se como ferramentas que permitem a qualquer pessoa passar da ideia à aplicação em poucas horas. Parece mágico, porque não é necessário ter conhecimentos técnicos de sintaxe nem formação formal. Basta dizer o que se deseja, copiar e colar, executar e ver se funciona.

É rápido e sem atritos, e é por isso que se espalhou para além das equipas de engenharia. Designers, profissionais de marketing e equipas de vendas agora podem lançar aplicações ou funcionalidades sem esperar pelos programadores.

O problema é que a codificação vibrante prioriza a produção em detrimento da segurança. Na maioria das vezes, não há revisões, testes nem segurança incorporada. É aí que começam os problemas.

Quando o clima fica desagradável

Há vários exemplos de codificação de vibração que deram errado:

• Incidente com a Replit: Jason Lemkin, da SaaStr, confiou no agente de IA da Replit para criar uma aplicação de nível de produção. No início, foi emocionante: protótipos em poucas horas, verificações de controle de qualidade, progresso rápido. Então, as coisas começaram a dar errado. A IA começou a mentir sobre testes de unidade, ignorou congelamentos de código e, por fim, excluiu todo o banco de dados de produção da SaaStr. Meses de registros executivos cuidadosamente selecionados desapareceram da noite para o dia. Como Lemkin disse à ZDNet, “não se pode sobrescrever um banco de dados de produção. Não, nunca, jamais”. ‍
• Aplicação Tea: rotas de administração deixadas desbloqueadas, expondo os dados dos utilizadores a qualquer pessoa que acedesse ao ponto final. O que parecia ser uma experiência divertida rapidamente se tornou um risco para a privacidade dos dados.
  

Uma proporção considerável de aplicações criadas por programadores amadores contém vulnerabilidades graves antes mesmo de serem lançadas; se experimentasse dez aplicações criadas dessa forma, é provável que pelo menos uma delas fosse vulnerável a ataques.

Essas falhas são importantes porque as falhas de segurança em aplicações codificadas por vibe não são apenas pequenos bugs. Frequentemente, envolvem proteções essenciais, como autenticação, acesso a dados e secrets . Se uma aplicação lida com pagamentos ou dados pessoais, as consequências não são apenas técnicas. São financeiras, regulatórias e de reputação.

Mackenzie Jackson, defensor dos programadores na Aikido , é direto:

«A IA não escreve código seguro por predefinição. Apenas produz algo que funciona. Por baixo do capô, pode estar totalmente exposta a ataques.»

Por que isto se espalha rapidamente

A principal diferença com a codificação vibe é que agora todos estão a fazê-lo. Designers, gestores de produto, equipas de vendas e marketing estão todos a enviar código. Os invasores não se importam se é um projeto paralelo ou software empresarial. Eles só se importam se a porta estiver destrancada.

A velocidade é uma vantagem, mas também é um problema. Um aplicativo que antes levava semanas para ser desenvolvido agora pode ser criado em uma tarde. Isso significa que toda uma equipa pode criar protótipos e ferramentas sem esperar pela engenharia. O problema é que nenhum desses novos programadores está a pensar em controlos de acesso, sanitização de entradas ou atualizações de dependências.

Willem Delbare, fundador e diretor técnico da Aikido, descreveu essa mudança à ZDNet como uma tempestade perfeita:

“A codificação Vibe torna o desenvolvimento de software mais acessível, mas também cria uma tempestade perfeita de riscos de segurança que nem mesmo desenvolvedores experientes estão preparados para lidar. Injeções SQL, traversal de caminho, secrets codificados.” 

Mackenzie Jackson alerta que a situação vai piorar. Como ele disse ao TechMonitor:

«Mais pessoas sem uma sólida formação em engenharia ou segurança estão a usar essas ferramentas para criar software... o que significa que acabaremos com ainda mais código gerado por IA que ninguém realmente analisou com cuidado.»

É assim que a programação vibrante acaba se tornando o que Mackenzie chama de «vulnerabilidade como serviço». Quanto mais rápido profissionais sem formação lançam aplicativos com IA, mais rápido as falhas de segurança se multiplicam na web.

Garantindo as vibrações

Já publicámos uma Lista de Verificação de Segurança da Vibe Coders para pessoas que estão a desenvolver. Ela abrange o básico: autenticação, sanitização de entradas, verificação e secrets .

Mas o ponto mais importante aqui é a conscientização. Se você está a experimentar a codificação de IA, ou se a sua equipa está, precisa reconhecer que o protótipo brilhante que você lança numa tarde também pode ser a porta dos fundos que permite a entrada de invasores.

O que as equipas podem fazer?

• Trate o código de IA como se tivesse sido escrito por um programador júnior: revise, teste e bloqueie-o.
  
• Terceirize a autenticação para serviços criados para isso, em vez de desenvolver o seu próprio.
  
• Mantenha secrets do frontend e dos repositórios.
  
• Não se limite a executar análises. Pense realmente nas falhas lógicas.
  

Parece óbvio, mas a maioria dos programadores de vibração não o faz. É por isso que a segurança tem de fazer parte da conversa, mesmo para funções fora da engenharia.

O que é codificação agênica?

A codificação agênica é o passo além da codificação vibracional. Em vez de pedir trechos a uma IA e colá-los, os agentes de IA assumem o processo de escrever, executar e modificar o código automaticamente. Eles podem instalar dependências, executar testes, refatorar ficheiros e até mesmo atualizar a infraestrutura.

Esta abordagem é mais utilizada por programadores e equipas técnicas do que por utilizadores casuais, o que a torna mais confiável. O problema é que essa confiança é equivocada. A codificação agênica cria um código mais limpo e com aparência mais profissional, mas essa aparência esconde os riscos.

Codificação Agente Acelera

Enquanto a codificação por vibração frequentemente cria código confuso e obviamente frágil, a codificação por agente produz código que parece impecável. Isso faz parte do perigo. Uma única decisão errada pode repercutir em todo o sistema e se espalhar por dependências e ambientes antes que alguém perceba.

As ferramentas de IA estão a produzir mais desse código mais rapidamente do que nunca, e nenhum deles é seguro por padrão. Código limpo é mais fácil de enviar e reutilizar, o que significa que as vulnerabilidades se espalham silenciosamente e rapidamente.

A única maneira de controlar o risco é detectar os erros antes que eles entrem em produção. Isso significa conectar-se diretamente aos pipelines de CI/CD, verificar todas as dependências e validar as suposições com feedback imediato.

O que os CISOs precisam de ter em consideração

Para os líderes de segurança, a codificação vibrante não é apenas uma tendência dos programadores. Ela está a mudar a forma como o software é desenvolvido em toda a organização. O trabalho do CISO está a mudar de impor restrições para projetar barreiras de proteção que permitem que as pessoas experimentem sem prejudicar a produção.

Algumas ideias-chave a ter em conta:

• MTTG (Tempo médio até orientação)
  Métricas tradicionais como MTTD e MTTR medem o que acontece depois que algo dá errado. O MTTG mede a rapidez com que os programadores da Vibe obtêm orientações práticas antes que o seu código se torne uma vulnerabilidade. Quanto menor o MTTG, menos incidentes ocorrem.
  
  
• PromptBOMs
  Pense em SBOMs, mas para código de IA. Um registo simples do modelo, prompt e parâmetros que geraram um trecho. Se algo falhar, você sabe de onde veio e porquê. Proveniência é igual a responsabilidade.
  
  
• Níveis de garantia de codificação Vibe (VCAL 0–5)
  Semelhante aos níveis de condução autónoma, mas para codificação assistida por IA. VCAL-1 significa que a IA está apenas a sugerir. VCAL-3 adiciona proteções e captura de proveniência. VCAL-5 é uma fusão totalmente autónoma para alterações de baixo risco com atestado contínuo. A estrutura oferece aos CISOs uma maneira de calibrar as expectativas em vez de reagir cegamente.
  

Conclusão: não tente ensinar todos os funcionários a «fazer segurança». Em vez disso, forneça uma experiência de segurança invisível, integrada e adaptada à forma como as pessoas realmente trabalham com IA.

Conclusão 

A codificação Vibe não vai desaparecer. O código está a ser escrito na velocidade da IA por pessoas dentro e fora da engenharia. Se não planear a segurança, não estará apenas a avançar rapidamente, mas também a espalhar vulnerabilidades com a mesma rapidez.

O ambiente está bom. Só não se esqueça da verificação de segurança.

Quer saber os passos práticos? Leia a Lista de Verificação de Segurança da Vibe Coders.