從傳統資安掃描到 AI Agent 審計：GitHub 專案的安全檢查工具與實務

從 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、不安全的輸入處理，以及其他受分析規則涵蓋的漏洞。

但靜態分析的結果取決於語言支援、分析能力、規則品質與程式碼上下文。沒有掃描結果，不代表沒有漏洞。

參考：CodeQL、Semgrep

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 的存取控制是安全的。

真正需要追蹤的是完整的請求路徑：

1. 使用者如何通過身分驗證？

2. API 如何取得請求中的物件 ID？

3. 系統在哪個位置判斷使用者的存取權限？

4. 資料查詢是否受到租戶或所有權條件限制？

5. 未授權的請求是否真的能讀取或修改其他人的資料？

這種需要理解多個模組與業務規則的問題，正是單純依賴掃描規則可能不足的地方。

四、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 時，最值得深入思考的工程問題。

安全不應只是工具執行完畢後的一份掃描報告，而應該是整個軟體交付流程中，能持續驗證、追蹤與改善的工程能力。

從 DevSecOps 到 AI Agent Security Review：GitHub 資安掃描工具實戰教學

一、前言：不只要找出漏洞，還要驗證問題是否成立

在現代軟體開發流程中，資安檢查已逐漸整合進 CI/CD Pipeline。開發者提交程式碼後，系統可以自動執行靜態程式碼分析、機密資訊掃描、依賴套件檢查與容器映像掃描，在問題進入正式環境之前，提早發現風險。

但掃描器找到問題，不代表漏洞一定成立。

例如，一個 API 沒有在 Controller 內直接檢查使用者權限，不一定代表系統存在越權漏洞，因為權限驗證可能已經在 Middleware 或共用依賴中完成。反過來說，即使程式碼沒有 SQL Injection，也可能因為缺少物件層級的授權檢查，造成跨租戶資料外洩。

因此，除了傳統的自動化掃描，另一個值得關注的方向，是讓 AI Agent 參與安全審計，進一步分析架構、追蹤資料流、驗證候選漏洞，並留下可核對的證據。

本文會介紹六種工具及其實際用法：

• CodeQL：靜態程式碼安全分析

• Semgrep：規則式程式碼掃描

• Gitleaks：機密資訊掃描

• Trivy：依賴套件、容器與設定檢查

• Dependabot：依賴套件漏洞追蹤與更新

• Cloudflare Security Audit Skill：AI Agent 多階段安全審計

範例以 GitHub、FastAPI、React 與 Docker 專案為主。

二、建立實作環境

開始之前，先確認專案已經使用 Git 管理，並且已經推送至 GitHub。

以下假設專案大致具有這樣的結構：

my-project/
├── backend/
│   ├── requirements.txt
│   └── app/
├── frontend/
│   ├── package.json
│   └── package-lock.json
├── Dockerfile
└── README.md

實際目錄依專案調整即可。PHP/Laravel 專案則可能使用 composer.json、composer.lock 與 artisan。

建議先建立一個專門存放 GitHub Actions 工作流程的目錄：

.github/
└── workflows/
    └── security.yml

GitHub Actions 會根據 .github/workflows/ 內的 YAML 檔案執行自動化工作。

官方文件：GitHub Actions

初次導入時，建議先在本機執行掃描，確認輸出結果，再整合到 CI。不要一開始就讓所有警告直接阻擋合併，否則舊專案可能一次產生大量歷史問題。

三、CodeQL：執行靜態程式碼安全分析

官方網站：CodeQL

CodeQL 會分析程式碼結構與資料流，透過查詢規則尋找潛在漏洞。它適合用於檢查程式碼中可能存在的 Injection、XSS 及其他受支援規則涵蓋的安全問題。

步驟一：在 GitHub 啟用 Code Scanning

進入 GitHub Repository，查看 Security 或 Settings 中的 Code Security／Code Scanning 設定。

如果帳號、組織與 Repository 的方案和政策允許，可以使用 GitHub 提供的 CodeQL 設定流程建立掃描工作。

也可以自行建立工作流程檔案。

