Protocolo de Arquiteto de Segurança Defensiva
Trabalhe apenas dentro do projeto autorizado. Evidências estáticas são evidências para revisão, não prova de explorabilidade ou garantia de segurança. Não transmita código-fonte ou segredos. Pergunte antes de alterar serviços de produção, rotacionar credenciais ou fazer alterações destrutivas.
Fase 1: Reconhecimento da superfície de ataque
Mapeie pontos de entrada e limites de confiança: métodos de API, autenticação e autorização, correspondentes de middleware, tabelas e políticas de banco de dados, armazenamento, entradas e ferramentas de LLM, webhooks e configuração de agente/MCP. Verifique a configuração de implantação e exclusões. Identifique o que o scanner não pode ver.
Fase 2: Varredura estática automatizada e auditoria de habilidades
npx -y @vibefoundry/vibe-shield scan . --format json
npx -y @vibefoundry/vibe-shield audit-skills . --format json
Inspecione achados, inventário, caminhos ignorados e os arquivos varridos. O . explícito inclui arquivos de teste e documentação: revise os fixtures como exemplos, em vez de alterá-los cegamente. Use explain <RULE_ID> para investigar uma regra. Esses comandos são executados localmente; a instalação pela primeira vez com npx requer acesso ao registro.
Fase 3: Modelagem de ameaças contextuais profundas
Rastreie a entrada não confiável através da autenticação, verificações de propriedade e limites de locatário até o banco de dados, sistema de arquivos, rede, HTML e sumidouros de LLM. Inspecione IDOR, bypass de lógica de negócios, verificação de assinatura de webhook e trabalhos assíncronos. Verifique guardas entre arquivos e políticas de banco de dados implantadas; a ausência de um achado estático não é evidência de proteção.
Fase 4: Remediação cirúrgica com zero regressão
- Em rotas de mutação Next.js, autentique a sessão no servidor e autorize o recurso de destino em relação ao principal da sessão antes das gravações. Não confie na identidade dos corpos das requisições.
- Habilite RLS no Supabase e escreva políticas específicas para ações usando o principal autenticado; teste locatários permitidos e negados antes de implantar migrações.
- Valide entradas no limite com um esquema como Zod e, em seguida, use consultas parametrizadas ao banco de dados. Trate a saída do LLM como não confiável.
- Use listas de permissões CORS explícitas, flags de cookies seguras e uma CSP apropriada para a aplicação. Teste login, redirecionamentos e comportamento do navegador.
- Relate credenciais expostas ao proprietário para rotação no lado do provedor; evite reproduzir seus valores nos relatórios. Não suprima achados nem enfraqueça controles para obter uma pontuação mais alta. Pergunte sobre decisões de negócios ou implantação ausentes.
Fase 5: Portão de verificação
Execute os testes do projeto e ambas as auditorias novamente. Busque 100/100 Nota A+ sem achados altos ou críticos, mas relate honestamente qualquer achado não resolvido, exclusão, falso positivo ou limitação de verificação, em vez de reivindicar sucesso. Nunca equacione uma pontuação limpa com uma avaliação de segurança completa.
npx -y @vibefoundry/vibe-shield scan --fail-on high
npx -y @vibefoundry/vibe-shield audit-skills --fail-on high
Fase 6: Aprovação executiva de segurança
Produza um relatório em Markdown ou HTML com escopo, inventário, riscos priorizados por gravidade, evidências, ações, resultados de teste e incerteza restante. Exemplos de código ilustrativos não são patches específicos do projeto; revise e adapte-os. Obtenha aprovação humana antes da implantação ou ação no lado do provedor.
npx -y @vibefoundry/vibe-shield scan --report SECURITY-REPORT.md --patch-prompt PATCH-PROMPT.md
npx -y @vibefoundry/vibe-shield audit-skills --report AGENT-REPORT.html