概念位置

它位在模型層與安全治理交界，跟 model card 不同：model card 提供 metadata，supply-chain trust 判斷來源、hash、量化流程、namespace 與散發路徑是否可信。

可觀察訊號與例子

官方 organization、知名量化者、verified registry、可比對 hash、清楚 license 與 model card 都提升信任；個人上傳、來源不明、檔案被替換、缺 metadata 都降低信任。GGUF、Safetensors、Ollama registry、Hugging Face Hub 都在這條鏈上。

設計責任

下載模型前確認來源；下載後記錄 SHA-256、檔案大小與版本；第三方量化要看量化者信譽與社群採用。MCP server 與 plugin 是另一條可執行程式碼供應鏈，要用更高權限標準判讀。

讀完本章後、你應該能對自己用的模型回答：來源是不是作者本人 / 官方鏡像、檔案完整性怎麼驗、量化版本是不是社群常用的、第三方再上傳的版本該不該用。

本章目標

1. 認識本地 LLM 模型供應鏈的角色：原始作者 → 官方 release → 第三方量化 → registry 散發。
2. 知道個人 dev 場景的信任邊界跟驗證手段。
3. 區分「官方版本」、「社群熱門量化」、「個人上傳」三種來源的信任等級。
4. 用 GGUF 檔案完整性檢查（hash、檔案大小、metadata）建立基本驗證流程。
5. 認識 Ollama / Hugging Face / LM Studio model browser 的供應鏈差異。

本地 LLM 模型供應鏈的角色鏈

1原始作者（如 Meta、Google、Qwen 團隊）
2  ↓ 發布原始權重（safetensors / pt、通常 fp16 或 bf16）
3官方 Hugging Face organization
4  ↓ 第三方量化者（如 bartowski、TheBloke、unsloth）
5量化版本 GGUF（Q4_K_M、Q5_K_M 等）
6  ↓ Ollama 收進 registry 或社群上傳
7Ollama registry / LM Studio 內建瀏覽器
8  ↓ 使用者拉下來
9本機 GGUF 檔案

每一層都是潛在的信任邊界：

1. 原始作者：信任假設是「作者發布的權重就是訓練出來的權重、沒被植入後門」。個人 dev 場景下、選主流作者（Meta、Google、Qwen、Mistral 等）的官方發布通常是合理起點。
2. 量化者：把官方 fp16 權重壓成 Q4 / Q5 等 GGUF 格式的人。社群常見熱門量化者（如 bartowski、unsloth）有公開的量化腳本與長期信譽、但仍是個人或小團隊、不是企業簽章。
3. registry 散發：Ollama registry、HF Hub、LM Studio 內建瀏覽器是分發層。可能被搶 namespace、可能有人偽造「官方」名義上傳。
4. 本機儲存：下載完的 GGUF 檔案在硬碟、後續執行時權重本身就是程式邏輯的一部分（透過 inference 影響輸出）。

事實查核註：上面的角色鏈是 2026 年 5 月的常見運作模式。具體量化者、registry 政策、模型分發流程依平台變化、建議引用前以 Hugging Face、Ollama、LM Studio 各自的安全公告與 community guidelines 為準。

三種來源的信任等級

個人 dev 場景下、常見的模型來源可以分成三個信任等級：

「中等」跟「較高」的差別主要在「企業簽章」這個維度——Hugging Face verified organization 對應「該組織確實是 Meta / Google / Qwen 等主體」、但不對「該組織內部 release process 是否安全」做擔保。即使是官方發布、仍是「人類團隊發布的權重」、不是密碼學意義的零信任。

GGUF 檔案完整性的基本檢查

下載完 GGUF 檔案後、可以做幾個輕量檢查確認檔案完整性：

 1# 1. 比對檔案 SHA-256（HF / Ollama 通常會列出官方 hash）
 2shasum -a 256 ~/.ollama/models/blobs/sha256-xxx
 3# 或
 4sha256sum Qwen3-30B-A3B-Q4_K_M.gguf
 5
 6# 2. 看檔案大小是否跟 model card 標示一致
 7ls -la Qwen3-30B-A3B-Q4_K_M.gguf
 8
 9# 3. 用 llama.cpp 的工具看 GGUF metadata
10./gguf-dump.py Qwen3-30B-A3B-Q4_K_M.gguf | head -50
11# 確認 architecture、context_length、量化等級跟預期一致

這些檢查能擋住：

1. 下載中斷導致檔案不完整：hash 不對、跑不起來、不是安全議題但會誤導判讀。
2. CDN / 鏡像中間人替換：理論可能、實務上 Hugging Face 跟 Ollama 走 HTTPS、TLS 完整性是基礎防護；hash 比對是額外確認。
3. 誤拉到不同量化版本：例如想拉 Q4_K_M 結果拉到 Q4_0、檔案大小跟 metadata 會反映出來。

擋不住：

1. 量化者本身在量化過程做了手腳：hash 對得上、但權重已經被改過。這需要回到原始作者的權重重新量化、屬於進階驗證、個人 dev 場景通常不做。
2. 作者本身在發布的權重裡植入後門：個人 dev 場景的 threat model 假設主流作者不會做這件事；若不信任、不應該用該模型。

事實查核註：GGUF 檔案的完整性檢查工具跟流程依 llama.cpp 版本變化、gguf-dump.py 等腳本路徑可能改名或棄用、以實際 llama.cpp release 跟 GGUF 規格 為準。

Ollama / Hugging Face / LM Studio 的供應鏈差異

三個 registry 在實際拉模型的操作面（namespace、download 指令、本機儲存路徑）見對應安裝章節：1.0 Ollama、1.1 LM Studio、PC 場景的 LM Studio 見 5.4。本節聚焦三者在供應鏈管理上的相對位置：

實務上、社群常見的選擇路徑：

• 想拉 official 模型：優先 Hugging Face official organization、或 Ollama library/ namespace
• 想拉熱門量化：bartowski / unsloth 等知名量化者的 HF repo、Ollama 通常也會把熱門模型收進 official library
• 看到個人 repo 上傳的「特別優化版」：除非有明確來源說明、否則保守看待

量化版本污染的可能性

量化版本污染的具體威脅形態：

1. 量化腳本被改過：量化者公開的腳本跟實際跑的腳本不一致、產出的權重跟「按公開腳本量化」會不同。
2. 量化過程引入後門：在量化的同時微調權重、在特定 prompt 下觸發特定行為。技術上可行、實務上社群罕見公開案例、但無法事前完全排除。
3. 量化版本被替換上傳：先上傳乾淨版本累積下載量、再替換成有問題的版本。HF / Ollama 都有 file history、但個人 dev 通常不會檢查。

個人 dev 場景的合理應對：

1. 優先用知名量化者的版本：bartowski / unsloth 等有長期紀錄的量化者、相對個人首次上傳信任度較高。
2. 下載後立刻記錄 hash：作為日後比對基準；若日後同一 model name 但 hash 變了、值得查 history。
3. 大型 codebase 任務前先用簡單 prompt 試模型：例如「fn main() { println!("hi"); }」這類；確認模型行為基本合理、再用於真實任務。

第三方 plugin / MCP server 的供應鏈

模型本身的供應鏈之外、Continue.dev / MCP server / Ollama plugin 等也構成供應鏈、且風險形態不同：

1. MCP server 多為可執行程式碼：安裝 MCP server 等於在本機跑第三方程式碼、權限影響大於 GGUF 檔案（GGUF 只在 inference 時影響輸出、MCP server 可以直接讀寫檔案、呼叫 shell）。
2. Continue.dev 擴充套件：VS Code marketplace 有基本審查、但 community-published 擴充套件的供應鏈仍是個人視角。Continue.dev 安裝與 multi-provider 配置見 1.3。
3. Ollama Modelfile 中的指令：Modelfile 內可以指定 template、system prompt 等、若使用社群分享的 Modelfile、要看完內容再用。

MCP server 的權限模型詳見 6.2 tool use 與 MCP server 的權限模型。

事實查核註：MCP（Model Context Protocol）的安全模型仍在演進、各 MCP server 實作的權限粒度、認證機制依版本變化、建議引用前以 MCP 官方文件 跟具體 MCP server 的 README 為準。

給讀者的判讀流程

實際下載 / 切換模型時的判讀流程：

1. 確認來源 organization / namespace：是 official、知名量化者、還是個人上傳。
2. 比對檔案完整性：對主流量化等級、HF / Ollama 通常提供 hash；下載完做一次 hash 比對。
3. 記錄 hash 到本機 inventory：建一份 ~/models/inventory.md、記錄每個 GGUF 的來源 URL、下載日期、SHA-256。
4. 試模型基本行為：用簡單 prompt 確認模型行為合理。
5. 若是新 MCP server：分開判讀供應鏈（看 6.2）、不要把 GGUF 跟 MCP 的信任邊界混在一起。

下一章

下一章：6.1 推論伺服器的綁定與暴露範圍、處理伺服器跑起來後的第一個對外接觸面。

概念位置

典型的 model card 包含哪些區段（依平台跟模型而異）：

事實查核註：Hugging Face 推動 Model Card 規範跟 Model Card Toolkit、但實際填寫品質依 organization 變化、部分 repo 的 model card 內容很簡略、不能 100% 依賴。引用前以該 repo 當前內容為準。

設計責任

理解 model card 後可以解釋兩個現象：為什麼選模型不能只看名字（同個 base model 的不同 fine-tune 版本能力差很多）、為什麼商用前要看 license（Llama Community License、Apache 2.0、MIT 等差異大）。

實務上選模型時、model card 是第一閱讀對象、其他資訊（社群評測、benchmark leaderboard）作為交叉驗證；引用模型時應該明確記下「base model + fine-tune 變體 + 量化版本」三層。詳見 6.0 模型供應鏈與信任邊界 跟 LLM Deployment 供應鏈完整性。

服務定位

GHAS 的核心定位是 把 application security 控制面收斂回 GitHub 平台：SAST、Secret Scanning、Dependency Review、Dependabot 共用 GitHub 的 identity / permission / PR / branch protection / Actions / Security tab，讓 security finding 跟 code review 在同一個 surface 上決策。這跟 Snyk 走「跨 SCM、跨雲、自有 dashboard」是相反方向 — Snyk 把 security 抽到平台之上、GHAS 把 security 釘在 GitHub 之內。

跟 Trivy 比、定位差更遠。Trivy 主打 container image / IaC / SBOM scan、open-source 免費、適合塞進任何 CI；GHAS 主打 source code + secret + dependency、Enterprise 付費、container scan 有但偏弱。兩者通常 並存 — Trivy 跑 container artifact、GHAS 跑 source repo。

跟 Dependabot 的關係是 內含 — Dependabot 是 GHAS 四模組之一、跟 GHAS 同一個控制平面、跟 PR / Security tab 同一條 evidence chain。本頁聚焦 GHAS 整體 + Code Scanning / Secret Scanning / Dependency Review；Dependabot 的 update PR 政策、ecosystem 覆蓋、alert routing 細節留在該頁。

關鍵張力：GHAS 計費走 per-active-committer + per-repo、2024 後 Secret Scanning 跟 Code Scanning 拆開計費。大型 mono-repo 或 committer 數量膨脹的組織會撞到成本天花板、需要選擇性 enable repo + 拆模組買；同時、Push Protection 這類 預防型 控制只有 enable 後才有效、選擇性 enable 等於默認 risk 接受。

本章目標

讀完本頁、讀者能判斷：

1. GHAS 四大模組各自承擔哪段控制責任（SAST / Secret / PR-level dependency gate / 自動 update）、哪些跟 Snyk / Trivy 重疊或互補
2. CodeQL 跟 SARIF 標準的關係、為什麼第三方 SAST 工具的 finding 也能進 GHAS Security tab
3. Secret Scanning 的 Push Protection（預防 push）跟 Secret Scanning Alert（偵測 leaked）的職責差、partner pattern vs custom pattern 何時用
4. 何時用 GHAS、何時改走 Snyk / Trivy / GitLab Ultimate（GitLab 自家相當品）