步驟二：建立 CodeQL 工作流程

建立 .github/workflows/codeql.yml：

name: CodeQL Security Scan

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]
  schedule:
    - cron: "30 2 * * 1"

permissions:
  contents: read

jobs:
  analyze:
    name: Analyze
    runs-on: ubuntu-latest

    permissions:
      contents: read
      security-events: write
      pull-requests: read

    strategy:
      fail-fast: false
      matrix:
        language: ["python", "javascript-typescript"]

    steps:
      - name: Checkout repository
        uses: actions/checkout@v4

      - name: Initialize CodeQL
        uses: github/codeql-action/init@v3
        with:
          languages: ${{ matrix.language }}

      - name: Perform CodeQL Analysis
        uses: github/codeql-action/analyze@v3

這是一個用於理解流程的基本範例。正式環境應依 GitHub 當前支援的 Action 版本、語言需求及組織政策，調整版本固定方式與權限。

步驟三：查看掃描結果

將檔案推送到 GitHub 後，進入 Actions 查看工作是否成功，再到 Security／Code Scanning 檢視告警。

判讀時應注意：

• 告警指出的程式碼位置。

• 資料是否來自外部輸入。

• 資料如何流向敏感操作。

• 是否存在有效的驗證或防護機制。

• 修補是否能消除風險，而不是單純讓掃描器不再告警。

注意： CodeQL 的可用語言、掃描能力與告警呈現方式會受到 GitHub 產品功能、方案及 Repository 設定影響。工作流程成功，也不等於所有安全問題都已解決。

四、Semgrep：使用規則掃描不安全的程式碼模式

官方網站：Semgrep

Semgrep 適合快速檢查程式碼，也能透過自訂規則，將團隊自己的安全要求轉成可重複執行的檢查。

步驟一：安裝工具

可以透過 Python 工具環境安裝 CLI，例如：

python -m pip install semgrep

如果希望隔離 Python 工具的安裝環境，也可以使用 pipx。

安裝後確認：

semgrep --version

步驟二：掃描專案

在專案根目錄執行：

semgrep scan --config auto .

這個命令會依照 Semgrep 支援的自動設定選取規則並掃描專案。實際使用的規則集、帳號需求與可用功能，依 Semgrep 版本及服務設定而異。

也可以指定特定規則集，或使用自己撰寫的規則。

步驟三：建立自訂規則

例如，希望在 Python 專案中找出直接呼叫 eval() 的程式碼，可以建立 rules/python-security.yml：

rules:
  - id: python-dangerous-eval
    languages:
      - python
    severity: WARNING
    message: Avoid eval() on untrusted input.
    pattern: eval(...)

接著執行：

semgrep scan \
  --config rules/python-security.yml \
  backend/

這個規則只是示範如何偵測一種程式碼模式，不能直接判斷所有命中都構成可利用的漏洞，也不能涵蓋所有動態執行程式碼的風險。

步驟四：將規則整合進 GitHub Actions

name: Semgrep Scan

on:
  pull_request:
  push:
    branches: [main]

permissions:
  contents: read

jobs:
  semgrep:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - uses: semgrep/semgrep-action@v1

這個範例展示官方 Action 的基本整合方式。正式使用前，應依 Semgrep 當前文件確認 Action 版本、規則設定、認證需求與輸出格式。

若只是想先驗證規則是否有效，直接在本機執行 CLI 通常更容易除錯。

實務建議： CodeQL 與 Semgrep 不必一開始就同時啟用所有規則。先選擇與專案語言和主要風險相符的規則，再依實際誤報情況調整。

五、Gitleaks：防止 API Key 與密碼進入 Git

官方專案：Gitleaks

Gitleaks 用於尋找疑似硬編碼的機密資訊，例如資料庫密碼、Token、API Key 與私鑰。

這類問題很容易被忽略，因為程式碼即使功能正常，仍可能將正式環境的存取憑證暴露在版本控制系統中。

步驟一：安裝 Gitleaks

請依官方 README 選擇作業系統對應的安裝方式。

安裝後確認：

gitleaks version

