前 15 天，我們逐項建立 Production Readiness 的基礎：

• Authentication 與 Authorization
• 個資與 Log
• Secret
• Injection
• 供應鏈
• Logs、Metrics 與 Traces
• Timeout、Retry 與 Idempotency
• 健康檢查、容量與降級
• Backup、Migration 與 Recovery

今天開始進入 Agent 的核心設計。

如果我們把整個 Repository 丟給 Gemini，再問一句：

請找出所有資安漏洞。

模型可能很快產生一份報告。但這份報告混合了架構理解、漏洞搜尋、影響判斷與文字整理。模型只要在前面誤解一項設計，後面的結論就可能全部建立在錯誤假設上。

Cloudflare 的 security-audit-skill 採用另一種方法：把稽核拆成 Recon、Hunt、Validate、Report、Structured Output 與 Independent Verification。

今天會拆解這六個階段，並用 Vibe Guard 的三個候選問題跑一次縮小版流程。

這個 Skill 想解決什麼？

一般程式碼 Reviewer 容易產生三種問題：

1. 看見不符合 Checklist 的寫法，就直接列為漏洞。
2. 找到一段可疑程式，卻沒有追蹤完整資料流。
3. 同一個 Agent 發現問題後，又負責證明自己是對的。

第三個問題特別重要。

Hunter 的任務是找出問題，因此會偏向接受攻擊假設。讓同一個 Agent 驗證自己的 Finding，就像請作者替自己的文章做最後事實查核。它可能修正文句，卻不容易推翻最初判斷。

Cloudflare 的方法要求不同角色執行發現與驗證：

Hunter 要嘗試證明漏洞存在；Validator 要嘗試證明 Finding 是錯的。

只有經過對抗驗證後仍成立的問題，才會進入報告。

目前公開 Skill 的六個階段

Cloudflare Blog 使用七階段描述早期 Skill，最後一個階段是把結果送進 Ingest API。目前公開 Repository 的 README 則把單一 Repository 的工作整理成六個階段。

兩種說法沒有衝突。Ingest 是大型 Harness 的後續處理，不是目前公開 Skill 的核心稽核步驟。

Phase 1：Recon 先理解系統

Recon 不只是列出目錄。

Cloudflare 的 Skill 讓不同 Research Agent 分別調查：

1. 應用程式類型、技術棧與可比較產品。
2. 信任邊界、Authentication、Authorization 與權限模型。
3. HTTP、檔案、CLI、Queue 與外部整合等輸入面。

這些結果會合併成 architecture.md，再交給後續 Hunter。

如果跳過 Recon，Reviewer 很容易誤判設計。

例如：

apiKey: "demo-api-key"

只看變數名稱，Agent 可能回報「API Key 洩漏」。

但 Vibe Guard 使用 Firebase Emulator。這個值只識別本機 Demo Project，程式也拒絕在非本機環境執行。它不是可以呼叫 Gemini 的正式憑證。

Recon 提供必要上下文，避免模型只用字串模式判斷風險。

Phase 2：Hunt 要像攻擊者，不是 Checklist Reviewer

Cloudflare 不讓一個 Hunter 負責所有攻擊面，而是平行調查：

• Injection
• Access Control
• Business Logic
• Cryptography
• Feature Abuse
• Chained Attacks
• Wildcard

不同 Hunter 可能找到同一個問題。這不是立即需要避免的浪費。

重疊調查可以從不同入口發現相同 Root Cause，也能增加覆蓋率。真正需要處理的是在驗證前合併重複項目。

Hunting 文件也要求 Agent：

• 追蹤資料從 Entry Point 到 Sink。
• 攻擊 Error Handler、Fallback 與 Timeout 等 Sad Path。
• 檢查元件之間未被驗證的假設。
• 測試邊界值、操作順序與併發。
• 驗證 Parser 與 Runtime 的真實行為。
• 能執行時，建立最小 Harness 動態重現。

這與我們前 15 天的做法相同。每篇文章都不只說明「可能有問題」，還建立可以執行的 Scenario。

Phase 3：Validator 的工作是駁回 Finding

Cloudflare 的 Validation 文件要求獨立 Agent 執行五項測試：

1. **Exploitation Test：**資料流與攻擊輸入是否真的成立？
2. **Impact Test：**攻擊者實際得到什麼？
3. **Baseline Test：**可比較系統是否使用相同模式？
4. **Mitigation Test：**其他層是否已經阻止攻擊？
5. **Parser／Runtime Test：**行為是否經過規格或實作驗證？

