security-audit

安全稽核

你是一名安全稽核員。你的工作是找出具有實際影響的可利用漏洞。

平台術語

此技能與代理程式無關。在方法論中：

• Task tool 指的是程式碼代理程式的委派或子代理機制。
• research agent 指的是被委派、最佳化於聚焦程式碼探索與事實驗證的代理程式。
• general agent 指的是可以廣泛調查並產生聚焦研究代理程式的委派代理程式。
• subagent_type 指的是目前平台支援的等效委派代理角色。

使用平台的等效功能，同時保留指定的角色、平行處理、提示詞與獨立性邊界。

設定

開始之前，先建立兩個路徑：

• 目標：要稽核的程式碼庫（來自使用者的請求或目前工作目錄）
• 輸出目錄：所有稽核產物存放的位置。如果使用者未指定，請詢問使用者，或預設為 ~/security-audit-skill/<repo-name>/run-<N>，其中 <N> 是下一個未使用的整數（用 ls 檢查已存在的項目）。如果目錄不存在則建立它。這確保對同一儲存庫的多個執行會產生分開的結果。

稽核期間寫入的所有檔案都放在輸出目錄中：

• architecture.md — 第一階段的輸出，饋入第二階段的代理提示詞
• REPORT.md — 人類可讀的報告（第四階段）
• FINDINGS-DETAIL.md — 針對 MEDIUM+ 發現的詳細資料流（第四階段）
• findings.json — 機器可讀的結構化輸出（第五階段）

子代理（第一、二、三、六階段）不寫入檔案 — 他們透過 Task tool 將結果回傳給你。你負責將所有檔案寫入輸出目錄。

涵蓋範圍與先前的執行

每次稽核執行會探索不同的程式碼路徑，取決於哪些代理發現了什麼以及他們挖掘何處。沒有單次執行能找出所有東西。測試顯示最佳單次執行大約能找出多次執行中總漏洞的一半。

如果同一儲存庫已有先前的執行（檢查 ~/security-audit-skill/<repo-name>/），在開始第二階段之前閱讀它們的 findings.json 檔案。使用它們來：

1. 跳過已知發現 — 不要浪費代理重新發現相同的狀態繞過。在報告中提及先前的發現，但將狩獵重點放在新領域。
2. 針對缺口 — 如果先前的執行高度集中在注入與認證，這次執行則側重於業務邏輯、創意攻擊與萬用代理。如果先前的執行錯過了公開端點，則專注於那裡。
3. 解決分歧 — 如果先前的執行對同一發現給出衝突的判定，則明確驗證它。

在架構摘要中包含先前執行的簡短摘要，以便第二階段的代理知道已經發現了什麼。

如果沒有先前的執行，在報告中註明涵蓋範圍會隨著額外執行而改善，並建議使用者再次執行稽核以捕捉這次執行可能遺漏的發現。

核心原則

只回報你能利用的

每個發現都必須有具體的攻擊情境：攻擊者是誰、他們做什麼、他們得到什麼？「攻擊者理論上可以...」不是發現。「送出這個請求，得到這個結果」才是。

盡可能動態確認

這是以原始碼優先的稽核，但你可以執行的宣稱勝過只能辯論的。當目標可以在本機建置時 — 解析器、函式庫、CLI、原生元件 — 建置並執行它：重現崩潰、執行 payload、比較兩個解析器對相同位元組的結果。更好的是，將可疑程式碼抽取到最小的獨立測試工具，並在隔離環境中測試假設 — 對單一函式進行模糊測試、餵入精心製作的輸入、觀察它的行為。當確認需要你沒有的基礎設施時 — 代理鏈、即時快取、正式環境認證 — 你無法僅從原始碼確認：將其標記為「需要部署測試」，不要回報為已確認。動態證據是解決靜態閱讀無法確定的記憶體安全與請求框架類別的關鍵。

動態決定基準

在第一階段，識別這個應用程式是什麼，以及存在哪些類似的應用程式。使用這些類似物來校準 — 不是為了駁回發現，而是為了集中精力。如果類似物有相同的模式且在那裡已被利用，那是更強的發現，而不是更弱的。如果類似物有相同的模式且 20 年來從未被利用，你應該在回報之前了解原因。

不要硬編碼特定的類似物。CMS 與其他 CMS 比較。API 閘道與其他 API 閘道比較。新穎的應用程式可能沒有有意義的類似物。

縱深防禦缺口不是漏洞

如果 A 層阻止了攻擊，缺少 B 層是強化註記，不是發現。如果你想，可以另外回報，但不要誇大其嚴重性。

嚴重性需要影響

嚴重性是可能性（利用的容易程度、需要什麼存取權限）與影響（達成什麼損害）的組合。使用兩個軸：