最短判讀路徑

判斷 GHAS 配置是否健康、最少看四件事：

• 誰能 enable / disable：Organization owner / Security manager role 配置、enable GHAS 的 audit log 是否同步、誰能改 Code Scanning workflow（branch protection 是否擋住 workflow file 直接 push）
• 哪些 repo 開啟：Org Security overview 看 Code Scanning / Secret Scanning / Dependency Review coverage、新建 repo 是否預設啟用（Organization-level default setting）、private / internal / public repo 是否一致開啟
• Push Protection 狀態：Secret Scanning Push Protection 是否 organization-wide enable、bypass 權限給誰（developer 個人 bypass vs 必須走 Security team approval）、bypass 事件是否進 audit
• Secret Scanning Coverage：partner pattern（AWS / GCP / Stripe / Slack 等預配）是否全開、custom pattern 是否涵蓋自家 internal token（service token、internal API key）、historical scan 是否跑過（不只新 commit、舊 commit 也要掃）

四件事任一缺失、就是 Secret Management 跟 Supply Chain Integrity 邊界的待補項目。

日常操作與決策形狀

Code Scanning 走 SARIF 標準：Code Scanning 不只是 CodeQL 的 UI、是 SAST aggregation layer。所有 SAST 結果（CodeQL 預設、或 Semgrep / Snyk Code / Brakeman / Bandit / SonarCloud / Checkmarx 等第三方）以 SARIF（Static Analysis Results Interchange Format）upload 到 Code Scanning、Security tab 統一展示、PR review 統一標註。意義是 組織可以用多個 SAST 工具但只看一個 dashboard — 不需要每個 vendor 各自登入。多工具 SARIF upload 用 GitHub Actions 的 github/codeql-action/upload-sarif step。

CodeQL 是 first-class query language：CodeQL 用 Datalog-like 語法寫 自定 query、可以檢測 organization-specific anti-pattern（例：禁用某內部 deprecated function、強制 input validation 在特定 trust boundary）。vendor-provided pack（GitHub 維護的 CodeQL pack）覆蓋 OWASP Top 10 / CWE Top 25、自定 query 補組織 idiomatic check。代價是 CodeQL 學習曲線陡 — 不是 regex / AST pattern、是完整的 graph query language。

Secret Scanning 三層職責：Secret Scanning 分三層。Partner pattern — GitHub 跟 AWS / GCP / Stripe / Slack / npm 等 vendor 預配 token pattern、預設 detection 範圍最大、leaked token 還會通知 vendor revoke。Push Protection — commit push 前 scan、發現 secret 直接 reject push、開發者必須先移除才能 push；這是 預防 不是 偵測、不需要等 leaked 後 rotation。Custom pattern — 組織自己的 internal token（service-to-service API key、legacy auth token）寫 regex pattern、配 validation endpoint 降 FP。

Dependency Review 是 PR-level gate：每個 PR 跑 新增 / 升級依賴的漏洞檢查 + license check、把 新引入 CVE 列在 PR review、可設 branch protection 強制 PR 過 Dependency Review 才能 merge。這跟 Dependabot 是互補關係：Dependabot 是 已 merge 依賴的 update PR（時間軸：merge 後 vuln 出現、自動發 update PR）、Dependency Review 是 PR 加新依賴時的 gate（時間軸：merge 前 vuln 已知、擋 PR）。兩條軸都要開。

Security overview 是 org-level dashboard：Organization Security tab 看 跨 repo 的 Code Scanning / Secret Scanning / Dependency / Dependabot alert 彙整、用 repo / severity / age filter 排序。對於 security team 不是 repo owner 的組織、Security manager role 給 security team 跨 repo read + triage 權限、不需要 admin。

Security Advisories（CVE 揭露 workflow）：自家 OSS / 商業 product 出 CVE 時、走 GitHub Security Advisory — 在 private fork 修補、coordinated disclosure 時間到公開 advisory、GitHub 自動向 CVE Numbering Authority 申請 CVE ID。這條 workflow 是 維護者視角、不是 使用者視角；使用者收到的是其他人發的 advisory 進 Dependabot alert。

SARIF integration 是 GHAS 的 aggregation 角色關鍵：GHAS 不強迫只用 CodeQL — Snyk Code / Semgrep / SonarCloud 等 SAST 工具跑完輸出 SARIF、CI 上傳到 GitHub、Security tab 集中展示。意義是 組織用 Snyk 做 SAST、但 finding 走 GHAS UI 是合法配置；GHAS 賣的不只是 CodeQL、是 SAST 統一視圖。

核心取捨表

選 GHAS 的核心訴求：GitHub 是 SCM + 想 PR review 跟 security finding 合一 + Enterprise 預算可吸收 per-committer cost。GitLab 主要的組織直接走 GitLab Ultimate 的對等功能；多 SCM 或 container 為主走 Snyk + Trivy 組合。

進階主題

CodeQL custom query 開發：寫自定 query 用 CodeQL CLI 本地開發、跑 codeql database analyze、SARIF output 上傳。常見場景：禁用 internal deprecated API、特定 framework 的 misuse pattern、組織 idiomatic security check。Query pack 可以 publish 到 GitHub Container Registry 或 internal registry、跨 repo 復用。代價是 維護成本 — CodeQL query language 學習曲線陡、組織需要至少 1-2 個 security engineer 專門養護。

Push Protection bypass workflow：Push Protection reject push 後、developer 可以 bypass（標記 false positive / test data / 風險已知）。Bypass 權限治理是關鍵 — 開放給 developer 個人 bypass 失去預防意義、強制 Security team approval 又拖慢 dev velocity。常見折中：低風險 pattern（test fixture token）developer 可 bypass、高風險 pattern（production credential）必須 Security team approve；所有 bypass 事件進 audit log。

跟 GitHub Actions 整合：Code Scanning 走 GitHub Actions workflow 跑 CodeQL — github/codeql-action/init + github/codeql-action/analyze。同 workflow 可以加 upload-sarif step 接第三方 SAST 結果。Actions 用 GitHub-hosted runner 跑 CodeQL 是預設、大型 repo 跑 CodeQL analyze 可能超時、需改 self-hosted runner（大 RAM / 多 CPU）— 但 self-hosted runner 自身是 supply chain 風險、需要 ephemeral runner + 限制 secret access。

SARIF 多工具整合：第三方 SAST / SCA / Container scan 工具（Snyk / Semgrep / Trivy / Brakeman / Bandit / Gosec）跑完輸出 SARIF、CI 上傳到 GHAS。實務上組織常用 CodeQL + Semgrep 雙軌 — CodeQL 跑深度 graph query、Semgrep 跑快速 pattern 規則；finding 在 Security tab 用 tool filter 分開看。

Secret Scanning partner pattern：GitHub 維護的 partner pattern list 涵蓋 AWS / GCP / Azure / Stripe / Slack / npm / Docker Hub / GitHub PAT 等。leaked token detect 後、GitHub 自動通知 vendor、vendor 端可選擇 自動 revoke 該 token。意義是 組織不需要做 rotation — vendor 已經把 leaked token 廢掉。custom pattern 則需要組織自己提供 validation endpoint、GHAS 呼叫驗證才確認是真 leak。

GHAS Cloud-hosted vs Self-hosted Runner 治理：CodeQL 跑在 GitHub-hosted runner 是預設、所有 source code 上傳到 GitHub 運算環境。對 source code 機密度高 的組織（金融 / 國防 / 法規限制 source 出境）、需走 self-hosted runner。Self-hosted runner 的供應鏈風險見 GitHub OAuth 2022 — runner token 是 supply chain entry、OIDC short-lived token 是建議方向。

GHAS Enterprise pricing trap：Per-active-committer 計費、organization 內所有 過去 90 天有 commit 的 user 都算 active committer、即使只 commit 1 行也計費。大型公司容易超支；2024 後 Secret Scanning 跟 Code Scanning 拆開計費、可只買 Secret Scanning（單價較低）給全 org、Code Scanning 給關鍵 repo。Public repo 上 GHAS 功能多數免費（Code Scanning、Secret Scanning、Dependency Review）；GitHub Enterprise Cloud 的 internal / private repo 才落入 GHAS 計費範圍 — 兩者範圍不同、新組織常踩到把 private repo 全開的成本。

排錯與失敗快速判讀

• 新建 repo 沒自動開 GHAS：Organization-level default 沒設、新 repo 預設 disable — 開 Organization Security settings 的 Enable for new repositories、現有 repo 用 bulk enable
• Push Protection 大量誤殺：custom pattern regex 太寬、合法字串被當 secret — 加 validation endpoint 或收緊 regex、bypass 統計看 FP rate
• Secret Scanning 沒掃歷史 commit：只 enable 後新 commit 觸發、舊 commit leaked secret 沒被發現 — 跑 historical scan（enable 後 GitHub 自動掃過去全部 commit）、可能花數小時
• Dependency Review 沒擋住 vuln PR：Branch protection 沒加 Dependency Review required check — 加進 required status check、新 PR 才強制過
• Code Scanning workflow 跑很久 / 超時：repo 太大、GitHub-hosted runner RAM 不足 — 換 larger runner（GitHub Larger Runners）或 self-hosted、或只跑 changed file analysis
• Custom CodeQL query FP 多：query 寫得太寬、commit 都跳 alert — 加 @precision high 標籤、用 Sink-Source 分析降低 reach
• 第三方 SAST SARIF 沒進 Security tab：upload-sarif step 沒設對 category 或 permissions — security-events: write permission 必須在 workflow 給；同 repo 多工具用不同 category 區分
• Bypass 沒進 audit：Push Protection bypass 沒同步到 SIEM — Enterprise audit log streaming 開、event filter 加 secret_scanning.bypass

何時改走其他服務

不在本頁內的主題

• CodeQL 完整 query language reference
• Dependabot 的 update PR 政策、ecosystem 覆蓋、grouped update（見 Dependabot vendor 頁）
• GHAS Enterprise Server（自管 GitHub）跟 Cloud GHAS 的功能差異
• 各語言 / 框架的 CodeQL pack 完整覆蓋表
• GHAS 跟 GitHub Copilot Autofix 整合的 AI-assisted remediation 細節

案例回寫

GHAS 在 07 案例庫沒有 直接 GHAS-level vendor 事件。對照引用展示 GHAS 在 supply chain / source-level 控制的能力邊界：

下一步路由

• 上游：7.12 供應鏈完整性與 Artifact 信任
• 平行：Snyk、Trivy、Dependabot、Syft + Grype（SBOM 走 SARIF 進 GHAS Code Scanning 是常見組合）
• 下游：7.6 秘密管理與機器憑證治理（Secret Scanning 配 Vault rotation）
• 跨類：7.13 偵測覆蓋率與訊號治理（GHAS alert 進 SIEM 的 routing）
• 跨模組：8 事故處理 vendor 清單（leaked secret / SAST critical finding 進 IR 流程）
• 官方：GitHub Advanced Security Documentation

服務定位

Snyk 的核心定位是 用一個工具一個 dashboard 同時管 SCA + SAST + IaC + Container + Cloud。五大模組 — Snyk Open Source（SCA、依賴漏洞）、Snyk Code（SAST）、Snyk Container（image scan）、Snyk IaC（Terraform / CloudFormation / K8s manifest 安全）、Snyk Cloud（CSPM、雲端配置 drift）— 共用 Project / Target / Organization / Issue 模型、Issue 跨模組可一起 prioritize。對 多 SCM + 多技術棧 的組織、Snyk 比拼裝 GHAS + Trivy + Dependabot 更整合。

跟 GitHub Advanced Security 的核心差異是 部署模型跟 SCM 範圍：GHAS 綁 GitHub、走 GitHub Actions、PR 整合更深（Code Scanning alert 直接顯示在 PR review）；Snyk 走 SaaS、SCM 中立、但需要 OAuth 連到每個 repo。組織用 GitLab / Bitbucket / Azure Repos 或同時用多種 SCM、Snyk 是天然選擇。

