安全儲存庫與拉取請求

Azure DevOps 服務 |Azure DevOps Server |Azure DevOps Server 2022

透過結合存取控制、提取要求原則和狀態檢查,保護 Azure Repos 中最重要的分支。 本文將教你如何限制直接變更、要求合適的審查者、執行工作項目與建置需求,以及在拉取請求合併前加入 GitHub 進階安全檢查。

Tip

你可以在本文的後面部分使用 AI 來協助此任務,或參考 啟用 Azure DevOps MCP Server 的 AI 協助功能 來開始。

威脅與控制

結合以下控制措施,降低最常見的拉取請求風險。

威脅 風險 建議的防治方法
直接推送至受保護的分支 變更會繞過審查與驗證 分支權限分支政策
單人核准 審核品質取決於一個人 需要最少的檢閱者數目
敏感檔案缺少專家審查 對安全性至關重要的變更會在沒有合適審查者的情況下被合併 自動包含的檢閱者
未追蹤程式碼變更 降低可稽核性與變更可追溯性 檢查連結的工作專案
破損或未經測試的程式碼 迴歸會到達共享分支 建置驗證
未解決的評論回饋 已知問題合併卻無回應 檢查批註問題的解決情況
新的高風險或嚴重漏洞 安全性回歸問題透過提取要求合併 GitHub 進階安全狀態檢查

Prerequisites

分類 Requirements
專案存取 專案的成員。
Permissions - 檢視私人專案中的程式碼:至少具有 基本 存取權。
- 複製或參與私人專案中的程式碼: 參與者 安全性群組的成員或專案中的對應許可權。
- 設定分支或儲存庫權限:管理分支或儲存庫的 權限
- 設定分支政策、狀態檢查或更改預設分支:編輯儲存庫或分支的政策權限,或加入 Project 管理員安全群組。
- 匯入存放庫: 專案系統管理員安全性 群組的成員或 Git 專案層級 建立存放庫 許可權設定為 [允許]。 如需詳細資訊,請參閱 設定 Git 存放庫許可權
Services 啟用 Repos
Tools Optional. 使用 az repos 指令:Azure DevOps CLI
分類 Requirements
專案存取 專案的成員。
Permissions - 查看代碼:至少基本訪問權限
- 複製或參與程式碼: 參與者安全性群組 的成員或專案中的對應許可權。
Services 啟用 Repos

在設定任何分支政策之前:

  • 確保目標儲存庫和分支已經存在。
  • 決定哪些群組可以管理權限、繞過政策並批准拉取請求。
  • 如果你打算要求建置驗證或 GitHub 進階安全性狀態檢查,請先建立建置管線。

多數團隊的安全性基準

對於典型的生產分支,如 main,請從以下基線開始:

控制區 建議的基準線 原因為何
存放庫存取 將寫入權限限制為僅限目前活躍於存放庫的貢獻者 減少可能變更原始碼或儲存庫設定的身份數量。
分支權限 在完成拉取請求時限制繞過政策,推送給小型管理員群組時則限制繞過政策 防止使用者跳過必要的審查、驗證及其他分支保護措施。
審查政策 main 至少需要兩位審查者 提升審查品質,降低單一錯誤或偏頗核准的風險。
敏感檔案 自動將安全性、基礎架構或合規相關的敏感路徑審查者納入其中 確保高風險領域的變更能由適當的人員或團隊審核。
可追蹤性 開啟 「檢查連結工作項目」 保留程式碼變更與作為其依據的工作項目之間的稽核軌跡。
Validation 為 PR 分支新增建置驗證 在程式碼合併到受保護分支前,捕捉建置與測試失敗。
審查完成 開啟 「檢查留言解析」 有助於確保審查者的疑慮在完成前已獲得處理。
脆弱閘門 在設定進階安全掃描後再補充AdvancedSecurity/NewHighAndCritical 阻擋引入新的高風險或關鍵安全發現的拉取請求。

步驟 1:限制儲存庫與分支存取

先從權限開始。 政策在只有少數使用者能繞過時最有效。

檢視儲存庫權限

利用儲存庫權限來控制誰能閱讀、貢獻、管理設定或貢獻拉取請求。 詳細的權限參考,請參見 Set Git 倉庫權限

使用下列模式:

  • 授予 貢獻 者在功能分支中運作所需的權限。
  • 將儲存庫管理權限僅限於少數管理員群組。
  • 避免授予廣泛的繞過政策權限。

限制分支權限

對於受保護的分支,請仔細審查並限制這些權限:

  • 完成拉取請求時繞過規則
  • 推送時略過政策
  • 強制推送(重寫歷程記錄、刪除分支和標籤)
  • 編輯政策
  • 管理權限

使用 設定分支權限 來設定這些項目。

main 的建議模式:

