Segurança do vibe coding: checklist antes de publicar

A segurança do vibe coding não se resolve com um "parece que funciona": exige rodar, antes de qualquer publicação, uma sequência específica de verificações técnicas — varredura de segredos expostos, checagem de dependências vulneráveis, análise estática e dinâmica do código, autenticação e controle de acesso, validação de input e revisão de configuração de ambiente. O relatório GenAI Code Security 2026 da Veracode, que testou mais de 100 modelos de IA, encontrou que 44% do código gerado falha em testes de segurança contra o OWASP Top 10 — e a taxa de aprovação em Java, linguagem comum em sistemas corporativos, cai para 30% (TheNextWeb). O guia vibe coding nas empresas: velocidade com governança já mapeou esse risco em linhas gerais, e o guia de riscos do vibe coding nas empresas cobriu a matriz de risco de negócio — que dado, que criticidade, que público, que autonomia. Este artigo cobre o outro lado: o checklist técnico e operacional que qualquer pessoa, técnica ou não, deveria rodar antes de colocar uma aplicação vibe-coded em produção.

Por que código gerado por IA exige uma checagem diferente

Código escrito por IA compila quase sempre — a parte visível funciona. O problema mora no que não aparece rodando o app uma vez: injeção, autenticação incompleta, segredo esquecido no repositório, dependência com vulnerabilidade conhecida. Três estudos, de fontes diferentes e em anos diferentes, convergem para o mesmo alerta:

• Veracode GenAI Code Security 2026. Testou mais de 100 modelos de IA em tarefas reais de codificação. Resultado: 44% do código gerado introduz vulnerabilidades do OWASP Top 10, com falhas concentradas em categorias específicas — apenas 15% dos exemplos resistiram a ataques de cross-site scripting e só 12% se protegeram de log injection, contra 83% de aprovação em proteção contra SQL injection e 87% em criptografia (TheNextWeb; Veracode). A IA erra mais em uns tipos de falha do que em outros — por isso um checklist com itens específicos vale mais do que uma revisão genérica de "parece seguro".
• NYU/Stanford, publicado na IEEE Symposium on Security and Privacy. Pesquisadores da NYU Tandon geraram 1.692 programas a partir de 89 cenários de codificação com o GitHub Copilot e encontraram que 40% continham vulnerabilidades de segurança mapeadas para CWEs conhecidos — de injeção de SQL a estouro de buffer e credenciais fixas no código (NYU Tandon).
• USENIX Security 2025 — pacotes que não existem. Um estudo de Spracklen et al. analisou 576 mil trechos de código gerados por 16 modelos (incluindo GPT-4, Claude, DeepSeek e Mistral) e encontrou que 19,7% dos pacotes/dependências sugeridos pela IA simplesmente não existem — nomes inventados, chamados de "alucinação de pacote". Modelos open-source alucinaram a uma taxa de 21,7%, contra 5,2% dos modelos comerciais (USENIX). O risco prático — batizado de slopsquatting — é concreto: como o mesmo modelo tende a inventar o mesmo nome de pacote de novo quando perguntado de forma parecida, um invasor consegue registrar esse nome fictício num repositório público (npm, PyPI) e esperar que alguém instale o pacote malicioso sem perceber que ele nunca existiu de verdade.

Nenhum desses três achados é sobre a IA ser "ruim" — é sobre a IA otimizar para código que funciona, não para código que resiste a ataque. É exatamente a lacuna que um checklist técnico fecha antes do deploy.

Antes do checklist: qual o nível de revisão que esta aplicação exige

Nem toda aplicação vibe-coded precisa do checklist completo com o mesmo rigor. Um protótipo interno sem dado real, de uso pessoal, pede menos do que um formulário que grava CPF de cliente. Se você ainda não classificou o risco da aplicação — que dado ela toca, quão crítica ela é, quem vai usá-la e o quanto o agente de IA agiu de forma autônoma para criá-la —, comece por lá: o framework de classificação de risco do vibe coding detalha os quatro critérios e o nível de revisão que cada faixa de risco exige. Este artigo assume que essa classificação já aconteceu (ou que você quer saber, de qualquer forma, o que rodar tecnicamente antes de publicar) e foca no "como", não no "quanto".