跟 Trivy 比、Trivy 是 OSS、主 container + IaC、適合 CI 內 self-hosted；Snyk 商業 SaaS、覆蓋更廣（含 SAST 跟 Reachability）、適合 組織級 governance + 跨團隊統一 dashboard。Trivy 是 跑工具、Snyk 是 買治理。

關鍵張力：Snyk 的 Project 是計費單位。每個 manifest 算一個 Project（一個 repo 有 package.json + requirements.txt + Dockerfile = 3 Project）。大 monorepo 容易暴量、需要 project filter / archive 治理、否則年費失控。

本章目標

讀完本頁、讀者能判斷：

1. Snyk 五大模組在 application security stack 承擔哪一段、哪些靠其他工具
2. Project 計費模型、monorepo 跟 multi-manifest repo 的 Project 暴量風險跟治理路徑
3. Reachability analysis 的價值跟限制、何時減 noise、何時被誤判
4. 何時用 Snyk、何時走 GHAS / Trivy / Dependabot 的取捨

最短判讀路徑

判斷 Snyk 配置是否健康、最少看四件事：

• 誰能 enable Snyk：Organization 的 admin / collaborator role 配置、Service Account token scope（不要用 personal API token 跑 CI、用 Service Account + scoped token）、Audit Log 是否同步到 SIEM
• Project import 治理：每個 SCM target 自動 import 哪些 manifest、是否有 project filter 排除 test fixture / vendored dependency、archived project 是否真的不計費、monorepo 是否走 .snyk policy file 控制
• Reachability analysis 是否啟用：Snyk Code + Open Source 整合、call graph 分析「我的 code 真的呼叫到 vulnerable 函式嗎」— 大幅減少 transitive dep 但 unreachable 的 noise、production 應該啟用
• SBOM export 是否走 release pipeline：CycloneDX / SPDX 格式是否定期匯出、是否進 supply chain integrity 流程、合規要求（EO 14028 / NIS2）是否覆蓋

四件事任一缺失、就是 Audit Log 與 supply chain 治理邊界的待補項目。

日常操作與決策形狀

Project / Target / Organization 模型：Organization 是計費跟 RBAC 邊界、對應一個團隊或一個 BU。Target 是一個 SCM 來源（一個 GitHub repo / 一個 container registry image / 一個 Terraform stack）。Project 是 Target 內的單一掃描單位（一個 manifest 或一個 image tag）。Issue 是發現的漏洞 / license / misconfig、有 severity（Critical / High / Medium / Low）、CVSS、exploit maturity、fix availability。Project 暴量的根因通常是 monorepo 內 nested manifest 全被 auto-import、用 .snyk 或 import filter 排除。

五大模組分工：Snyk Open Source（SCA）掃 package manifest（npm、pip、Maven、Go modules、Composer、NuGet 等 20+ 生態）對 Snyk Vulnerability DB（自家維護、補強 NVD 延遲）。Snyk Code（SAST）掃源碼、symbolic execution + ML、覆蓋 OWASP Top 10 跟 CWE。Snyk Container 掃 image base layer + installed package、支援 Docker / OCI / ECR / GCR / Harbor。Snyk IaC 掃 Terraform / CloudFormation / K8s YAML / Helm chart 對 CIS Benchmark + custom policy。Snyk Cloud（2023 收購 Fugue 後加入）是 CSPM、scan AWS / Azure / GCP runtime 配置 + IaC drift detection（cloud 實際狀態 vs Terraform 狀態的差異）。

Snyk Code (SAST) vs GHAS CodeQL：Snyk Code 走 快速 inline scan（秒級回饋、走 cloud inference）、適合 dev loop；CodeQL 走 深度 dataflow query（分鐘級、執行更慢但表達力更強）、適合 release gate。同時用兩者並不矛盾 — Snyk Code 在 IDE / PR 給快速訊號、CodeQL 在 release 前跑深度檢查。

Reachability analysis：跟 純 dependency list 比對 CVE 不同、Snyk 結合 Snyk Code (SAST) 跟 Snyk Open Source (SCA)、做 call graph 分析、判斷「我的 code 是否真的呼叫到 vulnerable 函式」。實務影響：多數 transitive dependency 的 CVE 在你的 app 內 不 reachable（你引入的 lib 沒呼叫到那條 path）— Reachability 過濾後、可以從 幾百個 Critical / High 降到 幾個真的 exploitable。限制：只支援部分語言（Java / JS / Python / Go 較完整）、且 dynamic dispatch / reflection / runtime plugin load 會被當成 reachable（false positive）或 unreachable（false negative）— 不可全信、是 prioritization signal 不是 binary verdict。

Fix advice / Auto PR：發現 vuln 後、Snyk 自動發 PR 升級到 最小 fix version（包含 transitive dep 的 root cause upgrade）。跟 Dependabot 功能重疊、差異是 Snyk 跨 SCM（不只 GitHub）、且 fix advice 含 Reachability 標註（reachable vuln 的 PR 優先級高）。重複用兩者要關掉其一、否則 PR 量翻倍。

跟 CI 整合：snyk CLI（snyk test / snyk monitor / snyk container test / snyk iac test）走 SNYK_TOKEN 環境變數、可在任何 CI 跑。官方 Snyk Action（GitHub Actions）跟 Jenkins / GitLab CI / CircleCI plugin 是 wrapper。release gate 推薦在 build 後跑 snyk test --severity-threshold=high --fail-on=upgradable、只擋 可升級 的 high+ vuln（無 fix 的 vuln 阻塞 release 沒意義、走 .snyk policy 暫時 ignore + alert）。

SBOM export：snyk sbom --format=cyclonedx1.4+json / --format=spdx2.3+json 產 SBOM、支援 Snyk attestation（signed SBOM）。近年 supply chain compliance（US EO 14028、EU NIS2 / CRA）要求 SBOM、Snyk 是自動產線之一。SBOM 應該在 release artifact 旁 一起發布、走 supply chain integrity 流程。

License compliance：除了漏洞、Snyk 也掃 dependency license（GPL / AGPL / LGPL / proprietary / unknown）、可設 license policy（allow / disallow / require-review）、PR 引入違規 license 直接 fail check。對需要避開 copyleft license 的商業產品、license scan 跟 vulnerability scan 一樣關鍵。

API token 治理：CI / 第三方 integration 用 Service Account + scoped token（限 Organization、限 permission）、不要用個人 personal token（離職就失效）。Token 進 HashiCorp Vault / AWS Secrets Manager / Google Secret Manager、定期 rotate。

核心取捨表

選 Snyk 的核心訴求：組織用多個 SCM 或多技術棧（後端 + 前端 + container + Terraform + cloud） + 需要 統一 dashboard + 跨團隊 prioritization + 接受按 Project 計費的成本。純 GitHub 組織用 GHAS 更整合、純 container CI 用 Trivy 免費、極大型 monorepo 用 Snyk 容易爆 Project 數要小心。

進階主題

Snyk Cloud (CSPM) 跟 IaC drift detection：Snyk Cloud 連 AWS / Azure / GCP read-only role、掃 runtime 配置（S3 bucket public、IAM over-permission、security group 0.0.0.0/0）對 CIS Benchmark + custom policy。跟 Snyk IaC 結合做 drift detection — Terraform 內定義是 private bucket、但 cloud 實際是 public（有人 console 手改）、Snyk 報 drift。對標 Wiz / Prisma Cloud / Lacework、Snyk Cloud 是 跟 Snyk IaC 同源治理 的優勢（同個 dashboard 看 IaC + runtime）。

Custom Rule（Snyk IaC custom policy）：Snyk IaC 預設規則庫覆蓋 CIS Benchmark + AWS / GCP / Azure 最佳實踐、可寫 custom policy（Rego-like / SnykIQL）擴展。例：禁止 RDS 沒開 encryption-at-rest、禁止 S3 沒 versioning、禁止 K8s pod 跑 hostNetwork。Custom policy 走版控（git）跟 PR review、避免在 console 直接改。

Reachability vs 純 static SCA：純 SCA（如 Dependabot / Trivy）只看 manifest 中聲明的版本是否有 CVE、不分 reachable / unreachable。結果是 Critical / High alert 大量、開發者 alert fatigue 後直接 ignore。Snyk Reachability 用 SAST + SCA 整合做 call graph、過濾掉 vulnerable lib 載入了但 vulnerable 函式從未被呼叫 的案例。限制：dynamic dispatch / reflection / 動態載入 plugin / native binding 都會讓 reachability 判斷失準、不可當成 binary truth。

Snyk Insights（風險優先級 prioritization）：除了 CVSS、Snyk 加入 exploit maturity（exploit in-the-wild / PoC / no known exploit）、fix availability（有無 fix version）、social trend（CVE 被討論度）、Reachability 綜合算 Priority Score。production 用 Priority Score 排 backlog、而非單純 CVSS — 一個 Critical 但 unreachable + no fix 的 vuln 不該擋 release。

SBOM 流程整合：把 snyk sbom 接到 CI release step、SBOM artifact 跟 release binary 一起進 registry / object store、走 in-toto attestation 或 SLSA provenance 流程、合規時可回溯。跟 Syft + Grype 流程的差異：Syft + Grype 是 OSS local-first + Unix philosophy、Snyk 是 SaaS、SBOM 含 Snyk Issue ID 跟 fix advice link。

License policy enforcement：除了 vulnerability、license 違規（GPL / AGPL 引入到 proprietary product、unknown license dep）走同套 policy / PR fail-check 機制、production 應該把 license policy 跟 vulnerability policy 並列當 release gate。

排錯與失敗快速判讀

• Project 暴量計費：monorepo 自動 import 把 test fixture / node_modules-vendored 全當 Project — 用 .snyk 跟 import filter 排除、archived project 確認真的不計費
• Reachability 漏判 / 誤判：dynamic dispatch / reflection / plugin load 讓 call graph 失準、Critical vuln 被標 unreachable 但實際 reachable — 對 framework-heavy code（Spring / Django middleware / Rails initializer）保守處理、不全信 Reachability
• PR noise：Snyk + Dependabot 同時開、依賴升級 PR 翻倍 — 二選一、或讓 Snyk 處理 vuln-driven upgrade、Dependabot 處理 routine version bump
• CI fail-on 設不對：--severity-threshold=low 把 release 整個擋死 / --severity-threshold=critical 漏 high — production 通常 --severity-threshold=high --fail-on=upgradable、再用 .snyk policy file 例外管理
• License check 誤殺：transitive dep 引入 LGPL 被當 GPL 阻擋 — 細分 license policy（allow LGPL-with-dynamic-linking、disallow GPL）、走 review workflow 而非 fail-fast
• API token over-scoped：CI 拿到 admin-level Service Account token、整 org Project 都能改 — 改 scoped token、限 Organization + 限 permission、進 Vault
• SBOM 沒進 release pipeline：SBOM 只在 Snyk dashboard、release artifact 沒附 — 把 snyk sbom 加進 CI release step、SBOM 跟 binary 一起發
• Snyk Cloud drift 沒人看：CSPM alert 進 dashboard 但沒 routing 到 on-call — 接 SIEM / Slack / PagerDuty、高 severity drift 觸發 ticket

何時改走其他服務

不在本頁內的主題

• Snyk 完整 pricing tier（Team / Business / Enterprise）跟 Project 計費細節
• Snyk Vulnerability DB 跟 NVD / GHSA 的覆蓋差異對照
• Snyk Code SAST 規則完整 reference
• Snyk IaC 內建 policy 完整列表 + CIS Benchmark 對照
• Snyk Cloud 多雲 onboarding 步驟（AWS / Azure / GCP read-only role 設置）

案例回寫

Snyk 在 07 案例庫沒有直接 vendor-level 事件、但多個 supply chain 案例展示 Snyk 工具能力的 範圍跟邊界：