Validator 最後只能回傳：

CONFIRMED

或：

REJECTED

Validator 不是替 Finding 補上漂亮理由。它要主動尋找反證。

Cloudflare 的文件用一句話說明取捨：

三個真實 Finding，比三十個理論問題更有價值。

用 Vibe Guard 跑縮小版流程

今天的 Demo 放在：

demo-app/audit-pipeline-demo/scenario.js

進入專案：

cd /media/mickey/777/ithome/demo-app

執行：

npm run audit-pipeline:demo

這不是完整的 Cloudflare Skill，也不會自動掃描新的漏洞。它使用三個已知候選，展示 Finding 如何流過六個階段。

Recon：建立最小架構摘要

Demo 先整理：

{
  "application": "Firebase web application",
  "trustBoundaries": [
    "Browser to Firebase Authentication",
    "Browser to Cloud Firestore"
  ],
  "inputSurfaces": [
    "Email and password form",
    "Project name and launch goal",
    "Firestore document reads and writes"
  ]
}

這份摘要指出兩個重要事實：

• 瀏覽器是不可相信的 Client。
• Firestore Rules 是資料存取的授權邊界。

後續 Hunter 因此應優先檢查 Rules，而不是只看前端是否隱藏按鈕。

Hunt：產生三個候選

Demo 建立三個 Candidate：

AUTH-01   Any signed-in user can access every project
SECRET-01 Firebase Web API key is exposed in client code
RATE-01   Application has no rate limiting

Candidate 不是最終 Finding。

Hunter 可以提出合理懷疑，但它還沒有證明攻擊路徑與影響。

Validate：一個確認、一個駁回、一個降級

實際結果：

AUTH-01 CONFIRMED

Firestore Rules 只有以下條件：

allow read, write: if request.auth != null;

前端又查詢整個 projects Collection：

query(collection(db, "projects"))

一般登入者符合唯一條件，因此可以跨帳號讀取或修改專案。Day 7 也已經用第二個帳號動態重現。

第二個候選被駁回：

SECRET-01 REJECTED

demo-api-key 是本機 Firebase Emulator 使用的 Project Identifier。它不是 Gemini Credential，程式也禁止在非本機環境執行。

如果報告把它列為高風險 Secret，反而會降低整份報告的可信度。

第三個候選改列 Hardening：

RATE-01 HARDENING

目前 Repository 沒有 Rate Limit Middleware，但我們不知道部署層是否使用 CDN、API Gateway、Firebase App Check 或平台 Quota。

「Repository 中找不到」不等於「Production 中不存在」。

在取得部署設定以前，Agent 只能要求補充證據，不能直接宣稱存在可利用的 DoS 漏洞。

Phase 4：Report 不應塞滿所有警告

Demo 最後統計：

Confirmed findings: 1
Rejected findings:  1
Hardening notes:     1

報告應把三種結果分開：

• Confirmed Finding：具有攻擊路徑與實際影響。
• Rejected Finding：原始判斷不符合程式事實。
• Hardening Note：可以改善防禦，但目前沒有可利用證據。

如果把三種內容全部放進漏洞表，讀者會花時間處理低價值項目，也可能忽略真正的越權問題。

Cloudflare 的 Report 還要求加入 Positive Patterns。例如：

• Demo 限制在本機執行。
• Gemini Key 從環境變數讀取。
• 測試使用假帳號與假資料。

寫出做對的地方，可以讓讀者確認 Reviewer 理解整個系統，而不是只會挑錯。

Phase 5：Structured Output 不是把文章存成 JSON

Cloudflare 使用 report-schema.json 約束 findings.json。

Confirmed Finding 需要包含：

• Root Cause
• Intended Behavior
• 從 Entrypoint 到 Sink 的 Trace
• Exploitation Conditions
• Payload 與執行步驟
• Remediation
• Likelihood、Impact 與 Severity
• Confidence 與理由

Rejected Finding 則保存：

{
  "verdict": "rejected",
  "reason": "具體說明原始判斷錯在哪裡"
}

Schema Check 只能驗證結構。例如，它可以確認 severity 使用合法值，也可以確認 Trace 包含必要欄位。

它不能證明漏洞是真的。

Demo 的縮小版輸出通過基本結構檢查：

Schema check: PASS

這只代表 JSON 具有預期欄位，不代表內容已經完成事實查核。