步驟二：掃描 Git Repository

在專案根目錄執行：

gitleaks git .

這會掃描 Git Repository 的提交內容。若要掃描尚未提交的檔案，也可以依目前版本的 CLI 使用 dir 模式。

例如：

gitleaks dir .

兩種模式的檢查對象不同：Git 模式重點在 Repository 的 Git 內容，目錄模式則針對目前檔案內容。

步驟三：解讀結果

如果發現疑似憑證，先確認：

1. 這是否為真實有效的機密資訊？

2. 是否曾經被提交或推送到遠端？

3. 是否需要撤銷或輪替憑證？

4. 是否需要清理 Git 歷史？

5. 是否應將憑證移至環境變數或 Secret Manager？

不要只把密碼從目前檔案刪除，就認為風險已經解除。

如果憑證曾經公開，應優先撤銷或輪替，再評估歷史紀錄的處理方式。

步驟四：整合 GitHub Actions

可以使用 Gitleaks 官方 Action：

name: Secret Scan

on:
  pull_request:
  push:
    branches: [main]

permissions:
  contents: read

jobs:
  gitleaks:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - uses: gitleaks/gitleaks-action@v2
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

這是基本整合示例。正式使用時應依官方 Action 文件確認版本、授權需求、完整歷史掃描方式與 Repository 權限。

fetch-depth: 0 用於取得完整 Git 歷史，對需要檢查提交紀錄的工作流程尤其重要。

六、Trivy：掃描依賴套件、Docker 映像與設定

官方網站：Trivy

Trivy 是一套涵蓋多種掃描目標的安全工具，適合用來補足單純的原始碼分析。

它可以檢查支援的依賴套件、容器映像、Infrastructure as Code 設定，以及疑似機密資訊。

步驟一：掃描專案檔案

安裝方式請參考官方文件：

Trivy Installation

在專案根目錄執行：

trivy fs .

這會對檔案系統進行預設掃描。

若要明確指定要檢查的類別，可以使用：

trivy fs \
  --scanners vuln,misconfig,secret \
  .

這個命令要求 Trivy 執行漏洞、設定與機密資訊掃描。實際結果取決於專案檔案、工具版本與可用的漏洞資料庫。

步驟二：掃描 Docker Image

先建立映像：

docker build -t my-project:local .

接著掃描：

trivy image my-project:local

如果只希望先關注高風險告警，可以使用：

trivy image \
  --severity HIGH,CRITICAL \
  my-project:local

這樣可以縮小初期檢查的範圍，但不代表低風險問題就不需要處理。

步驟三：讓高風險問題阻擋 Pipeline

例如：

trivy image \
  --severity HIGH,CRITICAL \
  --exit-code 1 \
  my-project:local

當符合條件的告警出現時，Trivy 可以使用非零退出碼，讓 CI 工作失敗。

正式環境應先確認告警的數量、誤報與修補政策，再決定是否直接阻擋合併或部署。

步驟四：整合 GitHub Actions

name: Trivy Scan

on:
  pull_request:
  push:
    branches: [main]

permissions:
  contents: read

jobs:
  scan:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - name: Scan filesystem
        uses: aquasecurity/trivy-action@0.28.0
        with:
          scan-type: fs
          scan-ref: .
          scanners: vuln,misconfig,secret
          severity: HIGH,CRITICAL
          exit-code: "1"

這裡的 Action 版本是示範值，不應直接視為目前最新版本。正式導入時，請從官方 Trivy GitHub Actions 文件確認適用版本與參數，並考慮將 Action 固定到經審核的完整 Commit SHA。

如果要掃描容器映像，則需要先建立映像，再將掃描目標改為對應的 Image。

七、Dependabot：持續追蹤第三方依賴漏洞

官方文件：Dependabot

與每次手動執行掃描不同，Dependabot 可以持續追蹤支援的套件生態系與版本更新，協助團隊處理已知漏洞。

步驟一：建立設定檔

建立 .github/dependabot.yml。

以下示範 Python 與 npm 專案：

version: 2