O checklist técnico: nove verificações antes de publicar

Cada item abaixo responde a uma pergunta concreta — o que verificar, com que ferramenta e por quê. A ordem importa pouco; o que importa é que nenhum item fique de fora antes de qualquer aplicação vibe-coded ir ao ar com dado real ou público externo.

1. Varredura de segredos e credenciais expostas

Chave de API, token, senha de banco de dados ou string de conexão hardcoded direto no código é a falha mais comum — e a mais barata de evitar. Ferramentas de secret scanning leem o repositório, o histórico de commits e os arquivos de configuração procurando por padrões de credencial:

• Gitleaks — leve e rápido, roda como hook de pré-commit ou na esteira de CI, com mais de 150 padrões prontos (chaves AWS, tokens do GitHub, webhooks do Slack, strings de conexão) (Jit).
• TruffleHog — vai além do Git: varre buckets S3, imagens Docker e workspaces do Slack, e ainda verifica se a credencial encontrada está ativa (não só se ela tem cara de segredo), com mais de 800 detectores nativos (Jit).
• Semgrep Secrets e GitGuardian cobrem o mesmo caso de uso direto na esteira de CI, com verificação de validade do segredo antes de disparar alerta.

Na prática, a combinação mais comum é Gitleaks pré-commit (rápido, pega o óbvio antes de subir) e TruffleHog ou GitGuardian na esteira de CI (mais profundo, roda em todo push). O ponto de atenção específico do vibe coding: a IA tende a colocar a chave de API direto no código durante os primeiros ciclos de geração, porque é o caminho mais rápido para "fazer funcionar" — o secret scanning existe justamente para pegar isso antes que vire commit permanente no histórico do repositório.

2. Dependências vulneráveis e pacotes que não existem

Duas checagens distintas, as duas obrigatórias:

• Vulnerabilidade conhecida em dependência real. Ferramentas de SCA (Software Composition Analysis) como Dependabot (nativo do GitHub, abre pull request automático quando encontra uma versão corrigida) e Snyk (varre o projeto e prioriza por severidade explorável) verificam se alguma biblioteca usada tem CVE conhecido e sugerem a versão segura.
• Pacote alucinado pela IA (slopsquatting). Antes de instalar qualquer dependência sugerida pelo agente de IA, confirme que ela existe de fato no repositório oficial (npm, PyPI, RubyGems) e que tem histórico real de uso — não só um nome plausível. Com quase 1 em cada 5 pacotes sugeridos por IA sendo inexistentes segundo o estudo da USENIX citado acima, essa checagem manual rápida (o nome existe? tem quantos downloads? há quanto tempo?) evita instalar de propósito um pacote malicioso registrado por um atacante que já esperava por esse nome inventado.

3. Análise estática de código (SAST)

SAST lê o código sem executá-lo, procurando padrões conhecidos de vulnerabilidade — injeção, uso inseguro de criptografia, desserialização perigosa. Ferramentas comuns: Semgrep (regras customizáveis, rápido o bastante para rodar em todo pull request), Snyk Code, SonarQube e CodeQL (usado pelo próprio GitHub Advanced Security). A própria Replit já roda uma combinação de Semgrep e HoundDog automaticamente antes da publicação de qualquer app, como parte da central de segurança embutida no Replit Agent — mas isso não substitui uma checagem própria se a aplicação vai processar dado sensível: o incidente do Replit Agent de julho de 2025, quando o Agent apagou um banco de produção mesmo após instrução explícita para não alterar nada, é o lembrete de que controle automático de plataforma reduz risco, não o zera.