下一步路由

• 上游：7.12 供應鏈完整性與 Artifact 信任
• 平行：GitHub Advanced Security、Trivy、Dependabot
• 下游：7.4 資料保護與遮罩治理（vuln 阻擋不完全時、資料層也要遮罩）
• 跨類：HashiCorp Vault、AWS Secrets Manager（Snyk API token 存放）
• 跨模組：8 事故處理 vendor 清單（Critical CVE 揭露時的 emergency triage routing）
• 官方：Snyk Documentation

服務定位

Dependabot 的核心定位是 把依賴升級從人工 ritual 變成 PR review 工作流。它把「找新版」「跑 manifest update」「開 PR」「附 release note」自動化、剩下的 是否合併 留給人類 / CI 判斷。這跟 Snyk 看似重疊 — 兩者都會自動發升級 PR — 但 Snyk 是 跨 SCM + 多 stack（GitHub / GitLab / Bitbucket、SCA + 容器 + IaC + Code）、Dependabot 是 GitHub-only + 純依賴。多數組織選一個、混用兩者會在同一個 manifest 上各自開 PR、造成 noise。

跟 GHAS 的關係比較細：Dependabot Alerts 跟 Security Updates 本身是 GHAS Dependabot 子模組的核心、但功能上 Alerts 對所有 repo 免費、Security Update 也免費自動發 PR、Version Update 也免費；GHAS 提供的是 Dependency Review（PR-time gate、阻擋 PR 引入新漏洞依賴）、Security Overview（org-wide dashboard）跟 enterprise-level 控制。Dependabot 是 background PR 工廠、GHAS Dependency Review 是 PR-time blocker、兩者互補不重疊。

跟 Renovate（Mend 維護的 OSS）的差異：Renovate 配置更彈性、跨 SCM、支援 ecosystem 數量多（含 Helm chart、Docker tag、ArgoCD 等）、Grouped Updates 規則更細；Dependabot 整合 GitHub 原生 UI（Security tab、Dependency graph、PR diff）更深、設定簡單。需要 跨 SCM 或 Helm / ArgoCD / 自訂 ecosystem 走 Renovate；單純 GitHub-only 加 npm / Maven / pip 等主流 ecosystem、Dependabot 配置成本更低。

本章目標

讀完本頁、讀者能判斷：

1. Dependabot 在 supply chain 防護裡承擔哪一段（背景 PR 升級）、哪些不在它責任內（容器掃描、IaC 掃描、PR-time gate）
2. dependabot.yml 的關鍵配置面：ecosystem、schedule、open-pull-requests-limit、groups、reviewers
3. Version Update vs Security Update vs Alerts 三個功能何時開、PR noise 怎麼控制
4. Auto-merge 政策的邊界：哪種更新可以全自動、哪種要保留 human approval

最短判讀路徑

判斷一個 repo 的 Dependabot 配置是否健康、最少看四件事：

• dependabot.yml 配置：repo 是否有 .github/dependabot.yml、ecosystem 是否覆蓋所有 manifest（npm / Maven / pip / Docker / GitHub Actions / Terraform）、directory 路徑對不對（monorepo 各 sub-package 是否獨立配置）
• Update Schedule：schedule.interval 是 daily / weekly / monthly、open-pull-requests-limit 是否合理（預設 5、太低會卡住 backlog、太高會 PR noise）、Grouped Updates 是否啟用（減少 minor / patch PR 數量）
• Auto-merge 政策：branch protection 是否設「CI green + required reviewer」、auto-merge 是否限定 patch + minor 自動、major 強制 human review、production 跟 staging branch 是否有差異化規則
• Token 治理：repo secrets 是否被 Dependabot PR 誤用、Dependabot secrets（私有 registry credential）是否獨立配置、PR 觸發的 Actions 是否假設 read-only token

四件事任一缺失、就是 Supply Chain Integrity 邊界的待補項目。

日常操作與決策形狀

dependabot.yml 是版控的配置檔：放在 .github/dependabot.yml、跟 manifest 同 repo、所有變更走 PR review。不在 GitHub UI 直接改 — UI 只能 啟用 / 停用 Dependabot 本身、細節必須 commit 進 repo。Monorepo 結構（例：/services/api、/services/web 各自 package.json）每個 sub-package 寫一個 entry、directory 指到 sub-package 根目錄、package-ecosystem 標 manifest 類型。schedule.interval 一般 weekly 開始、daily 適合高活躍度團隊但 PR noise 高、monthly 適合穩定 lib 但 CVE 延遲風險高。

Version Update vs Security Update 分開：Version Update 是 定期掃 manifest 看有沒有 newer compatible 版本、不分 CVE、是 hygiene 工作；Security Update 是 Dependabot 偵測到 CVE 且 manifest 指到 vulnerable 範圍時自動發 PR 升級到 fix version、是 incident 工作。多數組織開 Security Update 全 repo + 選擇性開 Version Update（核心服務開、archived repo 不開）— 避免 PR noise 淹沒緊急 PR。Security Update 預設啟用、Version Update 要 explicit 在 dependabot.yml 寫 entry 才會跑。

