從 DevSecOps 到 AI Agent Security Review：重新思考 GitHub 專案的資安掃描
一、資安掃描的下一步，不只是找到更多漏洞
在現代軟體開發流程中，資安檢查已經逐漸融入 CI/CD Pipeline。
開發者提交程式碼後，系統可以自動執行 SAST、Secret Scanning、Dependency Scanning 與 Container Scanning，在程式碼合併或部署之前，找出潛在的安全風險。
這些工具解決了許多傳統人工審查難以持續執行的問題。
然而，自動化掃描結果仍然需要判讀。
工具可能找到一段可疑的程式碼，但它是否真的構成漏洞？攻擊者是否能滿足利用條件？系統其他位置是否已經存在防護機制？修補之後，又是否會破壞原有的業務邏輯？
這些問題往往需要結合程式碼、執行流程、權限設計與系統架構才能回答。
因此，我認為值得關注的發展方向，是從傳統的自動化資安掃描，進一步走向 AI Agent Security Review。
Cloudflare 開源的 Security Audit Skill，提供了一個值得研究的案例：它不只是要求 AI 尋找漏洞，而是將架構分析、漏洞搜尋、對抗式驗證、結構化輸出與獨立檢查納入同一套審計流程。
這背後真正值得探討的問題是：
當 AI 能夠協助尋找漏洞時，我們要如何確認它找到的問題確實成立？
二、傳統 DevSecOps：不同工具負責不同的安全風險
DevSecOps 的核心不是把所有資安工具塞進 Pipeline，而是將安全檢查整合到軟體開發生命週期，讓問題能夠及早被發現、追蹤與修復。
常見的 GitHub 專案安全檢查，可以分成以下幾個類別。
1. SAST：靜態應用程式安全測試
代表工具：CodeQL、Semgrep。
SAST 在不需要實際執行完整應用程式的情況下，分析原始碼中的潛在安全問題。
CodeQL 可以利用程式碼資料模型與查詢規則分析資料流，尋找符合特定模式的漏洞。Semgrep 則適合使用既有或自訂規則，檢查不安全的程式碼模式與團隊規範。
這類工具能協助發現 SQL Injection、不安全的輸入處理，以及其他受分析規則涵蓋的漏洞。
但靜態分析的結果取決於語言支援、分析能力、規則品質與程式碼上下文。沒有掃描結果，不代表沒有漏洞。
2. Secret Scanning：機密資訊檢查
代表工具：Gitleaks。
開發者可能不小心將 API Key、資料庫密碼、Token 或私鑰提交到 Git Repository。
Gitleaks 可以掃描儲存庫內容，尋找疑似機密資訊，協助團隊在問題進入正式環境之前發現風險。
需要注意的是，從最新版本刪除機密資訊，不代表 Git 歷史紀錄中的內容已經消失。若憑證曾經外洩，通常還需要撤銷或輪替，並檢查相關存取紀錄。
參考：Gitleaks
3. Dependency Scanning：第三方依賴套件檢查
代表工具：Dependabot、Trivy。
現代應用程式大量依賴第三方套件。即使自行撰寫的程式碼沒有明顯問題，依賴套件仍可能存在已知漏洞。
Dependabot 可以追蹤支援的依賴套件與安全公告，並依照設定提出版本更新。Trivy 則可以掃描語言套件、作業系統套件及其他支援的目標，找出已知漏洞。
不過，發現有漏洞的依賴，不代表它在目前系統中一定能被利用。仍需考慮受影響版本、實際使用方式、攻擊可達性與修補相容性。
參考：Dependabot、Trivy
4. Container Scanning：容器與部署設定檢查
代表工具：Trivy。
對採用 Docker 的專案而言，安全問題不只存在於應用程式原始碼，也可能來自基底映像、作業系統套件、容器設定與部署配置。
Trivy 可以針對支援的容器映像與設定檔進行檢查，協助團隊在部署之前發現風險。
這類掃描能補足純粹檢查應用程式程式碼的不足，但仍不能取代正式環境的權限管理、網路隔離與執行時期防護。
傳統工具的共同限制
這些工具各有專長，卻不能單獨代表完整的資安審計。
它們通常能回答：
哪些程式碼符合已知的不安全模式？
哪些依賴套件存在已知漏洞？
哪些提交可能包含機密資訊？
哪些容器或部署設定存在風險？
但對於跨模組的權限邏輯、業務流程中的安全假設，以及一個候選漏洞是否真的可以被利用，仍可能需要更深入的分析。
這正是 AI Agent Security Review 可以嘗試補足的部分。
三、為什麼掃描工具可能發現不了真正的業務邏輯漏洞？
以企業系統常見的多租戶 API 為例。
假設系統提供以下端點：
GET /supplier/123/materials登入使用者可以查看供應商 123 的物料資料。當使用者將網址中的 ID 改成 456：
GET /supplier/456/materials如果後端只檢查使用者是否已登入，卻沒有確認該使用者是否有權限存取供應商 456 的資料，就可能造成跨租戶資料外洩。
這類漏洞稱為 BOLA（Broken Object Level Authorization，物件層級授權失效）。
OWASP API Security Top 10 2023 將 BOLA 列為 API1:2023，並指出，API 在根據使用者提供的物件識別碼存取資料時，必須正確執行物件層級的授權檢查。
參考：OWASP API1:2023 — Broken Object Level Authorization
這個案例說明了為什麼安全檢查不能只看某一行程式碼。
假設某個 Controller 沒有直接檢查供應商歸屬權限，不能因此立即認定存在漏洞。權限檢查可能已經在 Middleware、共用依賴或資料存取層執行。
反過來說，即使程式碼沒有 SQL Injection，也不代表 API 的存取控制是安全的。
真正需要追蹤的是完整的請求路徑：
使用者如何通過身分驗證？
API 如何取得請求中的物件 ID？
系統在哪個位置判斷使用者的存取權限？
資料查詢是否受到租戶或所有權條件限制？
未授權的請求是否真的能讀取或修改其他人的資料？
這種需要理解多個模組與業務規則的問題，正是單純依賴掃描規則可能不足的地方。
四、Cloudflare Security Audit Skill：將安全審計流程化
專案網址：cloudflare/security-audit-skill
Cloudflare Security Audit Skill 是一套用於 Coding Agent 的安全審計工作流程，也是 Cloudflare 公開漏洞發現系統的起點版本。
它的價值不在於取代所有既有掃描器，而在於把 AI Agent 的安全審計拆成明確的階段，並要求候選漏洞經過驗證與獨立檢查。
六個主要階段
1. Reconnaissance：架構分析
先理解程式庫的架構、信任邊界、輸入來源與主要攻擊面，建立後續審計的範圍與紀錄。
2. Coverage-led Hunting：依涵蓋範圍搜尋漏洞
將審計範圍拆成不同工作單位，交由不同的 Hunter Agent 檢查。除了搜尋漏洞，也要追蹤已檢查的範圍，並找出可能被遺漏的部分。
3. Candidate Validation：候選漏洞驗證
將候選漏洞交給新的 Verifier Agent，要求它嘗試推翻原本的判斷。
驗證者需要檢查程式碼路徑、必要條件、防護機制與實際影響，而不是直接接受發現者的結論。
4. Structured Output：結構化結果
將結果整理到 findings.json，並使用不同狀態區分已確認、待驗證與已被推翻的問題。
這讓後續流程可以根據明確的資料結構處理結果，而不是只依賴一份自然語言報告。
5. Independent Record Verification：獨立檢查報告證據
由新的 Agent 重新核對結構化紀錄中的程式碼位置與事實陳述，確認最終報告是否仍有足夠的原始碼證據支持。
6. Target-neutral Reporting：產生審計報告
依照經過驗證的紀錄，產生人類可閱讀的報告、詳細發現紀錄，以及尚待驗證的問題清單。
以上階段與輸出設計，可以直接參考官方專案的 README。
五、真正值得研究的設計：Verification Chain
如果只把 Cloudflare Security Audit Skill 理解成「用 AI 找漏洞」，就容易忽略它更重要的工程設計。
我認為它最值得研究的是 Verification Chain（驗證鏈）：讓一個安全發現從提出、驗證到正式寫入報告，每個階段都必須留下可追蹤的依據。
概念上可以表示為：
程式碼與架構分析
|
v
Hunter Agent
提出候選漏洞與證據
|
v
Verifier Agent
嘗試推翻候選漏洞
|
v
結構化 Findings
記錄狀態與證據
|
v
Independent Verification
重新核對來源與結論
|
v
安全審計報告
|
v
人工審查、修補與回歸測試這是概念上的責任流程，不代表所有實作都只能依照單一線性順序執行。
為什麼要讓不同 Agent 負責不同工作？
假設 Hunter 發現某個 API 可能存在越權存取。
如果同一個 Agent 直接替自己的發現背書，就可能沿用原先的假設，忽略其他模組已經存在的防護。
Verifier 的任務應該不同：它不是幫忙把原本的說法寫得更完整，而是主動尋找反證。
例如：
是否有 Middleware 已完成授權？
查詢是否已限制在目前使用者所屬的租戶？
攻擊者是否真的能控制目標物件的識別碼？
請求成功後，是否確實能讀取或修改未授權的資料？
如果證據不足，就應該保留待驗證狀態，而不是直接定義為已確認漏洞。
這種責任分離與一般程式碼審查的概念相似：開發者提交修改，Reviewer 挑戰設計與實作，QA 驗證行為，最後才進入交付流程。
但要注意，使用不同 Agent 並不會自動消除錯誤。不同 Agent 可能共享相似的模型弱點或錯誤假設。因此，對高風險問題仍應搭配可重現的測試、人工審查與安全的執行環境。
真正的重點不是讓 AI 多回答一次，而是讓驗證階段有明確的反證責任。
六、如何將傳統掃描與 AI 審計整合？
傳統工具與 AI Agent 並不是二選一，而是適合處理不同層次的問題。
以下是一個概念性的 GitHub 安全檢查流程：
GitHub Push / Pull Request
|
v
┌─────────────────────┐
│ CodeQL / Semgrep │
│ 靜態程式碼分析 │
└─────────────────────┘
|
v
┌─────────────────────┐
│ Gitleaks │
│ 機密資訊掃描 │
└─────────────────────┘
|
v
┌─────────────────────┐
│ Trivy / Dependabot │
│ 依賴與容器風險 │
└─────────────────────┘
|
v
┌─────────────────────┐
│ Security Audit Skill│
│ 深入分析與獨立驗證 │
└─────────────────────┘
|
v
Human Review
|
v
修補與回歸測試
|
v
Deploy這張圖展示的是一種可能的整合方式，而不是 Cloudflare Skill 的內建工具清單，也不代表所有專案都應將完整 AI 審計放在每一次 Pull Request 中。
實際導入時，可以依照成本與風險決定執行頻率：
每次 Pull Request： 執行速度較快、適合高頻率執行的靜態分析與機密掃描。
定期或重大變更時： 執行較深入的 AI Agent 安全審計。
修補完成後： 執行相關安全測試、原有功能測試與必要的回歸檢查。
正式部署前： 由負責人確認高風險問題的處理狀態與交付條件。
另外，安全審計涉及不受信任的程式碼時，必須限制執行環境與權限。不能為了驗證漏洞，就讓 Agent 在沒有適當隔離的環境中執行任意程式碼，或直接探測未經授權的正式系統。
七、AI Agent Security Review 的限制
即使採用多 Agent 驗證流程，仍然有幾個問題需要正視。
第一，驗證不等於形式上的安全證明。
Agent 找到證據、重現問題，能提高判斷的可信度，但無法證明整個系統不存在其他漏洞。
第二，覆蓋率仍然重要。
如果某個模組根本沒有被檢查，再好的驗證流程也無法確認該模組是否安全。架構分析與涵蓋範圍紀錄因此很重要。
第三，AI 審計有額外成本。
多階段分析、平行 Agent 與獨立驗證會增加 Token、工具呼叫與執行時間。是否值得投入，應取決於系統風險與審計目標。
第四，發現漏洞不等於修補完成。
修補可能引入新的錯誤，尤其是權限、租戶隔離與資料完整性等涉及業務不變條件的功能。
因此，AI 安全審計的成果應該進入正常的工程流程，包含問題追蹤、人工審核、修補、測試與重新驗證，而不是以一份 AI 產生的報告作為安全保證。
八、結語：Security as Process，而不只是 Security as Tool
從 CodeQL、Semgrep、Gitleaks、Trivy 到 Dependabot，傳統資安工具已經能在程式碼、依賴套件、機密資訊與部署設定等層面提供自動化檢查。
Cloudflare Security Audit Skill 則展示了另一種值得研究的方向：讓 AI Agent 參與更完整的安全審計，並將候選漏洞的驗證、證據紀錄與獨立檢查納入工作流程。
對 AI 輔助開發而言，這個方向尤其值得關注。
當 AI Agent 越來越常參與程式碼撰寫，工程團隊不能只關心產生程式碼的速度，也必須建立相應的驗證機制，確認程式碼是否符合安全要求、修改是否破壞既有行為，以及審計結論是否有足夠證據支持。
未來資安工具的競爭，可能不再只是誰能找到更多漏洞，而是誰能建立更可信的 Verification Chain，讓漏洞發現、驗證、修復與追蹤形成可持續運作的工程流程。
這也是從傳統 DevSecOps 走向 AI Agent Security Review 時，最值得深入思考的工程問題。
安全不應只是工具執行完畢後的一份掃描報告，而應該是整個軟體交付流程中，能持續驗證、追蹤與改善的工程能力。
