D1：GitHub 安全套件、功能與生態系
D1-O1 理解 GitHub 安全套件與架構
GitHub 的安全功能分成三層，差別在於「誰能用」：所有方案都有的基本功能、需要購買 GitHub Secret Protection 的功能，以及需要購買 GitHub Code Security 的功能。後兩者提供給 GitHub Team 與 GitHub Enterprise Cloud 的組織；另外，其中不少功能在公開 repository 上可以免費使用。
三層功能對照
| 層級 | 主要功能 |
|---|---|
| 所有方案 | security policy、dependency graph、SBOM 匯出、GitHub Advisory Database、Dependabot alerts 與 security updates、version updates、repository security advisories、repository rulesets、artifact attestations、合作夥伴的 secret scanning 通知、使用者層級的 push protection |
| Secret Protection（需購買） | secret scanning 的使用者警示、AI 偵測的 secret、push protection、delegated bypass、custom patterns、security overview |
| Code Security（需購買） | code scanning、CodeQL CLI、Copilot Autofix、AI Scan、Dependabot 的自訂自動分流規則、dependency review、security campaigns、security overview |
要注意的細節：artifact attestations 在 Free、Pro、Team 方案只能用在公開 repository，私有或 internal repository 需要 Enterprise Cloud。Security overview 同時列在 Secret Protection 與 Code Security 之下。
公開 repository 的差別
官方在下列功能標示「公開 repository 預設可用」：secret scanning 使用者警示、push protection、code scanning、CodeQL CLI、Copilot Autofix 與 dependency review。Delegated bypass、custom patterns、AI Scan、自訂自動分流規則與 security campaigns 則沒有這個標示。判斷時以功能為單位，不要把整個套件當成「公開就免費」。
Security overview
Security overview 位於組織的 Security and quality 頁籤，讓你檢視整個組織的安全狀況、趨勢，並找出風險最高的 repository。它的檢視包括：
- Overview：偵測（Detection）、修復（Remediation）與預防（Prevention）三方面的趨勢。
- Risk、Coverage、Enablement：風險、功能採用率、各團隊採用速度。
- Assessments、Campaigns、Code scanning on pull requests、Dependabot、Secret scanning。
所有檢視顯示的是各 repository 預設分支的資料。免費的 secret risk assessment 讓 GitHub Team 的組織在沒有購買任何套件時，也能評估組織的 secret 外洩風險；購買 Secret Protection 或 Code Security 後才有更多檢視。
判斷練習
情境： 管理員打開 security overview，某個 repository 沒有任何警示，於是回報「這個 repository 沒有弱點」。
解析： Security overview 顯示的是各項功能產生的有效警示。沒有警示，可能是真的沒有問題，也可能是弱點尚未被偵測，或該功能根本沒有在這個 repository 啟用。要先用 Coverage 檢視確認功能有啟用，才能解讀「沒有警示」。
來源：GitHub security features（GH500-DOC-07）、Security overview（GH500-DOC-08）；2026-11-02 以頁面原文比對本節的數字與名稱；其餘敘述為整理，備考前請讀來源原文。
D1-O2 套用安全 SDLC 與安全策略
Secret Protection 與 Code Security 處理不同的風險。Secret Protection 針對憑證外洩與 secret 蔓延：用 secret scanning 找出寫死的憑證，用 push protection 在它進入 repository 之前攔截。Code Security 針對程式碼與相依性的弱點：用 code scanning 找出程式碼弱點，並結合進階的 Dependabot 功能與 dependency review。兩者的警示都會匯總到 security overview，也都可以用 security campaigns 集中修復。
功能對應到開發流程
| 階段 | 功能 | 作用 |
|---|---|---|
| 推送 | push protection | 偵測到 secret 時阻擋推送；繞過會產生警示 |
| Pull request | code scanning、dependency review | 在合併進預設分支之前找出弱點、檢視相依性變更 |
| 維護 | Dependabot alerts、security updates、version updates | 通知已知弱點，並自動開 pull request 更新 |
| 大規模修復 | security overview、security campaigns | 看出風險與趨勢，集中修復累積的警示 |
| 建置與發布 | artifact attestations、immutable releases | 建立可驗證的來源與完整性 |
預防與事後偵測
上表中，push protection、PR 上的 code scanning 與 dependency review 都發生在變更進入預設分支或 repository 之前，這是預防導向；警示與修復活動則是事後處理已存在的問題。學習指南把「預防優先」與「門檻式（gate-based）策略」並列比較，但我讀過的 GitHub 官方頁面沒有定義「gate-based」這個詞，所以本節不替它下定義；備考時請以學習指南與官方文件的用法為準。
Security campaigns
Security campaign 把一批警示分組，分享給開發者，讓安全團隊與開發者協作清除待修復的警示（官方稱為 burn down your security backlog）。它的特點是：
- 開發者會收到可參與的 campaign 通知，並在日常工作流程中看到被標示的警示。
- 每個 campaign 有一位具名的聯絡人。
- 針對 code scanning 警示，Copilot Autofix 會自動被觸發來建議修復。
- 可以把 code scanning 與 secret scanning 警示指派給有寫入權限的使用者。
- 可使用範本，選出一群彼此相近的警示。
Code campaign 只納入預設分支的警示，會建立 repository 追蹤 issue；secret scanning 的 campaign 目前為公開預覽。使用條件是 GitHub Team 的組織且已啟用 Secret Protection 或 Code Security。
判斷練習
情境： 團隊累積了上百個 code scanning 警示，安全主管只在 Slack 提醒大家「有空去修」，三個月沒有進展。
解析： 這是 security campaign 要解決的問題：把最緊急、相近的警示分組，指派負責人與聯絡人，讓開發者在原有流程裡看到並追蹤進度，而不是靠口頭提醒。
來源：GitHub security features（GH500-DOC-07）、About security campaigns（GH500-DOC-09）；2026-11-02 以頁面原文比對本節的數字與名稱；其餘敘述為整理，備考前請讀來源原文。
D1-O3 偵測、管理與回應安全警示
三類主要警示的偵測來源不同。Secret scanning 以樣式找出寫死的憑證；code scanning 在新的或修改過的程式碼中找出弱點與編碼錯誤；Dependabot 把 dependency graph 與 GitHub Advisory Database 交叉比對，在「資料庫新增一則 advisory」或「repository 的 dependency graph 變動」時產生警示，也會偵測惡意套件並發出 malware alert。Secret scanning 與 Dependabot 的警示顯示在 repository 的 Security and quality 頁籤。
管理與指派
可以把 code scanning 與 secret scanning 警示指派給任何有寫入權限的使用者；被指派與警示被關閉時，GitHub 會通知相關的人。若 secret scanning 警示的被指派人原本看不到警示清單，他的權限會暫時提高以便處理，取消指派後權限即收回。
關閉警示的治理
預設下，有寫入權限的人可以關閉警示。啟用 delegated alert dismissal（委派警示關閉）後：
- 有寫入權限的使用者必須提出關閉請求。
- 組織擁有者與 security manager 可以核准或拒絕請求，也能自己直接關閉警示。
- 審查者透過電子郵件收到請求；審查完成後，請求者也會收到結果。核准即關閉警示，拒絕則保持警示開啟。
此功能適用於 code scanning、secret scanning 與 Dependabot 警示（各產品需要的 GitHub Enterprise Server 版本不同）。
誰負責什麼
| 角色 | 官方文件中的責任 |
|---|---|
| 開發者（寫入權限） | 修復被指派的警示；啟用 delegated dismissal 後，要關閉須先提出請求 |
| Security manager | 檢視並對所有警示有寫入權限、設定組織與 repository 層級的安全功能、審查請求 |
| 組織擁有者 | 指派 security manager 角色、核准或拒絕關閉請求、檢視全組織的安全資料 |
需要小心的資料行為
- 把 repository 封存（archive）後，其中仍開啟的警示會自動被關閉。
- Security overview 的儀表板指標會隨時間變動：同一段歷史期間，在不同時間查看可能得到不同結果（例如 repository 被刪除、advisory 被修改）。需要一致資料做合規或稽核時，官方建議改用稽核日誌（audit log）。
判斷練習
情境： 稽核人員要求提供「去年第三季所有已關閉警示」的數字，團隊直接截取 security overview 儀表板。
解析： 儀表板是依 repository 目前狀態與警示歷史狀態計算，數字可能在不同時間改變。需要不變的合規資料時，官方建議使用稽核日誌，而不是儀表板。
來源：About security campaigns（GH500-DOC-09）、Delegated alert dismissal（GH500-DOC-11）、Supply chain security（GH500-DOC-12）、Security overview（GH500-DOC-08）；2026-11-02 以頁面原文比對本節的數字與名稱；其餘敘述為整理，備考前請讀來源原文。
D1-O4 管理存取、治理與供應鏈安全
Security manager 角色
Security manager 是組織層級的角色，由組織擁有者指派給任何成員或團隊。它給予：所有 repository 的讀取權限、所有安全警示的寫入權限，以及在組織與 repository 層級設定安全功能（包含啟用或停用 GitHub Advanced Security 功能）的能力。較大的組織可建立專屬團隊。需要更窄或更寬的權限時，可以建立自訂安全角色，例如只管理 secret scanning 結果與繞過請求，或結合稽核日誌。
存取與可見度
Security overview 的可見範圍取決於角色：組織擁有者與 security manager 可檢視組織內所有 repository 的安全資料；一般成員只能看到自己有權檢視警示的 repository；企業擁有者要看到 repository 層級的細節，必須在該組織具備相應角色。
治理功能彼此獨立，要分清楚各管什麼：delegated bypass 管的是「誰能繞過 push protection、誰被豁免、誰審查繞過請求」；delegated alert dismissal 管的是「誰能關閉警示」。後者若要交給非擁有者、非 security manager 的人，可使用自訂角色，並賦予審查與繞過關閉請求的組織權限，以及檢視、關閉、重新開啟警示的 repository 權限（在自訂組織角色中加入 repository 權限目前為公開預覽）。
供應鏈安全的基本概念
專案依賴的函式庫、框架與工具統稱為相依性，整體構成供應鏈。直接寫在 manifest 或 lockfile 的是直接相依性；專案不直接指定、但被相依性使用的是間接（transitive）相依性。Supply chain attack 指攻擊者利用相依性的弱點插入惡意程式碼或竊取資料。
| 功能 | 作用 | 備註 |
|---|---|---|
| Dependency graph | 列出上游相依性與公開的下游依賴者，包含直接與間接相依性 | 其他功能依賴它；可匯出為 SPDX 相容的 SBOM |
| Dependency review | 在 pull request 檢視新增、移除、更新了哪些相依性及其安全影響 | 需要先啟用 dependency graph；私有 repository 還需要授權 |
| Dependabot alerts | 依 dependency graph 與 Advisory Database 通知已知弱點 | 預設不啟用；需 dependency graph |
| Dependabot security updates | 由警示觸發，更新到能解決弱點的最低版本 | 不一定需要設定檔 |
| Dependabot version updates | 依你設定的排程更新到符合設定的最新版本 | 需要設定檔；不使用 dependency graph |
| Artifact attestations | 以密碼學簽署，證明建置的來源（原始碼與工作流程）或 SBOM | 不保證安全，只提供來源資訊；公開 repository 可用 |
| Immutable releases | 發布後禁止更動 release 的資產與 Git tag | 預設不啟用；發布時自動產生 attestation |
另外，當生態系不被 dependency graph 的 manifest 分析支援時，可以用 dependency submission API 提交相依性；GitHub Actions 建置時提交的資訊也能補足在建置階段才展開的間接相依性。
判斷練習
情境： 團隊啟用了 Dependabot version updates，認為這樣已經涵蓋「有弱點的相依性會自動修復」。
解析： Version updates 依排程把相依性更新到最新版本，與是否有弱點無關，也不使用 dependency graph。針對已知弱點、由警示觸發、更新到最低修補版本的，是 Dependabot security updates，兩者要分別啟用。
來源：Managing security managers in your organization（GH500-DOC-10）、Delegated alert dismissal（GH500-DOC-11）、Supply chain security（GH500-DOC-12）、GitHub security features（GH500-DOC-07）；2026-11-02 以頁面原文比對本節的數字與名稱；其餘敘述為整理，備考前請讀來源原文。