Checklist de segurança antes de publicar um app feito com vibe coding

Antes de publicar um app feito com vibe coding, identifique o commit exato do lançamento, escaneie-o e teste em um ambiente controlado os limites de acesso, o tratamento de segredos e os caminhos de falha. Use os achados do vetkit como evidência a ser revisada junto com os seus testes e a configuração de deploy. Um scan aprovado não prova que o app em execução é seguro ou está pronto para lançamento.

Este checklist é para a decisão de lançamento, depois da revisão de código. Para revisar linha a linha as mudanças de um assistente, comece pelo checklist de revisão de código gerado por IA. Guarde as evidências abaixo junto com o lançamento, para que outra pessoa saiba o que foi verificado.

1. Vincule as evidências ao lançamento

• Registre o SHA do commit e o artefato de build que você pretende implantar.
• Verifique se o relatório de auditoria cita o mesmo commit. Um relatório de um ponto mais antigo da branch não cobre correções posteriores nem arquivos gerados.
• Faça o build e rode os testes do projeto a partir dessa versão, usando uma configuração controlada e dados sintéticos. Guarde os resultados reais dos comandos, incluindo falhas e testes pulados.

2. Confira o que realmente rodou

O Security Quick Scan inclui posture, detecção de segredos com o gitleaks e verificação de dependências com o OSV. Auditorias mais amplas podem incluir verificações adicionais quando a sua conta e o escopo selecionado permitirem. O template de lançamento do vetkit seleciona verificações para áreas como análise estática de segurança, infraestrutura, workflows e operabilidade, mas não inclui todos os analisadores disponíveis. Por exemplo, secrets-history e llm-app ficam fora da seleção desse template.

Um relatório parcial significa que um ou mais analisadores não terminaram e que as categorias afetadas podem estar subnotificadas. Resolva as lacunas de cobertura relevantes ou documente a verificação alternativa antes de confiar no resultado.

3. Teste os limites de acesso

Em um ambiente de teste, crie duas contas comuns e uma conta com privilégios elevados. Tente ler e alterar os registros de uma conta usando a outra e chame endpoints protegidos sem estar logado. Verifique se o servidor rejeita operações não autorizadas mesmo quando a interface do navegador esconde o botão. Inclua downloads de arquivos, exportações e operações em segundo plano que usam os mesmos dados.

Em um app com backend no Supabase, revise as políticas de row-level security e de storage implantadas usando registros sintéticos. As regras vibe-stack do vetkit podem sinalizar padrões de código suportados, como políticas de row-level security ausentes ou permissivas e buckets de storage públicos. A inspeção do código-fonte não estabelece a configuração atual do seu banco de dados hospedado nem prova o isolamento entre tenants.

4. Verifique segredos e assets do navegador

Revise os achados de segredos, os prefixos públicos de variáveis de ambiente e os assets gerados para o navegador. Mantenha as credenciais de provedores e de service role no servidor. Uma auditoria de repositório não enxerga um segredo de deploy que não está nos arquivos escaneados, e não inspeciona automaticamente o bundle do navegador em produção. Se uma credencial foi exposta, revogue-a ou rotacione-a; remover a linha do código não basta. O guia de segredos vazados explica as verificações separadas de repositório, histórico e navegador.

5. Revise dependências e recursos de IA

Use o lockfile destinado ao lançamento e revise os achados de dependências. Uma consulta de vulnerabilidades conhecidas não estabelece que um pacote desconhecido é confiável. Verifique os nomes de pacotes recém-introduzidos e a procedência deles; veja o guia de pacotes alucinados.

Se o seu app chama um LLM, teste o que acontece com entradas grandes demais, erros do provedor e saídas que pedem uma operação privilegiada. Defina limites de uso no servidor e exija autorização em torno de ferramentas que alteram dados. As regras llm-app do vetkit identificam padrões suportados, como saída do modelo executada como comando ou SQL e chamadas acionadas pelo usuário sem limite de tokens de saída. Elas não demonstram que toda tentativa de prompt injection vai falhar nem medem os seus controles de gastos em produção.

6. Teste caminhos de falha e recuperação

• Simule um timeout de dependência e uma escrita que falha. Verifique se o usuário recebe um estado de falha útil e se tentar de novo não duplica a operação silenciosamente.
• Confira o comando de inicialização de produção, o health check e o relatório de erros. Use falhas sintéticas para confirmar que o operador responsável consegue perceber um lançamento quebrado sem registrar credenciais em log.
• Ensaie o procedimento de rollback ou de recuperação em um ambiente de teste. Se o lançamento altera dados armazenados, verifique o caminho de recuperação separadamente; reverter o código da aplicação pode não restaurar esses dados.

O vetkit inclui regras estáticas para padrões como chamadas de saída sem timeout, servidores de desenvolvimento em comandos de inicialização de produção e sincronização de schema potencialmente destrutiva. Esses achados podem direcionar a sua revisão, mas a auditoria não executa esse ensaio de falhas nem restaura um backup por você.

7. Registre a decisão de lançamento

Mantenha juntos o commit, o identificador do build, o escopo da auditoria, os resultados dos testes e as verificações de deploy. Resolva credenciais expostas e acessos não autorizados demonstrados antes de publicar. Para os achados restantes, registre a evidência, o impacto, o responsável pela decisão e a data de acompanhamento. Se um analisador relevante falhou ou um comportamento crítico nunca foi testado, deixe essa lacuna explícita em vez de tratar o silêncio como aprovação.

Fontes e limitações

Verificado em 1º de novembro de 2026 com base na configuração do Quick Scan do vetkit, nos templates de auditoria, no formatador de relatórios e nas regras vibe-stack, llm-app, resilience, data-access e operability. O catálogo público de verificações descreve as regras próprias e as linguagens suportadas; a documentação descreve a configuração das auditorias. A disponibilidade dos analisadores, os padrões suportados, os limites do scan e o escopo selecionado afetam a cobertura.

As verificações manuais aqui são trabalho da sua equipe, não afirmações de que o vetkit faz testes de invasão ao vivo, executa a suíte de testes da sua aplicação ou certifica um lançamento. Uma auditoria de código-fonte não consegue verificar todas as permissões de produção, configurações de deploy ou requisitos de negócio. Mantenha essas verificações no seu processo de lançamento mesmo quando o relatório não tiver achados.