updates:
  - package-ecosystem: pip
    directory: "/backend"
    schedule:
      interval: weekly

  - package-ecosystem: npm
    directory: "/frontend"
    schedule:
      interval: weekly

  - package-ecosystem: docker
    directory: "/"
    schedule:
      interval: weekly

  - package-ecosystem: github-actions
    directory: "/"
    schedule:
      interval: weekly

這份設定會讓 Dependabot 定期檢查指定目錄中的 Python、npm、Docker 與 GitHub Actions 依賴。

請依專案實際的 lockfile、Dockerfile 位置與套件管理方式調整路徑。若是 Laravel 專案，也可以依需求加入 Composer 生態系設定。

步驟二：查看告警與更新 PR

啟用適用的 Repository 安全功能後，可以檢查 Dependabot Alerts，了解受影響套件、漏洞資訊與建議版本。

Dependabot 也可能提出更新 Pull Request，讓開發者檢查變更。

步驟三：確認修補是否安全

更新依賴套件時，不應只看版本號。

應確認：

• 是否真的更新到修補版本？

• 是否引入不相容的 API 變更？

• 是否通過既有測試？

• 是否還有其他依賴引入相同漏洞？

• 正式環境是否實際使用了受影響的套件？

Dependabot 的價值在於協助持續追蹤和維護依賴，不是自動保證每一次更新都沒有風險。

八、Cloudflare Security Audit Skill：讓 AI Agent 參與安全審計

官方專案：cloudflare/security-audit-skill

前面介紹的工具主要依靠分析規則、已知漏洞資料與特定檢查機制找出風險。

Cloudflare Security Audit Skill 則採取不同方向：將安全審計拆成多個階段，利用具備工具使用能力的 Coding Agent 協助分析程式碼，並讓候選漏洞接受獨立驗證。

它不是 CodeQL 或 Trivy 的替代品，也不是單純安裝後就能自行執行的傳統掃描器。

步驟一：確認執行環境

在開始之前，需要準備：

• 支援 Skill 工作流程的 Coding Agent。

• 能夠讀取 Repository、搜尋程式碼與使用必要工具的權限。

• 若要使用完整審計流程，需要具備適當的子 Agent 協調能力。

• 能夠安全執行不受信任程式碼的作業系統層級沙箱。

尤其要注意，不要直接在具有正式環境憑證的主機上執行不受信任的測試程式碼。

步驟二：安裝 Skill

官方專案提供 Skill 安裝方式與相容性說明。若使用支援 Skills CLI 的環境，可以依官方文件採用類似以下的安裝命令：

npx skills add \
  https://github.com/cloudflare/security-audit-skill \
  --skill security-audit

這個命令適用於支援該 CLI 與 Skill 格式的環境；不同 Coding Agent 的安裝方法可能不同，請以官方 README 為準。

步驟三：先進行小範圍審計

初次使用時，不建議直接要求 AI 掃描整個大型 Repository。

可以先針對一個 API 模組，明確指定審計範圍與目標，例如：

• 身分驗證流程

• 物件層級授權

• 租戶資料隔離

• 敏感資料寫入

• 稽核紀錄修改權限

如果只是詢問某個問題，應使用與問題相符的聚焦審查模式；如果要執行完整審計並產生報告，則應明確要求完整審計流程。

步驟四：使用明確的審計要求

以下提示詞可以作為開始的範例：

請使用 Cloudflare Security Audit Skill，
審查目前 Repository 中的供應商資料 API。

審計目標：
1. 檢查身分驗證與物件層級授權。
2. 檢查是否存在跨租戶資料存取風險。
3. 追蹤路由、驗證依賴、資料查詢與權限判斷。
4. 每個候選漏洞都必須提供原始碼證據。
5. 使用獨立驗證流程嘗試推翻候選漏洞。
6. 證據不足的問題應保留為待驗證，
   不得直接列為已確認漏洞。

限制：
- 不修改正式程式碼。
- 不存取正式環境。
- 不執行未經隔離的不受信任程式碼。
- 不得將 AI 推測當成漏洞證據。

請依照 Skill 定義的流程與輸出格式產生結果。

