服務定位

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