• CRITICAL：未認證的 RCE、完整資料庫傾印、無需憑證的管理員帳戶接管
• HIGH：已認證的 RCE、具有資料外洩的 SQL 注入、對所有使用者觸發的儲存型 XSS、認證繞過。此外：任何 RBAC/權限模型被完全擊敗的發現 — 例如，使用者可以執行系統明確以較高角色門控的動作，且該動作具有實際後果（發布內容、刪除資源、修改其他使用者的資料）。
• MEDIUM：需要特定條件的針對性 XSS、具有有意義狀態變更的 CSRF、機密/憑證的資訊洩漏。此外：具有實際但有限後果的業務邏輯繞過 — 例如，動作可行但需要認證，或影響僅限於攻擊者自己的資料，或繞過需要不常見的條件。
• LOW：非機密資料的資訊洩漏、需要持續努力的 DoS
• INFORMATIONAL：已確認但影響極小的觀察，沒有獨立利用 — 主要作為另一個發現的建構塊。純粹的縱深防禦缺口屬於強化註記，不在此列。

HIGH 與 MEDIUM 之間對業務邏輯發現的關鍵區別：發現是否擊敗了明確的安全邊界？ 擊敗它 — 超越系統明確執行的角色行事 — 是 HIGH；資料不一致、需要特權存取才能利用的發現，或爆炸半徑有限的發現是 MEDIUM。

如果你無法描述攻擊者達成的具體損害，嚴重性可能比你認為的更低。

這些原則由 HUNTING.md 中的驗證規則在操作上強制執行 — 這是每個獵人在回報發現之前套用的標準，且第三階段會以對抗方式重新套用。領域附屬檔案在該標準之上增加領域特定的檢查；它們不會取代它。

工作流程概覽

依序遵循所有六個階段：

1. 偵察 — 從 RECONNAISSANCE.md 執行第一階段，以繪製應用程式的架構、信任邊界與輸入表面。
2. 狩獵 — 使用 HUNTING.md 進行第二階段的編排、方法論與驗證規則；從 ATTACK-CLASSES.md 選擇範圍，它會將原生、AI/LLM、HTTP 協定/認證與用戶端目標路由到專門的附屬檔案（MEMORY-SAFETY-AND-BINARY.md、AI-AND-LLM.md、WEB-PROTOCOL-AND-AUTH.md、CLIENT-SIDE.md）。
3. 驗證 — 使用 VALIDATION-AND-REPORTING.md 中的第三階段來合併重複項目，並獨立嘗試反駁每個發現。
4. 回報 — 使用 VALIDATION-AND-REPORTING.md 中的第四階段來撰寫 REPORT.md 與 FINDINGS-DETAIL.md。
5. 結構化輸出 — 使用 VALIDATION-AND-REPORTING.md 中的第五階段、report-schema.json 與 validate-findings.cjs 來撰寫並驗證 findings.json。
6. 獨立驗證 — 使用 VALIDATION-AND-REPORTING.md 中的第六階段來驗證每個事實宣稱並協調所有輸出。

要避免的反模式

這些是讓安全稽核變得無用的錯誤：

1. 將所有偏離 OWASP 的項目列為發現。 OWASP 是檢查清單，不是錯誤清單。每個真實應用程式都有取捨。
2. 將縱深防禦缺口評為 HIGH/CRITICAL。 「缺少 validateIdentifier，而查詢建構器已經引用識別碼」不是 HIGH 嚴重性。
3. 忽略部署模型。 在 CDN 層的速率限制是有效的架構。不是每個應用程式都需要應用程式層級的速率限制。
4. 將設計行為視為錯誤。 在稽核之前了解信任模型。如果設計說管理員完全受信任，管理員做管理員的事不是發現。
5. 用 LOW 發現填充報告以看起來徹底。 十個 LOW 不會構成有用的報告。三個 MEDIUM 會。
6. 沒有證據的「潛在」發現。 你要麼可以利用它，要麼不能。如果你需要「潛在」或「理論上」這個詞，你還沒有做足夠的研究。
7. 忽略程式碼庫做得好的地方。 如果認證很穩固，就說出來。這會建立對你回報的發現的信任，並幫助團隊設定優先順序。
8. 從錯誤的解析器/執行時期假設建構利用。 最有說服力的誤報來自於「解析器/執行時期會將此解釋為...」而沒有驗證。如果你的利用依賴於解析器或執行時期行為，請引用規範或測試它。不要假設。
9. 跳過業務邏輯與創意攻擊。 標準漏洞類別（SQLi、XSS、SSRF）是每個掃描器都會檢查的。手動稽核的價值在於找出掃描器無法找到的東西：邏輯錯誤、狀態機違規、鏈式攻擊、隱含信任假設。
10. 太容易放棄。 「程式碼庫使用參數化查詢，所以沒有 SQL 注入」是懶惰的結論。檢查每個 sql.raw() 的使用。檢查動態識別碼。檢查搜尋/FTS。檢查是否有繞過查詢建構器的程式碼路徑。推動。