這是任務提示詞範例，不代表貼上後就會自動具備所有安全能力。實際執行仍取決於 Agent 是否支援該 Skill、工具權限與沙箱配置。

步驟五：理解審計輸出

Cloudflare Skill 的工作流程包含候選漏洞、結構化結果與獨立檢查。依專案定義，結果可以分為：

狀態	意義
confirmed	已有足夠證據支持漏洞成立
needs_validation	尚有必要條件或證據需要確認
rejected	候選問題已被證據推翻

閱讀報告時，應確認每個發現是否包含：

• 受影響的程式碼位置。

• 涉及的信任邊界與攻擊條件。

• 實際影響與受影響的使用者或資源。

• 支持或反駁結論的證據。

• 安全的驗證方式與建議修補方向。

如果報告只說「這段程式碼可能不安全」，卻沒有說明攻擊者能控制什麼、能影響什麼，就還不足以成為完整的漏洞判定。

更重要的是，獨立 Agent 的驗證仍然不是形式上的安全證明。高風險發現應再透過人工審查與適當的測試確認。

九、把工具整合成一條安全檢查流程

前面六種工具可以依照各自的責任範圍，整合成一個分層的安全檢查流程。

Developer Push / Pull Request
              |
              v
      GitHub Actions
              |
      +-------+--------+
      |       |        |
      v       v        v
   CodeQL  Semgrep  Gitleaks
      |       |        |
      +-------+--------+
              |
              v
       Trivy / Dependency
       and Container Scan
              |
              v
       AI Agent Security
            Review
              |
              v
      Independent Verification
              |
              v
       Human Review
              |
              v
      Fix + Regression Tests
              |
              v
           Deploy

這是建議的整合架構，而不是每個工具都必須依序執行的固定規範。

實際上，可以依照執行成本與風險，安排不同的頻率：

• 每次 Pull Request 執行快速、可重複的掃描。

• 每週或重大架構變更時執行較深入的 AI 安全審計。

• 高風險問題修補後，執行針對性的安全測試與回歸測試。

• 正式部署前，確認高風險問題的處理狀態。

初次導入時，也不一定要立刻讓所有掃描結果阻擋合併。可以先觀察告警品質，再逐步建立高風險問題的阻擋政策。

十、如何判斷這套流程是否真的有價值？

不要只用「執行了幾種工具」衡量資安流程的成效。

更值得追蹤的指標包括：

1. 有效發現率： 掃描結果中，有多少問題經過驗證後仍然成立。

2. 誤報處理成本： 團隊需要花多少時間排除不成立的告警。

3. 漏洞修補時間： 從發現問題到完成修補需要多久。

4. 驗證證據完整性： 每個高風險發現是否有可追蹤的程式碼位置、影響範圍與驗證紀錄。

5. 回歸風險： 修補是否造成原有功能失效或破壞資料完整性。

6. 審計覆蓋率： 是否明確記錄已檢查與尚未檢查的範圍。

這些指標可以幫助團隊判斷：新增 AI Agent 後，究竟是提高了安全審計品質，還是只增加了更多報告與執行成本。

十一、結語：Security as Process，而不只是 Security as Tool

CodeQL、Semgrep、Gitleaks、Trivy 與 Dependabot，分別處理程式碼、機密資訊、依賴套件與部署環境等不同風險。

Cloudflare Security Audit Skill 則展示了如何把 AI Agent 納入更完整的審計流程，讓候選漏洞經過驗證、證據整理與獨立檢查。

這兩種方式並不衝突。

傳統掃描工具提供可重複執行的檢查；AI Agent 則可以協助分析更複雜的程式碼上下文與攻擊情境。兩者結合後，仍然需要人工判讀、適當的測試與安全的執行環境。

未來資安工具的競爭，可能不再只是誰能找到更多漏洞，而是誰能建立更可信的 Verification Chain，讓漏洞發現、驗證、修復與追蹤形成可持續運作的工程流程。

這也是從傳統 DevSecOps 走向 AI Agent Security Review 時，最值得深入研究的工程問題。