本文說明管理軟體原始碼的最佳做法。
軟體團隊管理來源的基本步驟是採用版本管控系統 (VCS)。版本控制系統會提供變更記錄和稽核功能。GitHub 等代管版本管控系統提供額外優勢，例如可用性、穩定性、安全控管、整合式程式碼審查工具，以及與其他雲端服務的整合。
雖然大多數團隊目前都使用版本控管，但設定版本控管系統，以及與 CI/CD 管道其他部分的整合方式有很多種。
本文探討設定版本控管系統時，應考量的軟體供應鏈安全事項。這份指南說明軟體構件供應鏈層級的最佳做法，這個架構可保護軟體供應鏈。架構包含多個層級的要求，可協助您逐步實作變更，包括來源要求。
具備變更記錄和不可變更修訂版本的版本管控系統，是 SLSA 第 2 級的要求。建議您以 SLSA 第 2 級為軟體供應鏈的起始基準等級。
在 SLSA 等級 3，原始碼和建構平台會遵守更嚴格的安全防護要求，包括經過驗證的原始碼記錄和原始碼保留政策。SLSA 第 4 級會在來源要求中加入雙人審查。
除了應用程式來源，也使用版本控制
將應用程式來源儲存在版本控管系統中，是需要進行歷史記錄審查和稽核時的既定做法。不過，其他類型的來源 (包括設定、政策和資料) 也適用於版本控管。包括：
- 影響運算基礎架構的可用性和安全性
- 需要協作才能完成
- 需要可重複的核准程序
- 需要變更記錄
舉例如下：
- 基礎架構即程式碼：如果企業想以可擴充且安全的方式管理基礎架構，基礎架構即程式碼就是重要的方法。舉例來說，您可以將建立 Artifact Registry 存放區的 Terraform 模組儲存在版本控管系統中。
- 設定管理：設定管理與基礎架構即程式碼類似，但著重於使用 Ansible、Puppet 和 Chef 等工具管理應用程式設定。您可以在版本控制系統中儲存及管理應用程式設定檔。
- 資料庫設定和遷移指令碼：儲存產品資料庫和 Analytics 或記錄資料庫的設定和指令碼。
- Jupyter 筆記本：您可以使用多種方式處理儲存在 GitHub 中的筆記本，包括 JupyterLab 的擴充功能、Colaboratory 和 Vertex AI Workbench
- 安全性政策：儲存政策檔案，自動強制執行政策。 舉例來說，您可以儲存 Gatekeeper 政策，允許或拒絕 GKE 中的部署行為，或是儲存 Sentinel 政策，防止 Terraform 佈建違反政策的基礎架構。
版本管控是 DORA 開發運作研究發現的技術能力之一，可提升軟體交付及機構成效。將指令碼、原始碼和設定檔儲存在版本控管系統中，有助於重現及復原環境、追蹤及稽核變更，以及快速因應缺陷。
存放區設定
存放區是組織程式碼和相關角色、權限、整合及核准的基本邏輯單元。
存放區設定可能發生的問題包括：
- 存放區設定並未標準化，因此很難確保存放區安全性符合所代表的應用程式，特別是當機構有數百或數千個存放區時，這種常見情況更是如此。
- 建立存放區的人會成為擁有者，具備完整管理權限，包括在沒有其他審查員的情況下執行合併作業。
- 將存放區與程式碼分析、建構伺服器、問題追蹤器、通知服務，以及 CI/CD 基礎架構的其他部分整合，可能需要大量工作。建立及設定存放區的標準做法可節省重複作業，並支援最佳做法。
如要解決這些問題，最佳做法包括
- 透過自動化、可重複執行的安全程序設定存放區。舉例來說，您可以設定 Terraform 模組，納入存放區所屬應用程式的安全防護需求。高安全性應用程式需要比低安全性應用程式更多且不同的合併核准者。
- 讓存放區管理員從一組存放區設定範本中選取，以驅動新的存放區設定，而不是從頭設定每個存放區。這些範本應反映應用程式的不同安全等級，並與各安全等級所需的使用者身分同步。在實務上，這通常是指使用階層式身分與存取權控管 (IAM) 系統，反映貴機構的應用程式和基礎架構，以及負責這些項目的使用者。
- 要求集中式身分管理，並為存放區使用者啟用多重驗證。
- 集中式身分管理可確保使用者離開機構或調往新團隊時，您仍能維持來源管理方面的最低權限。
- 多重驗證可大幅降低來源遭到網路釣魚和其他類型攻擊的風險。程式碼核准者必須啟用雙重驗證，才能達到 SLSA 第 4 級要求。
- 只允許少數幾位值得信賴的員工擔任存放區擁有者。這可能需要將版本控管與身分管理系統整合，並將設定政策的權限移至機構的較高層級。如有可能，請移除存放區擁有者在沒有第二位審查員的情況下執行合併的權限。
審查程式碼
程式碼審查是機構維護軟體品質和安全性的主要方式。程式碼審查會嘗試解決各種失敗模式，例如：
- 導入有軟體缺陷或設計不靈活的程式碼。
- 定義不當的 API
- 開發人員編寫不安全的程式碼，導致出現安全性問題
- 新增不安全或可能變得不安全的第三方程式庫，導致出現安全性問題。
降低風險的方法包括：
- 在整個軟體生命週期中實作測試自動化。當您將來源提交至版本控管系統時，系統會觸發自動化測試，開發人員可藉此快速取得測試發現問題的意見回饋。
- 審查員人數和身分應與應用程式的安全等級相符。舉例來說，使用率低的內部網路應用程式，安全性需求會低於公開發布的業務關鍵應用程式。
- 根據技術專業知識和提交內容變更所需的信任等級，指派審查人員。審查人員應精通所審查的語言、程式碼互動的系統，以及這類應用程式中的安全風險。技術專業知識要求涵蓋許多層面。例如：
- 程式碼是否可讀取？
- 是否安全？
- 是否使用適當的第三方程式庫？
- 是否設有保護第三方程式庫的程序？
- 程式碼是否可組合？
- API 設計是否遵循最佳做法？
審查不應只是官僚程序，而是持續討論最佳做法的過程。針對技術堆疊的每個部分建立檢查清單、樣式指南和設計標準，並為新開發人員提供教育訓練計畫。部分 IDE (例如 VS Code 和 IntelliJ) 提供可自動標記程式或樣式錯誤的檢查工具。Lint 工具可協助開發人員建立更一致的程式碼，並讓程式碼審查人員更專注於自動檢查不易發現的問題。
開發安全軟體是 Open Source Security Foundation (OpenSSF) 建立的免費線上課程。本文將說明軟體供應鏈安全防護的基礎軟體開發實務。
只要個別開發人員準備就緒，即可使用功能分支提取要求執行程式碼審查。請勿等到新版本即將進入測試階段，才進行安全檢查和程式碼審查。
將安全漏洞掃描 (包括第三方程式庫掃描) 整合至提取要求和 IDE，有助於盡快找出問題。On-Demand Scanning API (位於 Google Cloud 中) 可讓您在本機掃描容器，找出安全漏洞。
整合合併前自動化測試，讓開發人員可以找出並修正會導致應用程式中斷的變更。進一步瞭解測試自動化。
合併核准
在持續整合的 CI/CD 管道中，將程式碼合併至實際工作環境分支可能會導致下游變更，包括自動建構和推出。因此，確保只有授權人員可以合併程式碼，是保護軟體部署作業的重要環節。要考量的事項包括：
- 在正式版分支上設定受保護的分支擁有者。允許合併的人數和身分應符合應用程式的安全需求。SLSA 第 4 級需要兩位經過嚴格驗證的核准者，但核准者人數應與存放區內容相符。
- 嚴格控管存放區擁有者的身分，因為在大多數版本控制系統中，他們可以自行執行合併作業。
- 針對多存放區和多構件推出作業，分別進行部署和合併核准程序。
確保開發安全無虞的工具
Google Cloud 提供一系列模組化功能和工具，可協助您提升軟體供應鏈的安全防護機制。下列元件有助於保護軟體原始碼：
Cloud Workstations (搶先版)
Cloud Workstations 提供Google Cloud全代管開發環境，IT 和安全防護管理員可以輕鬆佈建、調度資源、管理及保護開發環境，開發人員則能存取設定一致的開發環境，並使用可自訂的工具。
Cloud Workstations 可強化應用程式開發環境的安全防護機制，協助您將安全防護措施提前納入開發流程。這項服務提供多種安全防護功能，例如 VPC Service Controls、私人輸入或輸出、強制更新映像檔，以及 Identity and Access Management 存取權政策。詳情請參閱 Cloud Workstations 說明文件。
Cloud Code 來源保護 (搶先版)
Cloud Code 提供 IDE 支援，可透過 Google Cloud建立、部署及整合應用程式。開發人員可以透過這個工具，使用範本建立及自訂新應用程式，並執行完成的應用程式。開發人員在 IDE 中工作時，Cloud Code 來源保護功能會提供即時安全性意見回饋，例如識別易受攻擊的依附元件和授權報告。這項工具可提供快速且實用的意見回饋，讓開發人員在軟體開發流程初期就能修正程式碼。
功能支援情形：Cloud Code 來源保護功能不開放公開存取。如要使用這項功能，請參閱存取權要求頁面。
後續步驟
- 瞭解保護建構作業的最佳做法。
- 瞭解保護依附元件的最佳做法。
- 瞭解保護部署作業的最佳做法。