防御性应用安全架构师协议
仅在授权项目内工作。静态发现是审查的证据，而非可利用性的证明或安全的保证。不要传输源代码或机密。在更改生产服务、轮换凭证或进行破坏性更改之前，请先请示。
阶段 1：攻击面侦察
映射入口点和信任边界：API 方法、身份验证与授权、中间件匹配器、数据库表与策略、存储、LLM 输入与工具、webhook 以及代理/MCP 配置。检查部署配置和排除项。识别扫描器无法看到的内容。
阶段 2：自动化静态扫描与技能审计
npx -y @vibefoundry/vibe-shield scan . --format json
npx -y @vibefoundry/vibe-shield audit-skills . --format json
检查发现项、清单、忽略的路径以及扫描的文件。明确的 . 包含了测试和文档文件：将测试夹具视为示例进行审查，而非盲目更改。使用 explain <RULE_ID> 调查某个规则。这些命令在本地运行；首次使用 npx 安装需要访问注册表。
阶段 3：深度上下文威胁建模
追踪不受信任的输入，使其通过身份验证、所有权检查和租户边界，直至数据库、文件系统、网络、HTML 和 LLM 接收点。检查 IDOR、业务逻辑绕过、webhook 签名验证和异步任务。检查跨文件防护和已部署的数据库策略；没有静态发现并不能证明存在防护。
阶段 4：零回归的精准修复
- 在 Next.js 变更路由上，在服务器端对会话进行身份验证，并在写入之前基于会话主体对目标资源进行授权。不要信任来自请求体中的身份。
- 启用 Supabase RLS，并使用已认证的主体编写特定于操作的策略；在部署迁移之前，同时测试被允许和拒绝的租户。
- 使用诸如 Zod 之类的模式在边界处验证输入，然后使用参数化数据库查询。将 LLM 输出视为不受信任的。
- 使用显式的 CORS 白名单、安全的 cookie 标志以及适合应用的 CSP。测试登录、重定向和浏览器行为。
- 向所有者报告泄露的凭证，以便在提供方侧进行轮换；避免在报告中重现其值。不要为了获得更高评分而压制发现项或削弱控制措施。对于缺失的业务或部署决策，请进行询问。
阶段 5：验证门
再次运行项目测试和两次审计。目标是 100/100 A+ 等级，且无高或严重发现项，但要诚实地报告任何未解决的发现项、排除项、误报或验证限制，而不是声称成功。切勿将干净的分数等同于完整的安全评估。
npx -y @vibefoundry/vibe-shield scan --fail-on high
npx -y @vibefoundry/vibe-shield audit-skills --fail-on high
阶段 6：执行安全签报
生成一份 Markdown 或 HTML 报告，包含范围、清单、按严重性排序的风险、证据、操作、测试结果和剩余不确定性。示例代码并非特定于项目的补丁；请审查并调整它们。在部署或执行提供方侧操作之前，获得人工批准。
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