服務定位

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