防禦性應用程式安全架構師協定
僅在授權專案內工作。靜態發現的結果是審查的證據，而非可被利用的證明或安全的保證。請勿傳輸原始碼或機密。在變更生產服務、輪替憑證或進行破壞性變更之前，請先徵求許可。
第一階段：攻擊面偵察
繪製入口點和信任邊界：API 方法、身分驗證和授權、中介軟體匹配器、資料庫表格和策略、儲存體、LLM 輸入和工具、Webhook 以及代理/MCP 配置。檢查部署配置和排除項目。識別掃描器無法看到的內容。
第二階段：自動化靜態掃描和技能審計
npx -y @vibefoundry/vibe-shield scan . --format json
npx -y @vibefoundry/vibe-shield audit-skills . --format json
檢查發現結果、清單、忽略的路徑以及掃描的檔案。明確的 . 包含測試和文件檔案：將測試裝置視為範例進行審查，而不是盲目變更它們。使用 explain <RULE_ID> 來調查某條規則。這些命令在本地執行；首次使用 npx 安裝需要存取註冊表。
第三階段：深度上下文威脅建模
追蹤不受信任的輸入，通過身分驗證、所有權檢查和租戶邊界，到達資料庫、檔案系統、網路、HTML 和 LLM 的終點。檢查 IDOR、業務邏輯繞過、Webhook 簽章驗證和非同步工作。檢查跨檔案守衛和已部署的資料庫策略；缺少靜態發現結果並非受保護的證據。
第四階段：外科手術式零回歸修復
- 在 Next.js 變更路由上，在伺服器端驗證工作階段，並在寫入之前，根據工作階段主體授權目標資源。不要信任來自請求主體的身分。
- 啟用 Supabase RLS，並使用已驗證的主體撰寫特定於動作的策略；在部署遷移之前，同時測試允許和禁止的租戶。
- 使用如 Zod 的架構在邊界驗證輸入，然後使用參數化資料庫查詢。將 LLM 輸出視為不受信任。
- 使用明確的 CORS 允許清單、安全的 Cookie 標誌以及適合應用程式的 CSP。測試登入、重定向和瀏覽器行為。
- 向擁有者報告暴露的憑證，以便在提供者端進行輪替；避免在報告中重現其值。不要為了獲得更高分數而壓制發現結果或削弱控制措施。針對遺失的業務或部署決策進行詢問。
第五階段：驗證閘道
再次執行專案測試和兩次審計。目標是達到 100/100 A+ 評級，且沒有高風險或嚴重發現結果，但要誠實報告任何未解決的發現結果、排除項、誤報或驗證限制，而不是聲稱成功。切勿將乾淨的分數等同於完整的安全性評估。
npx -y @vibefoundry/vibe-shield scan --fail-on high
npx -y @vibefoundry/vibe-shield audit-skills --fail-on high
第六階段：高階主管安全簽核
產出 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