六階段管線

在獵捕之前先看懂應用程式。三個代理從不同面向描繪它,再把輸出整併成 architecture.md。

• 1a — 應用概覽、技術棧,以及可用來校準的對照基準(comparable baseline)。
• 1b — 信任邊界、認證、授權、權限分離,以及各種繞道機制。
• 1c — 鉅細靡遺列出所有「不受信任輸入進入系統」的入口。
• architecture.md 會被原樣注入每一個第 2 階段代理的 prompt。

多個 general 代理同時攻擊程式碼,各自負責一個攻擊類別與/或子系統。它們以攻擊者的角度思考,而非審稿者。

• 小型函式庫 3–4 個代理;大型應用 8–12 個以上——依攻擊類別「與」子系統拆分。
• 每個 prompt 都帶上架構摘要、一個攻擊類別、起點檔案路徑、獵捕方法論與驗證規則。
• 獵人可以分叉一個聚焦的 research 子代理深入某子系統,而不必把所有東西塞進自己的 context。

先合併重複,再由「不同的」代理嘗試「推翻」每筆發現。獵人傾向找出東西,驗證者傾向幹掉誤報。

• 可利用性測試——讀真正的程式碼;你能構造出確切的觸發輸入嗎?
• 影響測試——攻擊者實際得到什麼?「知道欄位名稱」頂多是 LOW。
• 基準 / 緩解 / parser-runtime 測試——是否已有另一層擋住?要對照規格驗證,別憑直覺推論。

兩份人類可讀文件。要短:如果報告長到超過這份程式碼所值得的篇幅,那就是在灌水。

• REPORT.md——執行摘要、基準比較、發現表、強化建議,以及這份程式碼做得好的地方。
• FINDINGS-DETAIL.md——每筆 MEDIUM 以上發現:含 file:line 的完整資料流、確切請求、攻擊者所得。
• 點出哪裡穩固,能讓你「真正報出來」的發現更被信任。

每筆存活的發現轉成符合 report-schema.json 的 JSON 物件,再由 validate-findings.cjs 做結構檢查。

• 強制 additionalProperties:false——多餘欄位會讓輸出不合法。
• 若你無法用「對著原始碼驗證過的真實檔案路徑與行號」填滿 trace,代表這筆發現驗證得還不夠。
• 驗證器只做結構檢查——事實正確性是第 6 階段的工作。

寫出發現的代理看不見自己的盲點。一個全新的代理重讀原始碼,逐項查核每個事實主張。這是最後一道品質關卡——不可略過。

• 查核每個 trace 步驟:檔案存在、行號吻合、scope(函式)正確、描述準確。
• 查核 payload 真的會生效、前提條件完整,且修補不會弄壞正常功能。
• 校準 REPORT.md 與 findings.json,讓人類報告與機器輸出永不矛盾。