Levantamento com 334 apps de Lovable, Bolt e v0 acha falha de segurança em 32% antes do lançamento

A Axonscape, criadora da ferramenta Launchpad, rodou um teste de prontidão para lançamento em 334 repositórios públicos no GitHub gerados por Lovable, Bolt e v0, escolhidos aleatoriamente entre os atualizados nos últimos dois meses. O teste lê o código em busca do que quebra ou vaza quando o app vai para produção: nada de rodar a aplicação, só análise estática do repositório.

O resultado: 32% dos apps tinham pelo menos uma coisa para corrigir antes do lançamento. A pontuação mediana ficou em 80/100, e só 33% dos repositórios cruzaram a barra de 90 pontos que a Axonscape considera pronto para ir ao ar. Para quem usa agente de código para sair do zero ao deploy em um fim de semana, o número é um alerta direto: o agente entrega a funcionalidade, mas não necessariamente entrega a aplicação pronta para receber tráfego real.

O que os apps vazavam

A lista de problemas encontrados é bem específica, e quase toda ela gira em torno de segredo e permissão de banco:

• Arquivo .env commitado no repositório: 23% dos apps.
• Policies que deixam qualquer um alterar dado: 19% dos apps (regra de acesso aberta demais no banco).
• Tabelas sem Row Level Security: 7% dos apps.
• Chave administrativa do Supabase usada em código de browser: 6% dos apps.
• Segredos expostos ao browser (fora a chave de admin): 1% dos apps.
• Chave secreta commitada no repositório: 1% dos apps.

Repare no padrão: a maioria dos furos não é um bug exótico de lógica, é configuração de acesso que o agente de código gerou do jeito mais fácil de fazer funcionar na hora — e que ninguém voltou para apertar antes do deploy. .env commitado é o clássico "esqueci de colocar no .gitignore"; policy aberta é o clássico "desliguei a trava pra parar de dar erro 403 e testar mais rápido".

Por ferramenta, resultados bem diferentes

A Axonscape separou os números por ferramenta, e a diferença entre elas é grande o suficiente para valer a tabela:

O próprio levantamento faz questão de avisar: isso compara o que os usuários de cada ferramenta publicam, não as ferramentas em si, porque elas tendem a gerar tipos de app diferentes (Lovable puxa mais para produto completo com banco e autenticação desde o primeiro prompt, enquanto v0 nasce mais perto do front-end). Ainda assim, um salto de 7% para 79% de apps com pendência não se explica só por tipo de app: sugere que o fluxo padrão do Lovable deixa mais superfície de banco exposta por padrão do que o usuário médio sabe fechar sozinho.

Traduzindo para quem deploya na AWS

O estudo original mede apps com Supabase, mas quem tira o mesmo app de uma sessão de Claude Code, Cursor ou Kiro para rodar em Lambda, ECS ou Amplify encontra a mesma família de erro, só que com outro nome de serviço. A tradução direta:

• .env commitado no Supabase vira access key e secret key da AWS hardcoded no código que o agente gerou para chamar o SDK direto do bundle do browser, em vez de passar por um backend.
• Policy aberta que deixa qualquer um alterar dado vira policy do IAM com "Action": "*" e "Resource": "*" que o agente escreveu só para parar de tomar AccessDenied enquanto testava.
• Tabela sem Row Level Security vira bucket do S3 sem Block Public Access ou tabela do DynamoDB acessível por qualquer identidade autenticada do Cognito, sem checar o dono do registro.
• Chave administrativa usada no browser vira IAM user de longa duração (em vez de role) embutido no front-end, geralmente porque o agente achou mais rápido colar a credencial do que configurar Cognito Identity Pool ou uma Lambda Function URL com authorizer.

Nenhum desses pontos está no material da Axonscape, que fala especificamente de Supabase. É leitura própria, mas o raciocínio é direto: o agente de código otimiza para "funcionar agora", e a forma mais rápida de fazer uma chamada autenticada funcionar quase sempre é a forma mais aberta. Isso vale tanto para RLS do Postgres quanto para policy do IAM.

O checklist antes de dar push to production

Para quem vai promover um protótipo gerado por agente para um ambiente real na AWS, o equivalente ao que a Axonscape cobra do Supabase é:

1. Rode git log --all -- .env e git log --all -p | grep -i AKIA no repositório inteiro, não só no HEAD: chave commitada e depois removida continua no histórico.
2. Abra toda policy do IAM gerada pelo agente e procure * em Action ou Resource; troque por permissão específica ao recurso que a função realmente usa.
3. Rode aws s3api get-bucket-policy-status em todo bucket criado pela sessão e confirme que IsPublic está false, a menos que o bucket seja mesmo de conteúdo público.
4. Troque toda IAM access key de usuário por role assumida (Lambda execution role, ECS task role, ou Cognito Identity Pool para o front-end), e mova segredo que ainda precisa existir para o Secrets Manager ou o Parameter Store.
5. Se o app usa API Gateway ou Lambda Function URL, confirme que existe um authorizer (Cognito, IAM ou Lambda custom) antes de liberar a rota publicamente.

Nenhum desses passos é exótico; é o tipo de coisa que um engenheiro sênior faz de cabeça antes de aprovar um PR. O problema é que quem está vibe coding sozinho, sem esse par de olhos, não tem o hábito ainda, e o agente não avisa.

Os limites do estudo

Vale registrar o que a própria Axonscape admite: repositório público no GitHub não é sinônimo de app no ar, e a checagem lê só o código, não o que foi configurado depois no painel do Supabase (ou, no caso da AWS, no console). Um app pode ter .env commitado no repositório e ainda assim ter rotacionado a chave de verdade em produção, ou ter uma policy aberta no código mas sobrescrita por uma regra mais restritiva aplicada manualmente fora do repositório.

Ainda assim, 334 repositórios escolhidos ao acaso, nos últimos dois meses, é amostra grande o suficiente para não ser ruído: um em cada três apps gerados com os agentes mais populares do mercado tinha algo que um revisor humano teria pego antes do deploy. A Axonscape mantém o relatório completo em launchpad.axonscape.com/report, atualizado mensalmente, e oferece a mesma checagem de graça para quem quiser rodar no próprio app antes de publicar.

Fonte: DEV Community — #vibecoding