Phase 6：用新 Agent 再核對一次

Phase 3 已經由 Validator 檢查 Finding，為什麼還需要 Phase 6？

因為 Structured Output 可能在轉寫時加入錯誤：

• File Path 寫錯。
• Line Number 已經變動。
• Function Name 不存在。
• Payload 無法通過目前 Parser。
• Remediation 沒有阻止攻擊。
• Report 與 JSON 的 Severity 不一致。

Cloudflare 要求新的 Agent 逐項核對 findings.json 中的事實。這個 Agent 不能是原本寫 Finding 的 Agent。

Demo 最後重新搜尋原始 Rules，確認 Evidence 仍然存在：

Verified findings: 1/1

完整流程還應重新執行 Day 7 的動態測試，而不是只確認字串存在。今天的縮小版先展示角色與資料流，後續會把測試工具接入 Validator。

單次執行仍然不代表完整覆蓋

Cloudflare 的公開文件指出，單次執行大約只能找到多次執行所得問題的一半。

原因不是單純的隨機性。

每個 Agent 都受到以下限制：

• Context Window
• 搜尋起點
• 攻擊假設
• 執行時間
• 模型本身偏好的推理路徑

Cloudflare 後來把單一 Skill 發展成持久化 Harness，處理：

• 跨執行狀態
• Finding 去重
• 中斷後恢復
• 多 Repository 依賴
• 不同模型交叉驗證

Cloudflare Blog 建議先從 Recon、Hunt、Validate 與資料庫保存結果開始。只有在真正遇到瓶頸後，再增加跨 Repository Trace 或專用 Deduplication Agent。

這項建議也適用於我們的 Production Readiness Agent。現在不需要先建造龐大的 Agent Platform。我們應先讓單一 Repository 的 Finding 品質穩定。

我們會借鏡什麼，不會照抄什麼？

Production Readiness Agent 的範圍比 Security Audit 更廣。

我們會借鏡：

1. Recon 先建立架構與信任模型。
2. 多個 Reviewer 分開調查資安、隱私與 SRE。
3. Validator 主動推翻候選問題。
4. Confirmed、Rejected 與 Hardening 分開保存。
5. Structured Output 使用固定 Schema。
6. 新 Agent 再核對證據與報告。

我們還要增加：

• Health Check 與容量
• Logs、Metrics 與 Traces
• Timeout、Retry 與 Idempotency
• Backup、Migration 與 Recovery
• Deployment 與 Rollback

Cloudflare 的 Skill 是資安模組的重要參考，不是整個 Production Readiness Agent 的完整規格。

Production Readiness Agent 的第一版流程

根據今天的研究，我們可以先定義：

1. Recon
   └── 架構、資料流、信任邊界、部署資訊

2. Review
   ├── Security Reviewer
   ├── Privacy Reviewer
   ├── Reliability Reviewer
   └── Deployment Reviewer

3. Validate
   ├── 讀取完整程式路徑
   ├── 執行可重現測試
   └── 搜尋其他防護層

4. Classify
   ├── Confirmed Finding
   ├── Requires Evidence
   ├── Hardening Note
   └── Rejected

5. Report
   ├── Human-readable Markdown
   └── Structured JSON

6. Verify
   └── 新 Agent 核對事實與輸出一致性

這個流程的核心不是 Agent 數量。

核心是把不同目標拆開：

• 發現問題的人負責擴大搜尋。
• 驗證問題的人負責尋找反證。
• Schema Validator 負責檢查格式。
• Independent Verifier 負責核對事實。

每個角色只負責一種品質風險。

今天的結論

好的 AI 稽核不應是一次 Prompt，而是一條可以檢查、駁回與重跑的 Pipeline。

今天的縮小版實驗從三個候選中：

• 確認 1 個跨帳號授權漏洞。
• 駁回 1 個 Firebase API Key 誤報。
• 把 1 個缺少部署證據的問題改列 Hardening。

如果我們跳過 Validate，最終報告就會有三個「漏洞」。加入對抗驗證後，真正需要優先處理的只有一個。

明天，我們會繼續處理誤報問題：什麼條件才足以把 AI 的懷疑升級為 Confirmed Finding？

參考資料

• Cloudflare, security-audit-skill
• Cloudflare, Build your own vulnerability harness
• Cloudflare, Reconnaissance
• Cloudflare, Vulnerability Hunting
• Cloudflare, Validation, Reporting, and Verification