群組 建議的分支權限
貢獻者 允許透過提取要求進行一般貢獻,但不要授與略過權限
專案管理員 允許 編輯政策管理權限
緊急釋放的擁有者 僅在事件處理流程需要時,才授予繞過權限

Important

完成提取要求時略過原則推送時略過原則應僅限於少數受信任的管理員。 這些權限會使必要審閱者、驗證及狀態檢查所建立的保護機制失效。

步驟二:要求嚴格審查提取要求

需要至少一定數量的審閱者

main 和發行分支等重要分支上使用要求最少審查者人數

建議設定:

  • 高價值共用分支的最低審查人數:2
  • 最後一次迭代至少需要一次核准
  • 允許請求者自行核准變更Off
  • 禁止最新的推動者批准自己的變更On 當你想要更強的職責分離時

設定最小審查者政策

  1. 前往 專案設定>儲存庫
  2. 選擇你的儲存庫,然後選擇受保護的分支。
  3. 政策中,開啟 「要求最低審查人數」。
  4. 為該分支設定審核者選項。

驗證結果:

  • 分支原則清單顯示審閱者原則為已啟用。
  • 對此分支提出的提取要求,必須在獲得所需數量的核准後才能完成。

欲了解政策細節,請參閱 分支政策與設定

自動為敏感檔案加入審閱者

當某些檔案或資料夾需要特定個人或團隊核准時,請使用 自動包含的審查者

好的候選者包括:

  • 部署與基礎架構程式碼
  • 認證與授權碼
  • 合規敏感資料夾
  • 共用管線範本

設定自動包含的審查者政策

  1. 前往 專案設定>儲存庫
  2. 分支政策下開啟目標分支。
  3. 新增自動納入檢閱者政策。
  4. 加入所需的人員或團體。
  5. 請選擇此原則是必要選用
  6. 為需要審查的檔案或資料夾新增路徑篩選器。
  7. 不允許請求者核准自己的變更。

驗證結果:

  • 變更相符檔案的 pull request 會自動加入已設定的審閱者。
  • 提取要求在符合必要的審閱者原則之前,無法完成。

欲了解更多資訊,請參閱 「自動納入程式碼審查者」。

步驟 3:強制執行可追溯性與驗證

檢查關聯的工作專案

開啟 「檢查連結工作項目 」,當團隊需要變更拉取請求與工作追蹤之間的可追蹤性時。

設定連結工作項目政策

  1. 前往 專案設定>儲存庫
  2. 分支政策下開啟目標分支。
  3. 開啟「檢查連結的工作項目」
  4. 若拉取請求必須在完成前連結工作項目,則選擇 「必要 」。

驗證結果:沒有連結工作項目的拉取請求顯示政策未被滿足。

欲了解更多資訊,請參閱 「檢查相關工作項目」。

組建驗證

使用 Build 驗證 來要求在合併前成功執行 pull request 的管線。

Important

在設定建置驗證之前,先建立建置管線來驗證拉取請求。

受保護分支的建議設定:

  • 觸發:自動
  • 政策要求Required
  • 建置到期:選擇與受保護分支變更頻率相符的值

設定建置驗證政策

  1. 分支政策下開啟目標分支。
  2. 新增建置驗證原則。
  3. 選擇建置流程。
  4. 選擇是否需要該保單。
  5. 儲存原則。

驗證結果:

  • 開啟或更新提取要求時,系統會將已設定的驗證建置加入佇列。
  • 提取要求必須先等必要的建置成功,才能完成。

更多資訊請參見 建構驗證

檢查批註解決情況

使用 Check for comment resolution,確保審查討論串在提取要求完成前都已解決。

設定留言解決政策

  1. 分支政策下開啟目標分支。
  2. 開啟 檢查留言是否已解決
  3. 如果未解決的註解應阻止完成,請選擇 「必要」

驗證結果:含有尚未解決評論的提取要求會維持封鎖狀態,直到檢閱者或作者解決這些討論串。

欲了解更多資訊,請參閱 「檢查留言解析」。

限制合併類型

使用 限制合併類型 作為儲存庫的歷史治理設定。 此政策有助於標準化合併後拉取請求提交的呈現方式,但並非直接的安全控管。

根據團隊如何審查、追蹤及稽核歷史,選擇合併策略。

範例用途:

  • 對短期功能開發工作要求使用壓縮合併。
  • 在審計流程預期合併提交的分支上,禁止重新基準或壓縮。

審計與可追溯性考量:

  • Squash 會讓目標分支的歷史更乾淨,但它會在合併時將來源分支上的多個提交壓縮成一個提交記錄。
  • 如果你的稽核模型依賴於保留功能分支的精確提交序列,建議採用合併-提交策略而非壓縮。
  • 請讓您的政策與開發人員在提取要求和目標分支中檢查及偵錯歷史記錄的方式保持一致。