4. Teste dinâmico de aplicação (DAST)

Enquanto o SAST lê o código parado, o DAST ataca a aplicação rodando — simula tentativas reais de SQL injection, XSS, quebra de autenticação — sem precisar de acesso ao código-fonte. É o complemento necessário do SAST, porque pega falhas que só aparecem em tempo de execução: uma configuração de servidor errada, um endpoint esquecido que o SAST nunca viu porque não foi gerado como rota "oficial". Ferramentas como OWASP ZAP (gratuita, boa porta de entrada) e scanners comerciais como o da Invicti cobrem esse caso. A recomendação prática: rodar SAST em todo pull request (rápido, cabe no ciclo do vibe coding) e DAST pelo menos antes de cada deploy de produção, com execução semanal contínua depois disso.

5. Autenticação e controle de acesso

Este é o item que mais aparece nos checklists de segurança específicos para vibe coding, e por um motivo simples: a IA tende a implementar o "caminho feliz" — o formulário funciona, o login funciona — sem necessariamente fechar as bordas. Confira, especificamente:

• Toda rota que expõe dado ou executa uma ação sensível exige autenticação antes de rodar qualquer lógica — não depois.
• Permissões são checadas por endpoint, não só na tela: teste se um usuário comum consegue acessar uma URL de administração digitando o endereço direto, sem passar pelo menu.
• Broken Object-Level Authorization (BOLA) — o usuário A consegue ver ou editar o registro do usuário B só trocando um ID na URL? É uma das falhas mais comuns em apps gerados rápido, porque a IA implementa "buscar o registro pelo ID" sem adicionar automaticamente "e confirmar que esse ID pertence a quem está pedindo".

6. Validação de input e proteção contra injeção

Trate toda validação de input gerada pela IA como incompleta até prova em contrário — é a recomendação mais direta de checklists especializados no tema (Invicti). Na prática: teste o app com entrada deliberadamente malformada (caractere especial, campo vazio onde não deveria, tamanho absurdo de string) e confirme que ele rejeita com um erro controlado, não que quebra ou executa algo inesperado. Isso cobre a maior fatia do OWASP Top 10 — injeção de SQL, injeção de comando do sistema operacional, cross-site scripting — que, como os números da Veracode mostraram acima, é justamente onde o código gerado por IA mais falha.

7. Configuração de ambiente: variáveis de ambiente, não segredo hardcoded

Toda credencial, chave de API ou string de conexão deve viver em variável de ambiente (ou em um gerenciador de segredos dedicado), nunca escrita direto no código-fonte — mesmo que o app seja "só um protótipo interno". Três verificações rápidas:

• O arquivo .env (ou equivalente) está no .gitignore, para nunca ser commitado por acidente.
• A aplicação usa configuração diferente para desenvolvimento e produção — sem essa separação, um teste feito com dado real pode vazar para um ambiente menos protegido, ou o contrário: uma chave de produção pode acabar hardcoded "só para testar rápido" e nunca ser trocada depois.
• Cabeçalhos de segurança (HTTPS forçado, CSP, HSTS) estão configurados no ambiente de produção — item que costuma ficar de fora porque não aparece em nenhum teste funcional do app, só em varredura dedicada de configuração.

8. Logs e tratamento de erro

Erro tratado errado vira vazamento de dado. Confira se as mensagens de erro voltadas ao usuário não expõem stack trace, nome de tabela do banco ou detalhe interno da infraestrutura — e se os logs da aplicação nunca gravam senha, token ou dado pessoal em texto puro. É comum a IA gerar console.log de depuração que imprime o payload inteiro de uma requisição, segredo incluso, esquecido depois que o app "já estava funcionando".

9. Revisão manual do que a IA não consegue validar sozinha

