D5：安全營運：最佳做法、優先順序與修復
D5-O1 理解弱點脈絡與修復框架
弱點資料的三個名詞
- CVE： 弱點的公開編號。GitHub Advisory Database 中，來自 National Vulnerability Database 的 advisory 會附上 CVE 的連結。
- CWE： 弱點的類型標籤。Code scanning 計算安全嚴重度時，會找出與查詢相關 CWE 的所有 CVE，取其 CVSS 分數的第 75 百分位（見 D4）。
- GHSA ID： 每則 advisory（不論類型）在 GitHub 的唯一識別碼，格式為
GHSA-xxxx-xxxx-xxxx，其中 x 是23456789cfghjmpqrvwx這組字元之一；數字與字母隨機指派，字母全為小寫。
GitHub Advisory Database
Advisory 以 Open Source Vulnerability（OSV）格式的 JSON 檔發布。Global security advisory 分三類：
| 類型 | 來源與特性 | 是否產生 Dependabot 警示 |
|---|---|---|
| GitHub-reviewed | 對應到支援生態系中的套件，經 GitHub 審查有效性，含完整描述與生態系、套件資訊 | 會 |
| Unreviewed | 直接從 National Vulnerability Database feed 自動發布，未檢查有效性或完整性 | 不會 |
| Malware | 關於惡意開源套件，自動從 npm 安全團隊與 OpenSSF Malicious Packages 儲存庫發布 | 一般警示不會；啟用 malware alerts 後，偵測到惡意軟體時才產生 |
- 弱點（vulnerability）與惡意軟體（malware）不同： 弱點通常是意外引入、很快修復，advisory 會列出受影響的版本範圍與最早的修復版本；惡意軟體是刻意設計的有害程式碼，沒有修復版本，要把它從專案移除並找替代方案。惡意軟體 advisory 多半是替換攻擊（substitution attack）：攻擊者在公開 registry 發布與你依賴的第三方或私有 registry 套件同名的套件。可用
type:malware搜尋。 - 嚴重度： 採 CVSS 的四個等級（Low、Medium/Moderate、High、Critical）；支援 CVSS 3.1 與 4.0。
- EPSS： 由 FIRST 提供的利用可能性分數，介於 0 到 1（0% 到 100%），越高越可能被利用。例：90.534% 且在第 95 百分位，表示未來 30 天內被利用的機率為 90.534%，且 95% 的已模型化弱點被認為比它更不可能被利用。EPSS 資料由 GitHub 每日同步，GitHub 不撰寫這些資料，因此不能經社群貢獻編輯。
- 社群貢獻： 對
github/advisory-database提交 pull request 改善全域 advisory，由 GitHub Security Lab 策展團隊審查；被接受時，提交者自動獲得 Analyst 的 credit。
修復流程（端到端）
以 code scanning 為例：警示出現 → 評估（影響、資料流、嚴重度）→ 指派給負責人 → 修復（手動、Copilot Autofix 或 agentic autofix）→ pull request 觸發重新分析 → 合併後警示關閉；不需修復者以記錄的原因關閉。Dependabot 警示則是：advisory 或 dependency graph 變動 → 警示 → security update pull request → 合併後警示關閉。細節見 D3 與 D4。
判斷練習
情境： 團隊看到某則 advisory 的 EPSS 為 90.534%（第 95 百分位），主管問「這是不是代表有 90% 的專案受影響」。
解析： 不是。EPSS 是這個弱點在未來 30 天內被利用的機率，不是受影響專案的比例；第 95 百分位表示 95% 的已模型化弱點比它更不可能被利用。
來源：GitHub Advisory Database（GH500-DOC-44）、Global security advisories（GH500-DOC-45）、Code scanning alerts（GH500-DOC-31）；2026-11-02 已對照抓下的頁面段落；其餘為整理，備考前請讀來源原文。
D5-O2 大規模排定與管理安全工作
Security campaigns
Security campaigns 把一組警示分享給開發者，一起消化安全待辦。可用條件：啟用 Secret Protection 或 Code Security 的 GitHub Team 組織。用途包含改善公司安全態勢、以一組相關的 code scanning 警示強化開發者訓練、確保 secret 警示在修復目標內解決、促進安全團隊與開發者共同擁有警示，並讓開發者清楚知道最緊急的是哪些。
- 開發者會被通知可參與的 campaign，不必離開日常工作流程就能看到警示；每個 campaign 有指名的聯絡人。
- Code scanning 警示會自動觸發 Copilot Autofix 建議；若啟用 agentic autofix，可把 code scanning 警示指派給 Copilot 自動產生 pull request。一次最多選 25 則，一次指派一個 agent session、一個 pull request。
- 可用範本選取一組密切相關的警示，讓修好一則的經驗幫助修好其餘；也可用自訂篩選器。範本在 agentic autofix 停用時，會加上
autofix:supported，只納入 Copilot Autofix 支援的規則。 - 建立與管理：組織擁有者、security manager 與具 admin 角色的組織成員，在組織的 Security and quality → Campaigns。campaign 的警示數不得超過 1000 則。 可先存成草稿（供審查與回饋）再發布；要設定到期日與 campaign manager（必須是組織的擁有者或 security manager 的使用者或團隊）；可附聯絡連結。也可用 REST API 大規模建立與操作。
| 屬性 | Code campaign | Secret campaign（公開預覽） |
|---|---|---|
| 可納入的警示 | 僅預設分支 | — |
| 開發者通知需要 | 對 repository 有寫入權限 | 對警示清單有檢視權限 |
| 指派可能提權 | 頁面未說明 | 是（暫時提高，取消指派即撤銷） |
| 自動修復 | Copilot Autofix | — |
警示可指派給有寫入權限的使用者；GitHub 在被指派與警示被關閉時通知。Code scanning 可用 REST API 指派／取消指派並依指派者篩選，另有 webhook 通知指派與取消。
嚴重度與修復規則
可用 ruleset 把 code scanning 結果變成合併條件（見 D4）：設定 Require code scanning results，為每個必要工具選擇警示等級（None、Errors、Errors and Warnings、All）與安全警示等級（None、Critical、High or higher、Medium or higher、All）。建立者為組織擁有者、security manager，以及具 admin 角色的成員；也可用 REST API 建立含 code_scanning 規則的 ruleset。
自動關閉與記錄
- Auto-triage 規則（見 D3）在通知寄出前自動關閉或延後警示；自動關閉的警示仍可查詢與重新開啟。
- 手動關閉要選擇原因並可加註解，記錄在警示時間軸；原因選擇可能影響查詢是否繼續納入未來分析。可依篩選批次關閉。
- 委派關閉（delegated alert dismissal）： 啟用後，有寫入權限的使用者必須提出關閉請求；組織擁有者與 security manager 可核准、拒絕，或直接關閉。審查者以電子郵件收到請求，請求者也會以電子郵件收到結果。可用於 code scanning 與 secret scanning（GitHub.com 與 GitHub Enterprise Server 3.17 以上），以及 Dependabot（GitHub.com 與 GitHub Enterprise Server 3.21 以上）。
判斷練習
情境： 資安主管想建立一個 campaign，一次納入 1,500 則 code scanning 警示。
解析： 一個 campaign 的警示不得超過 1000 則；要調整篩選條件縮小範圍，或拆成多個 campaign。
來源：About security campaigns（GH500-DOC-09）、Creating and managing security campaigns（GH500-DOC-46）、Set code scanning merge protection（GH500-DOC-47）、Delegated alert dismissal（GH500-DOC-11）、Resolving code scanning alerts（GH500-DOC-39）；2026-11-02 已對照抓下的頁面段落；其餘為整理，備考前請讀來源原文。
D5-O3 自訂並最佳化安全偵測
依組織風險調整偵測
| 手段 | 用途與限制 |
|---|---|
| 選 query suite | default（精確度高）、security-extended（更多、精確度稍低）可用於 default setup；security-and-quality 與自訂 suite 需要 advanced setup。組織擁有者與 security manager 可為組織推薦 default setup 的 query suite |
| 自訂 CodeQL 查詢 | 偵測專屬於應用程式架構或框架的弱點、強制組織規範；只能在 advanced setup 或外部 CI 執行 |
| Repository properties | github-codeql-extra-queries 為組織內所有相關分析加入額外查詢，不必修改個別 workflow 或改用 advanced setup；github-codeql-config-file 套用設定檔；套用到所有 setup 類型 |
| 語言與 threat model | default setup 可選擇分析的語言、threat model（公開預覽，僅 Java/Kotlin 與 C#）與 CodeQL model pack |
| 自訂 secret 樣式 | 定義 repository、組織或企業層級的自訂樣式；先 dry run 檢視誤判再發佈（見 D2） |
調整前先在一個測試 repository 驗證：第一次設定屬性時，先在組織建立但不設值，改在測試 repository 設值並驗證後再推廣。
取捨
查詢集越寬，誤報越多、審查負擔越重；越窄則漏報風險越高。選擇應回應組織的風險輪廓與審查能力，而不是一律選最完整的。官方對各 suite 的描述是「precision 與 severity 的差異」，沒有給出「應該選哪一個」的規則；本節對此不做更具體的建議。
判斷練習
情境： 組織有 300 個 repository 使用 default setup，想為全部加上一組公司自訂的 CodeQL 查詢，但不想逐一改成 advanced setup。
解析： 在組織建立並設定 github-codeql-extra-queries repository property。它套用到所有 setup 類型，不必修改個別 workflow。
來源：Repository properties for code scanning（GH500-DOC-36）、CodeQL query suites（GH500-DOC-28）、Custom CodeQL queries（GH500-DOC-29）、Defining custom patterns for secret scanning（GH500-DOC-05）；2026-11-02 已對照抓下的頁面段落；其餘為整理，備考前請讀來源原文。
D5-O4 跨角色協作並落實治理
Security manager
組織層級角色，組織擁有者可指派給任何成員或團隊，用來給資安人員「最少所需」的權限。權限：所有 repository 的讀取權限；所有安全警示的寫入權限；在組織與 repository 層級設定安全功能（含啟用或停用 GitHub Advanced Security 功能）的能力。擁有 security overview 等額外功能（需要 Secret Protection、Code Security 或 Advanced Security）。若團隊持有此角色，對團隊與特定 repository 有 admin 權限的人可以變更團隊的存取層級，但不能移除存取。也可建立自訂安全角色（例如只管理 secret scanning 結果與繞過請求，或合併稽核日誌權限）。
委派機制
| 機制 | 作用 |
|---|---|
| 委派繞過 push protection | 授予特定個人、角色、團隊繞過權限（被擋的 commit 可放行）；授予特定對象豁免（完全略過 push protection，宜用於遷移機器人、服務帳號）；其他貢獻者的繞過請求進入審查，請求 7 天後過期。適用於在 GitHub 上建立、編輯與上傳的檔案 |
| 委派警示關閉 | 限制誰能直接關閉警示；寫入權限者須請求，擁有者與 security manager 審查（見 O2） |
| 自訂角色 | 讓非擁有者、非 security manager 的成員回應關閉請求並直接關閉警示；自訂組織角色需要審查並略過警示關閉請求的組織權限，以及檢視、關閉與重新開啟警示的 repository 權限（repository 權限加入自訂組織角色目前是公開預覽） |
一律可繞過 push protection 的人： 組織擁有者、security manager、繞過名單中的團隊／預設角色／自訂角色的成員，以及被指派具「審查並管理 secret scanning 繞過請求」細部權限之自訂角色的使用者。委派繞過可用於啟用 Secret Protection 的 GitHub Team 組織 repository。
警示所有權與協作
- 有寫入權限者可被指派警示；指派對象會被通知，警示頁面顯示其名稱。Dependabot 警示的指派需要 Code Security 或 Advanced Security 授權（D3）。
- Campaign 讓安全與開發團隊協作：開發者在日常流程看到警示，campaign manager 作為聯絡人處理問題與審查；secret 警示指派可暫時提權，讓無法檢視警示清單的被指派者處理。
- 開發者、安全人員與管理員的責任分工（依本節上述權限整理）：開發者修復並提交 pull request、依政策請求關閉警示；security manager 審查請求並設定功能；組織擁有者管理角色與組織層級政策。
跨套件的 ruleset 與政策
Rulesets 是一組命名規則，控制人如何與分支和標籤互動。與安全相關的規則包括：要求 workflow 通過（用於強制 dependency review，D3）、要求 code scanning 結果（D4），以及企業層級的授權合規政策。
判斷練習
情境： 組織想讓一個遷移機器人帳號的推送完全不被 push protection 阻擋，同時讓一般開發者被擋時能提出繞過請求。
解析： 對機器人授予豁免（exemption）；對一般開發者啟用委派繞過的審查流程，請求 7 天後過期。
來源：Managing security managers in your organization（GH500-DOC-10）、About delegated bypass for push protection（GH500-DOC-04）、Delegated alert dismissal（GH500-DOC-11）、About security campaigns（GH500-DOC-09）；2026-11-02 已對照抓下的頁面段落；其餘為整理，備考前請讀來源原文。
D5-O5 左移並強化預防性安全
在變更進入預設分支或 repository 之前就攔下問題，是預防導向的做法。對照 GitHub 的功能：
| 階段 | 功能 | 做法 |
|---|---|---|
| 推送時 | Push protection | 在推送時阻擋 secret，讓開發者在來源處修正（D2） |
| 開 pull request | Code scanning | 結果以檢查與註解呈現，高嚴重度預設使檢查失敗（D4） |
| 開 pull request | Dependency review | 顯示相依性變動與弱點，action 預設在發現有弱點的套件時失敗（D3） |
| 合併前 | Rulesets 合併保護 | 要求 workflow 通過、要求 code scanning 結果，在不符時阻擋合併（D3、D4） |
| 合併後 | Security campaigns、Dependabot security updates | 處理已累積的警示與已知弱點（事後處理） |
- Code scanning 合併保護不會自動啟用掃描；它把「沒掃描」視為不通過。通常用在長期存在的功能分支。
- 預防與事後處理要搭配：左移降低新增問題，campaigns 消化既有 backlog。
- 學習指南把「預防優先」與「門檻式（gate-based）」策略並列比較，但我讀到的頁面沒有定義「gate-based」，本節不補寫其定義。
判斷練習
情境： 團隊只依賴每週的 Dependabot 警示處理相依性風險，想「左移」。
解析： Dependabot 警示是事後處理已在相依性中的弱點；要在引入前攔下，使用 dependency review（pull request 層）並用 ruleset 要求 dependency review workflow 通過才能合併。
來源：About push protection（GH500-DOC-02）、Dependency review（GH500-DOC-15）、Code scanning merge protection（GH500-DOC-33）、GitHub security features（GH500-DOC-07）；2026-11-02 已對照抓下的頁面段落；其餘為整理，備考前請讀來源原文。