Azure DevOps CLI 範例:

az repos policy merge-strategy create \
  --blocking true \
  --branch main \
  --enabled true \
  --repository-id <repository-id> \
  --allow-no-fast-forward true \
  --allow-rebase false \
  --allow-rebase-merge false \
  --allow-squash false

欲了解更多資訊,請參閱 限制合併類型

步驟 4:新增 GitHub 進階安全狀態檢查

GitHub Advanced Security 的狀態檢查有助於在引入新的重大或高嚴重性弱點時,防止提取要求被合併。

Important

GitHub Advanced Security for Azure DevOps 只適用於 Azure DevOps Services,且僅限於 Code Git 倉庫。

在你新增狀態檢查政策之前:

  1. 在儲存庫啟用 GitHub 進階安全。
  2. 配置所需的進階安全管線任務。
  3. 為提取要求分支新增 建置驗證 原則。
  4. 啟用 Wait for Processing: true 以執行文件記載的進階安全性工作。
  5. 至少成功執行一次管線,讓狀態檢查顯示在 Status to check 清單中。

如果存放庫已經有尚未解決的警示,請先從 AdvancedSecurity/NewHighAndCritical 開始。 減少待處理工作後,請考慮遷移至 AdvancedSecurity/AllHighAndCritical

瀏覽器路徑:

  1. 分支政策下開啟目標分支。
  2. 狀態檢查中,選擇 +
  3. 狀態設定為勾選AdvancedSecurity/NewHighAndCritical
  4. 進階選項 維持在預設值。
  5. 儲存原則。

進階安全狀態檢查會在你啟用進階安全掃描與建置驗證後,從瀏覽器的 狀態檢查 中設定。 如需了解所需設定,請參閱 設定提取要求狀態檢查

驗證結果:

  • 包含新的高風險或重大風險發現的提取要求,狀態檢查會顯示為失敗。
  • 分支政策會阻擋完成,直到發現結果解決或政策變成可選。

關於設置細節,請參見:

範例推出計畫

低敏感度存放庫基準

如果儲存庫的敏感度較低,且你想要一個可管理的起點:

  1. 限制對 main 的分支繞過權限。
  2. 至少要求一到兩位審查員。
  3. 開啟連結的工作項目。
  4. 新增建構驗證功能。
  5. 開啟留言解決功能。

高靈敏度資料庫

若儲存庫包含部署、身份或合規關鍵資產:

  1. 將略過原則的權限僅限於系統管理員。
  2. 要求在 main 上需有兩位審閱者。
  3. 新增受保護的路徑所自動加入的審閱者。
  4. 要求連結的工作項目。
  5. 新增建構驗證功能。
  6. 如果你使用 Azure DevOps 服務,請新增 GitHub 進階安全狀態檢查。

可選性:使用 AI 協助檢視分支政策配置

AI 協助是可選的。 你的分支權限、政策和狀態檢查都會強制執行儲存庫保護,不論你是否使用 AI。

你可以利用這些提示檢視政策設定、找出缺口,並更快獲得基準建議。 如果你設定了 Azure DevOps MCP Server,助理就能利用你的 Azure DevOps 上下文來改善回答。 關於設定指引,請參見啟用 Azure DevOps MCP Server 的 AI 協助

請使用以下提示開始:

Goal 範例提示
檢視分支保護 Summarize the branch policies on main and explain which ones are required.
識別繞過風險 Find users or groups that can bypass branch policies on the main branch.
查看評論涵蓋範圍 List the reviewer and comment-resolution policies configured for this repository.
驗證工作追蹤 Check whether pull requests into main require linked work items.
檢查驗證閘 Show the build validation policy for main and explain what pipeline it uses.
查看安全性狀態檢查 List the status checks configured for main and tell me whether GitHub Advanced Security is one of them.
規劃一個更安全的基準 Recommend a secure branch policy baseline for this repository based on its current settings.

在套用指令和建議前,務必驗證其與你的儲存庫權限、分支設定以及目前 Azure DevOps 文件的照準。

疑難排解秘訣

Problem 可能的原因 建議的動作
分支政策選項不存在 你沒有 編輯政策 權限,或者分支沒有被選中 確認分支存取權限與政策權限
提取要求即使未符合原則,仍可合併 使用者擁有繞過權限 完成拉取請求時請檢視繞過政策,推送時則檢視繞過政策
必須的審查員不會被加入 審查者政策路徑過濾器與更改後的檔案不符 重新檢查路徑篩選器和審查者身份
進階安全狀態檢查無法使用 存放庫尚未完成包含所需工作的一次成功掃描執行 驗證建置驗證、管線任務與 Wait for Processing 設定
連結的工作項目政策不會被封鎖 此政策為可選性,非強制性 重新開啟分行政策並確認需求等級