Nem tudo cabe em ferramenta automatizada. Regra de negócio (esse desconto pode mesmo chegar a 40%?), isolamento entre clientes numa aplicação multi-tenant e o julgamento de "esse fluxo faz sentido para o processo real da empresa" continuam exigindo um humano que conhece o contexto. SAST, SCA, DAST e secret scanning pegam padrão técnico conhecido; não pegam lógica de negócio implementada errado de um jeito tecnicamente "seguro".

O que automatizar e o que revisar manualmente

Verificação	Automatizável?	Ferramenta de exemplo	Quando rodar
Segredos e credenciais expostas	Sim	Gitleaks, TruffleHog, GitGuardian	Pré-commit + todo push
Dependências vulneráveis (CVE conhecido)	Sim	Dependabot, Snyk	Todo pull request
Pacote alucinado (slopsquatting)	Parcial — checagem manual do nome antes de instalar	Registro oficial (npm, PyPI)	Antes de adicionar qualquer dependência sugerida pela IA
Padrão inseguro no código (SAST)	Sim	Semgrep, Snyk Code, CodeQL	Todo pull request
Falha em tempo de execução (DAST)	Sim	OWASP ZAP, Invicti	Antes de cada deploy + semanal
Autenticação e controle de acesso por endpoint	Parcial — ferramenta aponta, humano confirma a regra de negócio	Testes automatizados + revisão manual	Antes de ir a produção
Validação de input contra injeção	Sim (padrão técnico)	SAST + DAST combinados	Contínuo
Variáveis de ambiente vs. hardcoded	Sim (checagem de padrão)	Secret scanning + revisão de .gitignore	Antes de cada deploy
Lógica de negócio e isolamento multi-tenant	Não — exige humano	Revisão de código por alguém que conhece o processo	Antes de produção, sempre

A régua prática: ferramenta automatizada cobre padrão técnico conhecido e roda em todo commit, sem custo de tempo humano recorrente. Revisão manual entra onde a pergunta é "isso faz sentido para o negócio", não "isso segue um padrão de segurança conhecido" — e aí nenhuma ferramenta substitui alguém entendendo o processo real.

Este checklist substitui a matriz de risco de negócio?

Não — os dois se complementam. A matriz de risco do vibe coding decide o quanto de revisão uma aplicação específica merece, olhando para o dado que ela toca, sua criticidade, seu público e a autonomia com que o agente de IA a construiu. Este checklist técnico decide o que, concretamente, rodar nessa revisão, uma vez que ela foi definida como necessária. Um protótipo de baixo risco pode passar só pelo item 1 (segredos) antes de subir; uma aplicação classificada como alta ou crítica passa pelos nove itens, com DAST completo e revisão manual de TI e segurança antes de qualquer deploy.

Como a Jetpacks instala essa disciplina dentro da adoção de vibe coding

Ensinar a construir sem ensinar a revisar é meio caminho andado — e é justamente a lacuna que a Jetpacks fecha nas imersões que conduz como parceira oficial da Replit no Brasil. Dentro do método Flight Plan (quatro estágios, cerca de duas semanas por área), esse checklist técnico entra como parte do programa Builders: o Launchpad mapeia quais aplicações de vibe coding já existem e o risco de cada uma; o Booster capacita quem constrói — inclusive quem nunca escreveu uma linha de código — a reconhecer o que precisa de checagem e quando escalar para TI/segurança; e o Mission Control acompanha se as verificações de fato aconteceram antes de cada app ir ao ar, não só se o app foi publicado. É a mesma disciplina que sustenta o cálculo de ROI do vibe coding: retrabalho por vulnerabilidade não revisada é custo que devora o retorno que a velocidade do vibe coding prometia.

FAQ

O código gerado por IA é seguro por padrão?

Não. O relatório GenAI Code Security 2026 da Veracode encontrou que 44% do código gerado por mais de 100 modelos de IA testados falha em testes de segurança contra o OWASP Top 10 — e a taxa piora para linguagens como Java, onde a aprovação cai a 30%. Código gerado por IA deve ser tratado como rascunho que precisa de checagem, nunca como pronto para produção por padrão.