Grouped Updates：2023 推出、單一 PR 含多個 minor / patch 升級（例：一個 PR 升 10 個 npm package）、PR 數量從 10 個降到 1 個。配置在 dependabot.yml 的 groups 區、可以按 dependency name pattern（例：@types/* 一組、eslint* 一組）或 update-type（patch / minor 分組）。Major version 仍分開 PR — 因 breaking change 風險、需要單獨 review。Grouped Updates 配 auto-merge 是 minor / patch 全自動 的標準配置。

Auto-merge 是 PR 級、不是 commit 級：Dependabot 發 PR、搭配 GitHub branch protection 設「CI green + 1 approver」就 auto-merge — GitHub gh pr merge --auto 或 Actions workflow（peter-evans/enable-pull-request-automerge）都行。production 環境應該保留 human approval（至少對 major version）、staging / dev 可以全自動。常見模式：staging branch 全自動合（patch + minor）+ 自動 deploy；production branch 走 staging → cherry-pick / promote 流程、human approve。

Reviewer / Assignee / Label 自動標記：dependabot.yml 的 reviewers / assignees / labels 欄位讓 Dependabot 開 PR 時自動標 reviewer 跟 label。實務上配 labels: ["dependencies"] 讓 Dependabot PR 在 PR list 跟一般 feature PR 分開、CI workflow 可以針對 dependencies label 跑特化 lint（例：跑完整 e2e、不只 unit test）。

Token 治理：Dependabot PR 跑 GitHub Actions 時、secrets.GITHUB_TOKEN 是 read-only（GitHub 設計上限制、防 PR 觸發 supply chain attack）— 這代表 Dependabot PR 不能跑需要 write permission 的 job（推 image / 改 status / comment）。需要的話用 pull_request_target event（用 base branch 的 workflow + 完整 secrets）、但這也是 supply chain attack 高風險面、必須 最少 permission。私有 registry credential（npm private registry token、Maven private repo password）用 Dependabot secrets（org / repo level）配置、跟 GitHub Actions secrets 是 不同 namespace、不會互相讀到。

跟 GHAS Dependency Review 搭配：GHAS Dependency Review 在 PR-time 看 manifest diff 阻擋 引入新漏洞依賴、Dependabot Security Update 在 background 升級舊有漏洞依賴、兩個方向互補。production repo 標準配置：GHAS Dependency Review 設 high severity block + Dependabot Security Update 全開 + Dependabot Version Update 選擇性開。

核心取捨表

選 Dependabot 的核心訴求：GitHub-only + 只要依賴 PR 自動化、不要容器 / IaC scan、配置成本要低、整合 GitHub Security tab。要跨 SCM 或多 stack 走 Snyk、要彈性 ecosystem / Helm chart / ArgoCD 走 Renovate。混用 Dependabot + Snyk 對同一 manifest 自動 PR 會 noise、二選一。

進階主題

Multi-ecosystem repo：一個 repo 同時有 npm + Docker + Terraform + GitHub Actions、dependabot.yml 寫四個 entry、各自 schedule。實務常見配置：application 依賴（npm / pip）weekly、base image（Docker）weekly、IaC（Terraform provider）monthly、GitHub Actions（CI workflow）weekly。Actions ecosystem 要特別注意 — Dependabot 升級 uses: 指向的 action version、可以同時 pin commit hash（防 tag re-publish 攻擊）、但 pin hash 後 release note 看不到 — 取捨 安全 vs 可讀性。

Private registry support：私有 npm registry（GitHub Packages / Artifactory / Nexus）、私有 Maven repo、私有 PyPI mirror、私有 container registry 都要在 dependabot.yml 配置 registries 區、credential 走 Dependabot secrets。Dependabot 從私有 registry 抓 package metadata 跟 release info、否則只能看 public registry、會誤判 internal lib 沒新版。Org-level Dependabot secrets 適合共用 credential、repo-level 適合特殊 credential 隔離。

Self-hosted runner 隔離：Dependabot PR 觸發的 Actions 預設跑在 GitHub-hosted runner、跟 Dependabot 本身的 sandbox 不同。如果 CI 跑在 self-hosted runner（內網資源 / 大 build cache）、Dependabot PR 也會跑在 self-hosted runner — 要確認 runner 不會被 PR 注入的惡意 manifest 攻擊（npm install 跑 postinstall script 是經典攻擊路徑）。Mitigation：Dependabot PR 用 ephemeral runner（每次新 VM）、隔離 build cache、不掛 sensitive volume。

Auto-merge 風險：auto-merge 加速合併、但也放寬 攻擊者升級 dep 攻擊我 的窗口。XZ Backdoor 2024 的攻擊路徑就是攻擊者花兩年取得 upstream maintainer 信任、發 release 帶 backdoor — 如果下游 auto-merge 升級、攻擊就直達 production。Mitigation：major version 永不 auto-merge、critical infra dep（auth / crypto / network 函式庫）pin commit hash + 手動 review、auto-merge 範圍縮到 patch + minor + low-criticality dep。

GitHub Actions 跟 Dependabot 互動：Dependabot PR 觸發的 workflow 預設 GITHUB_TOKEN 是 read-only、secrets.* 是 empty（Dependabot context）— 防止 PR 注入腳本竊取 secret。需要在 Dependabot PR 跑帶 secret 的 job、用 pull_request_target event（workflow 從 base branch 取、有完整 secret）— 但這會 讀 PR 的 code 跑 workflow、必須先 checkout base 然後最小化 PR code 的執行（不跑 PR 的 install script、只跑既有 lint）。

排錯與失敗快速判讀

• PR noise 淹沒緊急 PR：Version Update 全開 + 沒 Grouped Updates、一週 30+ PR — 啟用 groups 按 pattern 分組（@types/* / eslint* / dev-dependencies）、open-pull-requests-limit 設 5、archived repo 關 Version Update
• Security Update 沒發 PR：CVE 公告了但 Dependabot 沒動 — 確認 manifest 真的指到 vulnerable 範圍、dependabot.yml 沒 ignore 該 dependency、Security Updates 在 repo settings 是啟用、Dependency graph 有抓到該 manifest
• 私有 registry 抓不到：Dependabot 在私有 npm / Maven repo 失敗 — dependabot.yml 配 registries 區、credential 進 Dependabot secrets（不是 Actions secrets）、URL 跟 token 範圍對齊
• Auto-merge 不觸發：PR 開了 CI 也綠了但沒合 — 確認 branch protection required check 跟 CI workflow 名稱對齊、gh pr merge --auto 在 PR comment / workflow 有觸發、reviewer count 達標
• Dependabot PR 跑 Actions 失敗：PR 的 workflow 報 permission denied — GITHUB_TOKEN 在 Dependabot context read-only、改用 pull_request_target 或拆 job（push secret 的部分跑在 merge 後 main branch event）
• Major version 被 auto-merge：規則沒寫對、major 也自動合進 production — dependabot.yml 的 ignore 加 update-types: ["version-update:semver-major"] 或 auto-merge 條件改 ${{ steps.metadata.outputs.update-type == 'version-update:semver-minor' }}
• Monorepo 漏掃：/services/api/package.json 沒掃 — dependabot.yml 每個 sub-package 寫一個 entry、directory 指到正確路徑、不是只在 root 一個 entry
• GitHub Actions ecosystem 升級拿掉 commit hash pin：原本 uses: actions/checkout@a12b3c4 被升成 uses: actions/checkout@v5 — Dependabot 會 follow 既有 reference 風格、想要 hash pin 設 dependabot.yml 的 ecosystem-level config 但目前限制較多、實務常另用 pinact 或 Renovate 處理 Actions hash pinning

何時改走其他服務

不在本頁內的主題

• dependabot.yml 完整欄位 reference（看 GitHub 官方文件）
• GitHub Advisory Database 詳細運作（CVE 來源、curation 流程）
• GHAS 其他模組（Code Scanning / Secret Scanning / Dependency Review）細節 — 看 GHAS 頁
• Renovate / Snyk 完整配置 — 看各自 vendor 頁
• Container base image 升級的 multi-stage Dockerfile 處理

案例回寫

Dependabot 沒有自身 vendor-level case、但在 supply chain case 中是 標準 mitigation 或 風險面：

下一步路由

• 上游：7.12 供應鏈完整性與 Artifact 信任
• 平行：GitHub Advanced Security、Snyk
• 下游：Trivy（容器 scan）、Syft / Grype（SBOM）
• 跨類：artifact 簽章（Sigstore cosign）見 Syft / Grype 頁的 SBOM attestation 段
• 跨模組：6 可靠性驗證流程（Dependabot PR 進 release flow 的 gate 設計）、8 事故處理 vendor 清單
• 官方：Dependabot Documentation

本模組的 framing 是個人 dev 視角、不是 enterprise 資安管理視角。production LLM 服務化的特殊資安議題（多租戶 isolation、deployment 供應鏈、agent 場景 prompt injection 後果、log/PII 治理、偵測訊號）見 Backend 模組七 資安與資料保護 的 LLM 相關章節。

本模組的責任範圍

跟 Backend 模組七 資安與資料保護 的分工：本模組的 6.1 ~ 6.4 是「個人 dev 場景下的安全議題」、用到的通用資安詞彙（identity / boundary / supply chain / transport trust 等）cross-link 回 backend/07 的既有卡片、不在本模組重新定義。

章節列表

跟其他模組的關係

為什麼這個順序

本模組章節順序的設計脈絡：

1. 先 6.0 模型供應鏈：模型權重是本地 LLM 的最上游、信任邊界從這裡開始；裝錯模型其他防護都沒意義。
2. 再 6.1 推論伺服器綁定：模型載入後、伺服器是第一個對外的接觸面；綁定錯誤是個人 dev 場景最常見的暴露點。
3. 接 6.2 tool use 權限：伺服器跑起來後、最大的副作用來自 tool use / MCP 對本機資源的存取。
4. 再 6.3 prompt injection：tool use 跟 RAG 把外部內容引入 prompt、prompt injection 才有著力點。
5. 然後 6.4 跨雲端 / 本地邊界：寫 code 場景常混用雲端 LLM、prompt 的洩漏軌跡要說清楚。
6. 最後 6.5 跨進 production：個人 dev 工作流穩了之後、若要分享給團隊或部署成服務、需要的 routing。

個人 dev 視角的 threat model 預設

本模組假設的 threat model：

1. 攻擊者預期：「不小心被執行的 malicious payload」（誤裝有問題的 GGUF、誤裝有問題的 MCP server、誤點到帶 prompt injection 的網頁 / 文件 / pull request），而非 nation-state APT。
2. 保護的 asset：本機檔案、開發中的 codebase（含未公開）、雲端 API key（OpenAI、Anthropic 等）、SSH key 與其他憑證。
3. trust boundary：本機 user account 邊界、prompt 邊界、tool 副作用邊界。
4. 可接受風險：個人 dev 不需要 enterprise-grade audit log、IDS / IPS、SOC、紅藍隊演練；用基本權限隔離 + 預設安全配置 + 場景判讀為主。

production / 多人協作場景的 threat model 完全不同、見 Backend 模組七。

不在本模組內的主題

本模組不討論：

1. enterprise IAM、SSO、SAML / OIDC：個人 dev 場景用不到、屬 backend/07 identity-access-boundary。
2. 合規認證（SOC 2、ISO 27001、HIPAA、GDPR 流程）：個人 dev 場景的隱私判讀見 6.4、企業合規流程屬 backend/07。
3. detection / SIEM / SOAR：個人 dev 場景靠 OS 既有 log 跟手動觀察、企業偵測屬 backend/07 detection-coverage-and-signal-governance。
4. incident response 標準流程：個人 dev 場景靠快速止血 + 重置、企業 IR 流程屬 backend/07 incident-case-to-control-workflow。
5. 模型本身的對抗性訓練 / 後門：屬研究範疇、本模組假設用主流模型作者發布的權重作為可信起點。

服務定位

Syft + Grype 的核心定位是 SBOM-first 的 OSS supply chain scan tool chain。SBOM 不是中間產物、是 正式可簽章 artifact：Syft 產 SBOM 後通常用 Sigstore cosign attest --predicate sbom.cdx.json 把 SBOM 簽進 image OCI metadata、跟 image 一起發布；下游團隊 / 客戶 / scan pipeline 拿 trusted SBOM 跑 Grype、不需要重新 scan image。對 air-gapped 環境、multi-team handoff、合規場景（EO 14028 / FedRAMP 要求交付 CycloneDX 或 SPDX）特別合適。

跟 Trivy 的差異是 分工 vs 全包：Trivy 一個 binary 把 SBOM 生成 + vuln scan + IaC + secret + license 都做了；Syft + Grype 拆兩個工具、SBOM 互通流程適合、團隊偏好 Unix philosophy 選這條。功能覆蓋面 Trivy 略廣（含 IaC / secret scan）、Syft 的 SBOM 格式互通性是 OSS reference implementation。跟 Snyk 的差異更直接：Snyk 商業 SaaS、覆蓋廣（SAST / IaC / CSPM / Reachability）、有 dashboard 跟 fix PR；Syft + Grype 純 CLI、OSS 免費、聚焦 SBOM + vuln 兩件事、沒 server / 沒 dashboard、要 dashboard 走商業 Anchore Enterprise 或自接 JSON 到 Elasticsearch / Grafana。

關鍵 first-class concept：Source（OCI image / OCI archive / Docker daemon / dir / file / 既有 SBOM）、Catalog（Syft 內部 package inventory 結構）、Package、Vulnerability、Match（Grype 的 package ↔ CVE 配對）、Match Configuration（grype.yaml 設 severity gate / 比對策略）、Vulnerability DB（Grype-DB、Anchore 聚合 NVD + GHSA + 各 distro secdb）、Ignore Rule（CVE 例外、強制帶 expiration）。

本章目標

讀完本頁、讀者能判斷：

1. Syft 跟 Grype 各自的責任邊界、為什麼拆兩個工具比合一個工具好（SBOM 互通、attestation、air-gapped）
2. SBOM 格式（CycloneDX / SPDX / SyftJSON）的選擇、跟合規要求對應
3. Grype Match Configuration 跟 Ignore Rule 怎麼設、CI fail 條件怎麼定
4. 何時改走 Trivy 全包式、何時走 Snyk 商業 SaaS

最短判讀路徑

判斷 Syft + Grype 配置是否健康、最少看四件事：

• SBOM 格式跟保存：產出格式是否符合合規（多數 EO 14028 / FedRAMP 場景要 CycloneDX 或 SPDX、不是 SyftJSON）、SBOM 是否簽章（cosign attest）、是否集中保存（OCI registry 旁邊 / artifact store）、是否有 baseline diff（image 升級前後依賴變化）
• Grype DB 更新：DB 是否每日同步、air-gapped 場景是否 mirror 到內部 registry（Grype DB 是 OCI artifact、可 oras pull 鏡像）、DB version 是否進 SBOM scan record（重現性）
• Match Configuration：grype.yaml 的 severity gate（CI fail 條件、通常 high / critical fail）、only-fixed: true 是否開（只報有 patch 的 CVE）、add-cpes-if-none: true 對 binary-only package 行為
• Ignore Rule 治理：例外清單是否帶 expiration、reason 欄位是否填 ticket / decision 連結、quarterly review 機制、過期自動回到 fail 狀態

四件事任一缺失、就是 Supply Chain Integrity 邊界的待補項目。

日常操作與決策形狀

Syft 用法跟 Source 種類：syft <source> -o <format> 是核心 — source 可以是 OCI image（registry/image:tag）、OCI archive（oci-archive:image.tar）、Docker daemon（docker:image:tag）、目錄（dir:./）、單一檔案、甚至既有 SBOM（sbom:./prev.cdx.json、用來 轉格式）。format 包括 cyclonedx-json / cyclonedx-xml / spdx-json / spdx-tag-value / syft-json / table。production 通常產 cyclonedx-json（合規要求最常見）+ 保留 syft-json（Syft 自家最完整、未來 round-trip 用）。

Package detector 廣度：Syft 自動偵測 OS package（apk / dpkg / rpm）+ 語言 dependency（npm / pip / gem / go module / cargo / maven / gradle / nuget / composer / hex / conan / swift / dart 等）+ binary analysis（Go binary 內 embedded module、Rust binary metadata、Java jar / war / ear nested）。對 static binary / FAT image 的支援是 Syft 的強項、比多數 SBOM tool 廣。但 runtime-only dependency（dlopen / dynamic load）SBOM 看不到、要靠 runtime workload protection（Falco / Cilium Tetragon 類工具、見 7 後續候選 vendor 清單）補。

Grype 用法：grype <source> 或 grype sbom:./image.cdx.json。輸出 table / json / cyclonedx-json（CycloneDX VEX 格式）/ sarif（GitHub code scanning）/ template（Go template 自訂）。production CI 通常 --output sarif 上傳 GitHub code scanning + --output json 進內部 SIEM。grype sbom:./prev.cdx.json 模式是 SBOM-only scan、不碰 image — 適合 下游團隊拿 SBOM 持續 monitor、原始 image 已經 frozen 或不可達。

Match Configuration（grype.yaml）：核心欄位包括 fail-on-severity: high（CI gate）、only-fixed: true（只回報有 fix 可用的 CVE、避免 noise）、ignore list（個別 CVE 例外）、match strategy（如何把 package CPE / PURL 對應到 CVE、預設策略對 90% 場景夠用、特殊 binary 場景才調）。所有設定走版控、grype.yaml 跟程式碼一起 review、避免 console 改。

Ignore Rule 治理：grype.yaml 的 ignore entry 結構：vulnerability + reason + expiration（YYYY-MM-DD）+ optional package.name / fix-state。Anchore 設計 沒有「永久 ignore」、必須帶 expiration — 強制 quarterly review、避免「五年前 ignore 的 CVE 早被 fix 了還在清單裡」。reason 欄位填 ticket 編號或 ADR link、給未來的人 context。

Cosign attest SBOM：syft image:tag -o cyclonedx-json > sbom.cdx.json && cosign attest --predicate sbom.cdx.json --type cyclonedx --key cosign.key image:tag — SBOM 被簽進 image 的 OCI signature manifest、下游 cosign verify-attestation --type cyclonedx ... 拿到 cryptographically signed SBOM。這把 SBOM 從「可被竄改的 JSON 檔」升級到 trusted artifact、是 SLSA L3+ provenance 的基礎。

SLSA / SPDX 流程整合：Syft SBOM 是 build 階段產物、跟 SLSA provenance（誰 build 的、用什麼 builder、source commit 是什麼）併存、不互斥 — SBOM 答「裡面有什麼」、provenance 答「怎麼 build 的」。完整 supply chain trust 需要兩者 + cosign signature。

核心取捨表

選 Syft + Grype 的核心訴求：要正式 SBOM 作為交付 artifact（合規 / 多 team handoff）+ 偏好 OSS Unix philosophy（兩個工具各做一件事、容易整合自家 pipeline）+ 不需要 SaaS dashboard（自家 SIEM / Grafana 已經有）。需要 IaC scan 一起做、看一下 Trivy 是不是更省整合成本；需要 fix workflow 跟 reachability、商業預算足、走 Snyk。

進階主題

SBOM attestation 完整鏈：build pipeline 順序通常是 — build image → syft image -o cyclonedx-json > sbom.cdx.json → cosign sign image → cosign attest --predicate sbom.cdx.json --type cyclonedx image → push。下游 admission controller（Kyverno / Gatekeeper / Sigstore policy-controller）verify-attestation 拿 trusted SBOM、再 Grype scan、policy 決定是否允許 deploy。這條鏈把 SBOM 從 文件 升級成 deploy gate。

Grype DB air-gapped sync：Grype DB 是 OCI artifact（ghcr.io/anchore/grype/listing.json + db.tar.gz）、oras pull 或 grype db update 取得。air-gapped 場景：DMZ 跑 grype db update --skip-listing-content-check、把 ~/.cache/grype/db/ 整個 sync 到內部 mirror registry、內部 grype 透過 GRYPE_DB_UPDATE_URL 指到內部 listing。DB 版本進 scan record、確保 相同 SBOM + 相同 DB = 相同結果（可重現）。

Custom matcher / Ignore Rule 細部：Grype 預設 matcher 對 90% 場景夠、但 Go binary、static-linked binary、custom C++ build 可能需要 add-cpes-if-none: true 強制配對 CPE。Ignore Rule 支援 vex-status 欄位（accepted / under-investigation / fixed / not-affected）對齊 CycloneDX VEX 標準、輸出 VEX-enriched SBOM 給下游 / 客戶。

Anchore Enterprise 商業整合：OSS Syft + Grype 不夠時、Anchore Enterprise 加：policy engine（GraphQL 寫複雜 policy）、dashboard、RBAC、SLA-backed support、跟 Kubernetes admission integration、跟 Jira / ServiceNow ticket 自動建單。OSS 是 90% 場景的起點、Enterprise 解的是 policy + workflow 而非 scan ability。

SBOM diff（baseline 比對）：syft 自己沒內建 diff、但 cyclonedx-cli diff 或自家 script 可以比對 image v1 SBOM vs image v2 SBOM、找出新增 / 移除 / 升級的 package。用途：XZ backdoor 之類「相同 version 但被植入後門」事件、單靠 SBOM 看不出來、但 baseline + behavior anomaly 雙軌可以提早警示。

排錯與失敗快速判讀

• Syft scan 找不到 package：image 是 FROM scratch 或 distroless、Syft 偵測不到 OS package metadata — 改 scan source 為 build 階段的 dir:./ 或保留 builder image 的 SBOM
• Grype 報一堆 unfixed CVE：base image 老、有 CVE 但 upstream 還沒 patch — 設 only-fixed: true 過濾 noise、focus 在 actionable item；同時排程 base image 升級
• CI 突然 fail 變多：Grype DB 更新後新 CVE 揭露 — 看 DB version diff、評估是 真新風險 還是 舊 package 被重新分類、必要時用 Ignore Rule + expiration 過渡
• SBOM 格式下游不認：合規要求 SPDX、產的是 SyftJSON — 用 syft convert syft-json:./sbom.json -o spdx-json 轉格式（Syft 本身就是 SBOM 互轉工具）
• Air-gapped 環境 Grype 跑不動：DB 沒同步、scan 直接報 0 vulnerability（假陰性）— grype db status 看 DB age、mirror sync 機制檢查、加 staleness alarm
• Ignore Rule 過期回到 fail：CI 突然 fail、查 expiration 已過 — 預期行為、強制 quarterly review；補 rotation 機制（cronjob 提前一週 alert owner）
• Binary 偵測不到 module：Go binary stripped、-trimpath 後 module path 沒了 — build 改加 -buildvcs=true 保留 VCS info、或 build 階段 SBOM scan source code、不是 binary
• cosign verify-attestation 失敗：image 被 re-tag / re-push 後 attestation manifest 不對 — 用 image digest（@sha256:...）而非 tag 做 attest、tag 不可信
• Grype 不抓某個 ecosystem：例如新冒出的 package manager — Syft 沒實作 detector、Grype 也看不到；submit issue 或自己寫 catalogger 貢獻

何時改走其他服務

不在本頁內的主題

• CycloneDX / SPDX 完整 schema 規格逐欄位解讀
• Sigstore cosign / Rekor / Fulcio 完整架構（attest 鏈的 OIDC / transparency log）
• SLSA framework 各 level 對應的 builder 要求
• Anchore Enterprise policy DSL 完整語法
• VEX（Vulnerability Exploitability eXchange）跟 CSAF 標準對照細節

案例回寫

07 案例庫沒有直接 Syft / Grype-level 事件、但供應鏈案例都是 SBOM-first 思維的對照：

下一步路由

• 上游：7.12 供應鏈完整性與 Artifact 信任
• 平行：Trivy（一站式替代）、Snyk（商業 SaaS）、GitHub Advanced Security（GitHub 內建）
• 下游：Sigstore cosign（SBOM attestation）、admission policy（Kyverno / OPA Gatekeeper、見 7 後續候選 vendor 清單）
• 跨類：runtime workload protection（Falco / Cilium Tetragon、見 7 後續候選 vendor 清單）、HashiCorp Vault（cosign signing key 保存）
• 跨模組：8 事故處理 vendor 清單（新 CVE 揭露時的 SBOM-based fan-out 查詢）
• 官方：Syft Documentation / Grype Documentation

本文是 Cloudflare WAF overview 的 implementation-layer deep article。Overview 已說明 Cloudflare WAF 在入口治理譜系的定位、本文聚焦 Page Shield 這個 client-side（browser）supply chain attack 防禦工具 — 跟 WAF 攔 server-side request 是不同層。

Attack pattern × Defense mechanism 對照

Client-side supply chain attack 不會被 WAF 看到 — 攻擊發生在 browser 渲染 page 時、不在 origin server 跟 client 之間的網路層。Page Shield 是 browser-side script execution 的監測 + 防禦層、跟 WAF 處理 server-side request inspection 互補不重疊。

三層防禦對應不同 attack 階段：

1. CSP（Content Security Policy）：browser-enforced policy、preventive、阻止違反 policy 的 script load / network request
2. SRI（Subresource Integrity）：load 階段 hash 驗證、detective + preventive、廠商 CDN 上 script 被改就 browser 拒載
3. Script monitoring：runtime 觀測、detective only、記錄頁面 load 哪些 third-party script、變動時 alert

三層各有 ceiling — CSP 擋 inline / unauthorized source 但擋不到 allowed source 被 compromise；SRI 擋已知 vendor 改 hash 但擋不到動態 loader；monitoring 看得到但攔不到。Production 三層疊用、不要單一 layer。

CSP 配置 step-by-step

從 Cloudflare dashboard 啟用 + 寫 policy

 1# Dashboard: Security → Page Shield → CSP
 2# 模式: Report-only（第一週）→ Enforced（驗證後）
 3
 4# 範例 policy
 5default-src 'self';
 6script-src 'self' 'nonce-{NONCE}' https://cdn.trusted.com https://www.googletagmanager.com;
 7style-src 'self' 'unsafe-inline' https://fonts.googleapis.com;
 8img-src 'self' data: https:;
 9connect-src 'self' https://api.myapp.com https://*.sentry.io;
10form-action 'self';
11frame-ancestors 'none';
12report-uri https://csp-report.cloudflare.com/cdn-cgi/script_monitor/report;
13report-to default;

關鍵直覺：

• 'nonce-{NONCE}'：origin server 每 request 生成 random nonce、注入 <script nonce="..."> 跟 CSP header；script tag 沒對應 nonce 就被 browser 拒跑、擋 XSS
• connect-src 精準寫：第三方 API endpoint 全列出；不寫 * 或 https: 是擋 exfiltration 的關鍵（Magecart 把信用卡送外部 endpoint 就是用 connect-src 攔）
• form-action：擋 form 被改 action attribute 送外部、formjacking 第一道防線
• report-uri + report-to：违反 policy 的 event 送 Cloudflare、Page Shield dashboard 看 violation report

Report-only mode 第一週

1Content-Security-Policy-Report-Only: <policy>
2Content-Security-Policy:             default-src 'self';   # 鬆 policy 仍 enforce

Report-only 期間 browser report 違反但不擋、production traffic 不受影響；SOC 看 report 找：

• 漏列的 legitimate third-party（marketing / analytics SDK 沒寫進 policy）
• 意外 inline script（dev 留下的 debug snippet）
• 跨 domain 的合法 connect（CRM / chat widget）

第一週後 dashboard 看 violation 數量趨穩 + 主要違規都已 whitelist、切 Enforced。

Enforced mode 切換 + canary

不要直接全站 enforced — 用 Cloudflare Page Rule 對 10% traffic enforced、90% report-only：

1URL pattern: example.com/*
2Page Rule: Add CSP header (enforced)
3Bypass: 90% by Cookie / IP hash

10% traffic 跑 24-48h、確認 zero legitimate violation、再擴大到 50% → 100%。canary 期間 monitor error-rate metric、不只是 violation report。

SRI 配置

Subresource Integrity 用 hash 驗證 CDN-hosted script 沒被改：

1<script src="https://cdn.example.com/widget.v1.2.3.js"
2        integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
3        crossorigin="anonymous"></script>

Browser load 時算 hash、跟 integrity 不符就拒跑。關鍵：

• Hash 一定要 version-pinned：用 widget.v1.2.3.js、不能用 widget.latest.js；廠商更新 latest 時 hash 變 → SRI 拒載 → 服務中斷
• 多 hash：寫 integrity="sha384-... sha512-..." 至少一個 match 就過、可在 vendor rotate hash 時平滑遷移
• crossorigin="anonymous" 必加：跨 origin script 預設 browser 不暴露 hash 失敗細節、anonymous 才允許 CORS-based hash check

Page Shield 自動產 SRI 提示

Dashboard → Page Shield → Scripts 列出所有偵測到的 script、含 建議 SRI hash；可以 export 整合進 build pipeline、自動把所有 vendor script 加 SRI。

故障演練

Case 1：CSP report flood，SOC noise

徵兆：切 Enforced 後、CSP violation report 從每天 ~500 漲到每分鐘 ~50K、Page Shield dashboard 變紅、SOC 收 alert 收到 silent。

根因：browser extension（廣告攔截 / spell checker / password manager）注入 inline script 跟 connect、被 CSP block 同時觸發 report；不是真實 attack、是 user 端 extension 行為。

修法：

1. CSP report-sample directive 限 sampling（只 report 10%）— spec 部分支援、不是所有 browser 都認
2. Page Shield 規則：filter out extension protocol（chrome-extension://、moz-extension://、safari-extension://）後再 alert
3. Report endpoint 自管 + aggregation：不直接接 SIEM、先 batch + dedupe、再送 SIEM
4. 接受 report flood 是 normal、focus 監測 unique violation pattern 不是 total volume

Case 2：Inline script 漏，舊頁面突然壞

徵兆：切 Enforced 後 X 個舊頁面壞、user feedback 提交 form 失敗、debugger 看到 console Refused to execute inline script because it violates...。

根因：legacy page 有 inline <script> 沒 nonce、CSP enforced 後 browser 拒跑；報表/管理後台/舊 admin page 常見。

修法：

1. Audit 所有 inline <script>、加 nonce attribute（server-side render 時注入）
2. 短期：對舊頁面用 unsafe-inline 寫進 CSP（接受降級）、page-specific CSP override
3. 長期：legacy page 改 build-time bundle、消除 inline script

Case 3：Dynamic script loader 繞過 SRI

徵兆：vendor script load 成功、但 Page Shield monitoring 看到該 vendor script load 後又動態 load 多個額外 script；額外 script 沒 SRI 保護、廠商側 compromise 直接過。

根因：第三方 SDK 用 document.createElement('script') + script.src = '...' runtime 動態 load；CSP script-src 可能允許這個來源、但 SRI 沒法在 runtime 注入。

修法：

1. CSP script-src 精準到 只允許特定 path、不是整個 domain（例：https://cdn.vendor.com/sdk/v3/ 而不是 https://cdn.vendor.com）
2. 評估 vendor 是否有 static-only 替代（多數 marketing / analytics SDK 不需要 dynamic loader、是 legacy 設計）
3. 不能消除 dynamic loader 時、Page Shield monitoring 設 new script alert、廠商加 sub-script 即刻通知

Case 4：SRI hash mismatch，vendor 偷偷更新

徵兆：第三方 widget 突然不顯示、Page Shield 顯示 SRI mismatch、廠商 status page 沒事故公告。

根因：廠商在 same URL（不是 versioned）下偷偷 push minor patch、hash 變了 → SRI 拒載；不是 attack、是 vendor 不遵守 immutable URL 慣例。

修法：

1. 強制要求廠商提供 versioned URL（widget.v1.2.3.js）、不收 widget.latest.js
2. 廠商不配合時、build pipeline 加 daily hash check、廠商偷改 SRI hash 自動更新 + Slack alert
3. 評估換 vendor — 不遵守 immutable URL 的廠商 supply chain integrity 信用低

容量 + cost

Page Shield 是 Enterprise plan + Page Shield add-on、cost 維度：

Page load 影響：

• CSP header ~1-2KB（policy 寫越精準越長、不是越短越好）
• SRI 比對 ~5-10ms / script、現代 browser cache decoded hash、不重複算
• Script monitoring beacon ~100 byte / script load、async 不阻塞 page render

實務 default：

• Critical e-commerce / fintech：CSP enforced + SRI 全 vendor + monitoring all、SOC review weekly
• 一般 SaaS：CSP report-only ongoing + SRI critical vendor only + monitoring 主域
• Marketing / blog：CSP default-src 'self' minimum + monitoring only

整合 / 下一步

跟 dev workflow 整合

CSP 寫進 deploy pipeline、不是 dashboard 手動配：

1. Repo 內 csp-policy.yml、跟 code 同 lifecycle
2. CI 跑 CSP linter（如 csp-evaluator）、檢查 policy 弱點
3. Deploy 時 push 到 Cloudflare API、自動 versioning + rollback

跟 WAF 互補

Page Shield 跟 Cloudflare WAF 不重疊但互補：

• WAF 攔 server-side request injection（SQL / command / path traversal）
• Page Shield 攔 client-side script execution（XSS / supply chain）
• 共同 dashboard + alert routing、不要分開 SOC team 看

跟 supply chain SBOM

Page Shield 偵測的 client-side dependency 可進 SBOM、跟 Snyk / Dependabot 的 server-side SBOM 合併、得到完整 dependency graph。

下一步議題

• Trusted Types：browser-side template injection 的下一代防禦、Chrome 已支援、Firefox / Safari 進度不一
• CSP Level 3 + strict-dynamic：減少 maintenance burden、用 nonce 動態信任 nested script
• Reporting API v1：standard report endpoint + Reporting-Endpoints header 取代 report-uri

相關連結

• 上游 vendor 頁：Cloudflare WAF
• 上游 chapter：7.3 入口治理與伺服器防護、7.12 供應鏈完整性
• 對照案例：British Airways 2018 Magecart / Macy’s 2019 skimmer（公開 supply chain 案例）
• 平行 vendor：AWS WAF / Fastly Next-Gen WAF
• 平行 deep article：Vault Dynamic Credential / Splunk RBA
• Methodology：Vendor 深度技術文章的寫作方法論

概念位置

SBOM 位在 build、scan、release 與 compliance review 之間，常見格式包含 SPDX、CycloneDX 或工具自訂輸出。

可觀察訊號

• 團隊需要知道 image 或 package 包含哪些 dependency。
• 漏洞公告需要快速判斷受影響 artifact。
• 高治理環境要求 release 產物附帶供應鏈證據。

接近真實服務的例子

Container image 發布時同時產生 SBOM，scan gate 依 SBOM 對照 CVE 與 license policy。若 base image 發現 critical vulnerability，團隊可查哪些 release digest 受影響。

設計責任

SBOM 要定義產出時機、格式、保存位置、artifact 對應關係與例外審核流程，讓供應鏈風險可以被查詢與治理。

服務定位

GitGuardian 的核心定位是 跨工具的 secret leak detection + incident workflow、不只是「pre-commit grep」。底層是一組 Detector（350+ specific detector、覆蓋 AWS / GCP / Stripe / Slack / 自家 token 等）+ Validation endpoint（call 該 service 確認 secret live 中），上層是 Incident 物件（assign / resolve / ignore / share with developer）跟 Source 抽象（GitHub / GitLab / Bitbucket / Azure DevOps / Slack / Jira / Confluence / Notion）。本機側用 ggshield CLI 做 pre-commit hook 跟 CI scan。

跟 GHAS Secret Scanning 比、GitGuardian 走 cross-tool detection + remediation workflow、GHAS 走 deep integration in GitHub：GHAS 的 push protection 在 GitHub server-side 直接攔 push、partner pattern（AWS / Stripe / Slack）廣度高；但只要組織有 GitLab self-hosted、Bitbucket、或 developer 習慣把 token 貼 Slack / Confluence，GHAS 看不到的就是 GitGuardian 的場域。跟 Gitleaks / TruffleHog OSS 比、GitGuardian 走 managed SaaS + validation + workflow、OSS 走 self-hosted + 你自己接 incident pipeline；OSS 適合預算敏感 + 已有 SOC / IR tooling、GitGuardian 適合直接買 incident workflow 不想自建。

關鍵張力：validation endpoint 是 FP 降噪核心、但也是 vendor 風險點。Detector 抓到字串後 GitGuardian call 該 service API live verify（AWS access key 試 sts:GetCallerIdentity、Stripe key 試 retrieve event）、活躍 secret 才升 Incident。意義是 noise 從 OSS gitleaks 的 70-80% FP 降到 個位數 FP；風險是 GitGuardian 本身會 call 你的 cloud account — vendor trust 跟 Failure: Credential Rotation Without Scope 的 scope map 需要在 onboarding 就釐清。

本章目標

讀完本頁、讀者能判斷：

1. GitGuardian 在 secret scanning stack 中承擔哪一段（pre-commit / SCM scan / SaaS scan / honeytoken）、哪些要外接（Vault 管 rotation、IR tool 接 incident）
2. Detector / Validation / Incident / Source 的 ownership 設計（誰 assign、誰 resolve、developer 怎麼參與）
3. 跨 SCM + SaaS coverage 該開哪些 source、historical scan 多久跑一次
4. 何時用 GitGuardian、何時走 GHAS / Gitleaks / TruffleHog 的取捨

最短判讀路徑

判斷 GitGuardian deployment 是否健康、最少看四件事：

• Source coverage 廣度：除 GitHub / GitLab 外、Slack / Jira / Confluence / Notion 是否也納入掃 — developer 把 token 貼 Slack DM 是常見 leak vector
• Validation endpoint 是否開：FP 降噪靠 live verify、未開等於回到 OSS gitleaks 的 noise 水位
• Incident remediation SLA：valid incident 從偵測到 rotation 完成的時間、是否串 Vault 自動 rotation、是否進 PagerDuty / Slack alert
• ggshield 在 CI 跟 pre-commit 的覆蓋率：是否所有 repo 走 pre-commit hook、CI step 是否阻擋 commit-with-secret merge

四件事任一缺失、就是 Secrets Management at Scale 邊界的待補項目。

日常操作與決策形狀

Detector library：350+ specific detector（AWS Access Key / Stripe Live Key / Slack Bot Token / GitHub PAT / 自家 API key pattern 等）+ generic high-entropy detector。Specific detector 走 vendor-specific pattern + validation endpoint、FP 個位數；generic detector 抓 unknown pattern、FP 較高、通常 routing 到 manual triage queue。Production tenant 應該全開 specific、generic 視 noise budget 開。

Validation endpoint：detector 抓到字串後、GitGuardian backend call 該 service API live verify。AWS key 試 sts:GetCallerIdentity、Stripe key 試 retrieve test event、GitHub PAT 試 GET /user。verify 結果 Valid / Invalid / Unknown 三態、決定 incident severity。意義是 只有 active secret 升 incident、已 revoke 的舊 commit history 不再 noise。

Incident workflow：偵測命中後會建 Incident 物件（而非直接 alert）、含 source location / detector / validation status / suggested remediation。Incident 可 assign 給 developer（developer 在 GitGuardian dashboard 自助 acknowledge / rotate / mark FP）、SecOps 只 review escalated case。對應 Security Workflow as Code 的 shift-left 模式 — developer 是 first responder、不是 SecOps 全包。

Source coverage：GitGuardian 預設掃 SCM（GitHub / GitLab / Bitbucket / Azure DevOps / 自管 Git），但 差異化價值在 SaaS scan — Slack workspace（message / DM / file upload）、Jira issue / comment、Confluence page、Notion workspace、Microsoft Teams 都可接 source connector。Developer 在 Slack 貼 prod DB password 是真實常見 case、SCM-only 工具看不到。

ggshield CLI：本地 / CI 端的 detection engine。pre-commit hook 攔住 push 前 leak（developer 機器、可被 bypass 但成本提高）、CI step 在 PR 跑 historical scan（不可 bypass、阻擋 merge）。跟 GHAS Push Protection 同類、但跨 SCM、且 detector pool 來自同一個 GitGuardian backend、跟 dashboard incident 走同一條 lineage。

Historical scan：onboarding 第一次跑 full git history scan、回填過去所有 commit 的 leak。意義是 已 leaked 多年的 secret 被找出來、強制 rotation。對應 CircleCI 2023 Secrets Rotation 的場景：CI 環境 compromise 後、historical scan 在數小時內找出 CI 環境曾接觸過的所有 secret、配合 secret store API 自動 rotation。

Honeytokens：散佈假 AWS / Stripe / GitHub token 到 repo 角落 / Confluence page / internal doc、attacker 拿到後試用會觸發 alert。是 早期偵測 unauthorized access 的工程化做法、不依賴 detection model 抓 attacker behavior、而是讓 attacker 自己 trigger 自己。對應 GitHub OAuth 2022 Token Supply Chain — attacker 拿到 OAuth token 後試 GitHub API、honeytoken 在 attacker map 環境時就 trigger。

Rotation 整合：detect 完不是工作結束、要 rotate the secret。GitGuardian 自身不存 secret，rotation 走 webhook / API 拉 Vault / AWS Secrets Manager / Azure Key Vault 觸發 rotation workflow。意義是 偵測跟 remediation 解耦、但需要組織側先把 secret store 接好、否則 incident 只能 manual rotation。

核心取捨表

選 GitGuardian 的核心訴求：跨 SCM + SaaS coverage + 內建 incident workflow + honeytoken、且能投入 per-developer 訂閱（大型公司 contributor 數會放大成本）+ 有 SecOps 跟 developer 分工承接 incident。GitHub-only 環境且已買 GHAS、重疊不必要、直接用 GHAS；預算敏感且自家有 IR pipeline、走 Gitleaks 或 TruffleHog OSS。

進階主題

Honeytokens 散佈策略：honeytoken 的效果取決於 放在哪裡 + 看起來多真。放 repo README、Confluence runbook、Slack #engineering 過期附件、舊 backup script — attacker reconnaissance 會優先看的地方。token 的命名要跟組織 naming convention 一致（prod-db-readonly-2024）、避免一看就是假的。每個 honeytoken 配 unique ID、trigger 時能定位 attacker 從哪個位置拿到、反推 leak surface。

Validation endpoint 的 trade-off：validation 是 FP 降噪核心、但代價是 GitGuardian 會 call 你的 cloud account。AWS key 命中時 GitGuardian 從自家 IP call sts:GetCallerIdentity、log 留在你的 CloudTrail。Onboarding 要 把 GitGuardian IP range allowlist 進 SIEM whitelist、避免被自家 detection 誤判為 unauthorized access；同時要評估 vendor trust — 2020 年 GitGuardian 自家 source code 透過第三方 SaaS leak、提醒 vendor 不是 detection-only 的零信任邊界。

IR workflow 整合：Incident 不應該停在 GitGuardian dashboard、要 routing 到組織既有 IR tooling — PagerDuty for on-call、Slack channel for SecOps、Jira ticket for tracking。Webhook 是標準做法、payload 含 incident metadata + validation status、由組織側決定升級邏輯（valid + prod scope → PagerDuty page；invalid + dev scope → Slack info）。

Historical scan + scope map：偵測到 leaked secret 後、要回答 這個 secret 還在哪裡用。GitGuardian 的 historical scan 找出 所有 commit 提到該 pattern 的位置、配合組織側 secret store 的 who uses this secret metadata、形成 scope map。對應 Failure: Credential Rotation Without Scope — rotation 不能只換一個地方、要全 scope 一起換、否則舊 secret 還在某個 service 用、rotation 沒生效。

排錯與失敗快速判讀

• Incident volume 爆炸 / developer 看不完：generic high-entropy detector 全開 + 沒 assign 到 developer — 縮 generic detector scope、incident 走 assign-to-author、SecOps 只 review escalated
• Valid incident rotation 慢 / SLA 跑掉：沒接 secret store rotation API、停在 manual rotation — 接 Vault / Secrets Manager webhook、自動觸發 rotation workflow
• Slack / Confluence 沒掃進來：以為 SCM-only 就夠 — 接 SaaS source connector、developer 貼 token 在 Slack DM 是常見 leak vector
• ggshield 被 bypass：pre-commit 在 developer 機器、可 --no-verify — 同步在 CI step 跑 ggshield、CI 不可 bypass、阻擋 merge
• Validation FP 不降：validation endpoint 沒開、或被 firewall 擋 — 確認 GitGuardian IP range 在 cloud account allowlist、validation status 是 Valid 不是 Unknown
• Honeytoken 沒 trigger / 假警報：token 放錯位置（attacker 不會看的 deep nested folder）或命名一看就假 — 散佈到 reconnaissance hot spot、命名跟組織 convention 一致
• Per-developer 計費暴衝：contractor / bot account 也算 developer — review billing report、排除 service account / read-only viewer、跟 vendor 談 contributor 定義

何時改走其他服務

不在本頁內的主題

• ggshield 完整 CLI flag reference 跟 custom detector YAML schema
• GitGuardian Internal Monitoring (self-hosted enterprise) 的部署架構細節
• Honeytoken 在 active deception / canary token 廣義生態的位置（屬 deception engineering、不在本頁）
• Detector pattern 的 regex / entropy 細節（屬 detection engineering）

案例回寫

GitGuardian 在 07 案例庫沒有直接 vendor-level 事件、但所有 secret leak / supply chain case 都是它的偵測對照：

下一步路由

• 上游：7.x Secrets Management at Scale、Security Workflow as Code
• 平行：GHAS Secret Scanning、Gitleaks、TruffleHog
• 下游：HashiCorp Vault（rotation 接點）、AWS Secrets Manager / Azure Key Vault
• 跨類：Splunk（Incident webhook → SIEM）、Sigstore（build provenance 覆蓋 secret scanning 抓不到的段）
• 跨模組：8 事故處理 vendor 清單（Incident → IR routing）
• 官方：GitGuardian Documentation

本章寫作邊界

本章聚焦 production LLM 服務的供應鏈完整性問題節點。個人 dev 視角的模型來源信任見 llm/6.0 模型供應鏈與信任邊界；本章不重複個人 dev 場景的判讀、聚焦 production 場景下的特殊議題（規模化下載、跨 region 鏡像、retry 策略、模型 release 流程）。

本章 threat scope

In-scope：模型權重 build provenance（HF organization / 量化者 / Ollama registry）、GGUF / safetensors artifact 完整性、production 下載與鏡像策略、第三方 MCP / plugin 的 deployment 供應鏈、模型版本回退機制。

Out-of-scope（路由到他章）：

• 一般 software artifact 信任 → 7.4 supply-chain-integrity-and-artifact-trust
• 機器憑證 → 7.6 secrets-and-machine-credential-governance
• 入口治理 → 7.3 entrypoint-and-server-protection
• 個人 dev 模型來源信任 → llm/6.0 model-supply-chain-trust
• 部署平台 → 05-deployment-platform、可靠性 → 06-reliability

從本章到實作

本章是 routing layer、沿兩條 chain 進入 implementation：

• Mechanism：問題節點表的 control link 進 knowledge-card、看具體機制與 LLM 場景的差異。
• Delivery：「交接路由」欄位指向 05-deployment-platform / 06-reliability / 08-incident-response、接配置 / 驗證 / 處置交付。

LLM 供應鏈的三條 chain

LLM 服務的供應鏈跟一般 software 服務的差異在「同時管三條 chain」：

1. 模型權重 chain：原始作者 → 官方 release → 量化者 → registry → production 鏡像
2. 推論伺服器 chain：llama.cpp / vLLM / Ollama 等 server software 的一般 software artifact chain
3. 第三方 plugin / MCP chain：MCP server / Continue.dev 等的程式碼供應鏈

三條 chain 在 production 階段都需要 build provenance、簽署驗證、依賴隔離跟回退機制。差異主要在模型權重 chain 的特殊性：權重是大型 binary（GB 級）、難以靜態 audit、且權重本身會影響推論行為。

分析模型

production LLM 供應鏈的分析依五個層次拆解、跟 7.4 的層次模型保持一致：

1. 來源層：模型 build provenance 是否可回溯（哪個 base model、用哪個 dataset、由誰量化）。
2. 產物層：GGUF / safetensors 在傳遞過程的完整性（hash / 簽署）。
3. 依賴層：MCP server / inference framework / model 各自獨立信任、影響面隔離。
4. 節奏層：模型版本切換、回退、freeze 流程。
5. 收斂層：供應鏈事件能否路由到 IR 流程。

判讀流程

判讀流程的責任是把「可部署的 LLM 服務」轉成「可信的 LLM 服務」。

1. 先確認模型來源 organization、量化版本、build provenance 可關聯。
2. 再確認 GGUF / safetensors 的完整性證據（hash、size、metadata）。
3. 接著確認模型 + server + plugin 三條 chain 的依賴隔離。
4. 最後交接到可靠性與 incident 流程、追蹤回退能力。

問題節點（案例觸發式）

常見風險邊界

風險邊界的責任是界定何時 LLM 供應鏈風險已進入高壓狀態。

• 模型來源（base + dataset + 量化者）長期無法回溯時、代表 provenance 模型失效。
• 模型 artifact 在 CDN / 鏡像層沒有簽署驗證時、代表完整性邊界不足。
• MCP server / plugin 跟 inference framework 共用單一信任域時、代表依賴隔離不足。
• 模型版本切換沒有 behavior regression test 時、代表 release 流程不收斂。

LLM 場景的特殊判讀

LLM 供應鏈相對一般 software 供應鏈有幾個特殊點：

1. 權重是大型 binary、難以靜態 audit：跟 source code 不同、權重檔案無法用 grep / diff / linter 找後門；只能用 behavior testing 跟 hash 比對。
2. 量化過程可能改變推論行為：同一 base model 不同量化版本、回答品質有差；量化者的可信度影響整體可信度、需 case-by-case 信任。
3. 模型 supply chain 跟 production deployment 解耦：模型釋出方（如 Meta、Qwen 團隊）跟 production 部署方通常不同單位、責任邊界要明確。
4. 「license」議題：模型權重的 license（如 Llama Community License）跟一般 software license 不同、production 使用需 legal review、不只是技術議題。
5. MCP server 多為 Node / Python 程式：跟一般 dependency 一樣有 supply chain 風險、但 LLM 場景下、MCP 對主機資源的副作用面比一般 dependency 大、需更嚴格的 isolation。

案例觸發參考

LLM 場景的供應鏈事件案例尚在累積中、本章先沿用 7.4 的通用案例。LLM-specific 案例累積後會補入 red-team/cases/llm-supply-chain/：

• 開源組件滲透與下游衝擊：XZ Backdoor 2024（同類威脅在 MCP server / inference framework 也適用）
• 平台級供應鏈事件：SolarWinds 2020（模型釋出方平台級事件適用）

事實查核註：LLM 供應鏈的公開事件案例累積還在早期、本章列舉的通用案例提供 mechanism 對照、不代表 LLM 場景已有等同規模的事件記錄。建議引用前以最新的 OWASP LLM Top 10 跟社群 incident 報告為準。

引用標準

LLM 場景的供應鏈標準在發展中、本章沿用 7.4 供應鏈與產物信任 的標準作為 mechanism 層 anchor、補上 LLM-specific 參考：

引用版本與 cadence 規則見 security-citation-currency-and-precision。Last reviewed: 2026-05-12。

下一步路由

• 交付平台與部署治理：05-deployment-platform
• 發佈驗證與回退演練：06-reliability
• 多租戶 LLM 推論隔離：llm-multi-tenant-isolation
• 偵測訊號設計：llm-as-service-detection-coverage
• 分級與跨部門收斂：08-incident-response

來源

Defender Pressure

Control Gap

控制缺口的核心是 artifact trust 需要跨越端點、CI、簽章與發佈流程。當 initial compromise 來自上游軟體時，單一 release gate 需要補足來源信任、build isolation 與 customer communication。

Detection Route

Exercise Hook

本案例可支撐 Supply chain artifact drill。演練重點是確認 artifact provenance、release freeze、rollback 與 customer communication 是否能在同一事件中協作。

Write-back Target

• 7.12 供應鏈完整性與 Artifact 信任
• 7.22 資安風險如何進入 Release Gate
• Detection lifecycle pattern
• Exercise write-back pattern

來源

Defender Pressure

Control Gap

控制缺口的核心是開源元件信任只看版本與簽章,缺少對維護者活動與 build artifact 行為的監控。XZ Utils 的 backdoor 只在特定 release 路徑啟用,單純依賴上游版本號與 license 檢查會漏掉這類風險。

Detection Route

Exercise Hook

本案例可支撐 Supply chain artifact drill 的開源變體。演練重點是確認團隊能在上游 advisory 出現時,快速比對 SBOM、降版受影響元件並驗證 sshd 行為。

Write-back Target

• 7.12 供應鏈完整性與 Artifact 信任
• 7.22 資安風險如何進入 Release Gate
• Detection lifecycle pattern
• Vulnerability response pattern

Scenario Trigger

客戶回報桌面客戶端或 agent 版本觸發 EDR alert。內部比對發現公開下載 artifact、build record 與簽章證據之間存在偏移。

Initial Hypothesis

Control Surface

控制面包含 artifact provenance、CI pipeline、release gate、release freeze、rollback 與 customer advisory。

Response Route

1. Freeze：暫停 affected artifact 發佈與自動更新。
2. Scope：比對 artifact hash、download log、customer version distribution。
3. Validate：重建 clean build、驗證簽章與 provenance。
4. Rollback：提供 clean artifact、uninstall 或 rollback route。
5. Write-back：更新 release gate、build isolation 與 artifact evidence policy。

Evidence Target

Write-back Target

• 7.12 供應鏈完整性與 Artifact 信任
• 7.22 資安風險如何進入 Release Gate
• Detection lifecycle pattern
• Exercise write-back pattern