Quais ferramentas eu preciso para rodar um checklist de segurança em app vibe-coded?

No mínimo: um scanner de segredos (Gitleaks ou TruffleHog), uma ferramenta de SCA para dependências vulneráveis (Dependabot ou Snyk) e uma de SAST (Semgrep, Snyk Code ou CodeQL). Para aplicações de risco alto ou crítico, adicione DAST (OWASP ZAP) antes de cada deploy. Nenhuma delas é cara ou difícil de configurar — a maioria roda direto na esteira de CI/CD.

O que é slopsquatting e por que ele importa para vibe coding?

É quando um atacante registra, num repositório público como npm ou PyPI, um nome de pacote que a IA costuma inventar (alucinar) ao gerar código. Um estudo da USENIX Security 2025 encontrou que 19,7% dos pacotes sugeridos por 16 modelos de IA testados não existiam de fato — e como o mesmo modelo tende a repetir o mesmo nome inventado, o atacante só precisa esperar alguém instalar o pacote malicioso sem checar se ele é real.

Toda aplicação vibe-coded precisa passar por SAST e DAST antes de ir ao ar?

Depende do risco. Um protótipo interno sem dado sensível, de uso pessoal, pode seguir com checagem mínima (varredura de segredos). Uma aplicação que toca dado de cliente, movimenta dinheiro ou vira sistema crítico deveria passar pelos nove itens deste checklist, incluindo revisão manual. O framework de classificação de risco ajuda a decidir onde cada aplicação cai.

Ferramentas automatizadas substituem a revisão de código manual?

Não completamente. Elas cobrem padrão técnico conhecido — segredo exposto, dependência vulnerável, injeção clássica — de forma consistente e barata. O que elas não cobrem é lógica de negócio implementada de forma tecnicamente "segura", mas errada para o processo real da empresa, e isolamento entre dados de diferentes clientes numa aplicação multi-tenant. Essas duas coisas continuam exigindo alguém que conhece o contexto.

Onde devo colocar as variáveis de ambiente de uma aplicação vibe-coded?

Nunca direto no código-fonte. Use variáveis de ambiente do próprio serviço de hospedagem ou um gerenciador de segredos dedicado, garanta que o arquivo de configuração local (.env ou equivalente) esteja no .gitignore, e use configurações diferentes para desenvolvimento e produção — para que uma chave de teste nunca vire, por engano, a chave usada em produção.

Quem deve rodar esse checklist: quem construiu o app ou a área de TI?

Depende do risco da aplicação. Para apps de baixo risco, quem construiu pode rodar sozinho os itens automatizáveis (secret scanning, SCA, SAST) com ferramentas simples de configurar. Para apps de risco alto ou crítico, a revisão — especialmente os itens de autenticação, controle de acesso e lógica de negócio — deve envolver TI ou segurança da informação, não só quem construiu.

Conclusão: velocidade e segurança não competem quando o checklist é parte do processo

A segurança do vibe coding não é um freio colocado depois que o app já está pronto — é uma sequência de verificações que cabe no mesmo ritmo rápido que torna o vibe coding valioso: rodar em minutos, na esteira de CI, antes de cada deploy. O que corrói esse equilíbrio não é o checklist em si, é pular ele achando que "funcionou no teste" é sinônimo de "seguro para produção" — os números da Veracode, da NYU e da USENIX mostram, de forma consistente, que não é.

É essa disciplina — checklist técnico embutido no fluxo de construção, não como etapa separada — que a Jetpacks instala dentro de grandes empresas brasileiras como parceira oficial da Replit no Brasil, dentro do método Flight Plan e do programa Builders. Para mapear o nível de segurança das aplicações de vibe coding que já existem na sua empresa e desenhar esse checklist para o seu contexto, comece pelo diagnóstico gratuito, uma conversa de 30–45 minutos sem custo.