本文說明保護建構作業的最佳做法。建築代碼可指不同類型的作業，例如：
- 最佳化或混淆處理程式碼：舉例來說，Google 開放原始碼工具 Closure Compiler 會剖析及分析 JavaScript、移除無效程式碼，並重寫及縮減剩餘程式碼。此外，也會檢查程式碼中常見的 JavaScript 陷阱。
- 將程式碼編譯為中繼程式碼：舉例來說，您可以將 Java 程式碼編譯為 Java 類別檔案 (
.class)，或將 C++ 程式碼編譯為物件檔案 (.obj)。 - 編譯程式碼並連結，建立程式庫或可執行檔：例如，將 C++ 程式碼編譯成共用程式庫 (
.so) 或 Windows 可執行檔 (.exe)。 - 將程式碼封裝為可發布或部署的格式：例如從 Java 類別檔案建立 Java WAR (
.war) 檔案、建立 Docker 映像檔，或建立 Python 建構發布版本 (.whl)。
視您使用的程式設計語言和部署環境而定，建構作業可能包含這些作業的不同組合。舉例來說，建構作業可能會將 Python 程式碼封裝至建構的發布版本，並上傳至 Artifact Registry 或 PyPI 等構件存放區，以便在 Cloud Run 函式中做為依附元件使用。您也可以將 Python 程式碼容器化，然後將容器映像檔部署至 Cloud Run 或 Google Kubernetes Engine。
本文著重於建構程式碼，以便封裝或部署至執行階段環境，而非編譯程式碼。
使用自動建構功能
自動建構或指令碼建構會在建構指令碼或建構設定中定義所有建構步驟，包括擷取原始碼的步驟和建構程式碼的步驟。如果有的話，唯一的手動指令就是執行建構的指令。
舉例來說，建構指令碼可以是：
- Cloud Build
cloudbuild.yaml。 - 您使用
make工具執行的 Makefile。 - 以 YAML 格式儲存在
.github/workflows/目錄中的 GitHub Actions 工作流程檔案。
自動建構可確保建構步驟的一致性。不過，在一致且受信任的環境中執行建構作業也很重要。
雖然本機建構作業可用於偵錯，但從本機建構作業發布軟體可能會在建構程序中引發許多安全性問題、不一致和效率低落的情況。
- 允許本機建構會讓有惡意的攻擊者修改建構程序。
- 開發人員本機環境和做法不一致，導致難以重現建構作業和診斷建構問題。
手動建構會使用更多基礎架構資源 (例如運算、儲存空間和網路)，導致程序效率不彰。在 SLSA 架構的需求中，自動建構是 SLSA 第 1 級的要求，而使用建構服務而非開發人員環境進行建構，則是 SLSA 第 2 級的要求。
Cloud Build 是Google Cloud上的代管建構服務，它會使用建構設定檔，向 Cloud Build 提供建構步驟。您可以設定建構作業來擷取依附元件、執行單元測試、靜態分析和整合測試，並使用 Docker、Gradle、Maven、Go 和 Python 等建構工具建立構件。Cloud Build 與其他持續整合/持續推送軟體更新服務 (例如 Artifact Registry 和 Cloud Deploy) 完全整合，也與 GKE 和 Cloud Run 等執行階段環境整合。此外，Cloud Build 也與 GitHub 和 Bitbucket 等主要原始碼管理系統整合。Google Cloud
產生建構作業來源資訊
建構來源是一組可驗證的建構資料。
來源中繼資料包含建構映像檔的摘要、輸入來源位置、建構工具鍊和建構時長等詳細資料。
產生建構來源資訊有助於：
- 確認建構的構件是從受信任的來源位置建立，且是由受信任的建構系統建立。
- 找出從不受信任的來源位置或建構系統插入的程式碼。
您可以運用快訊和政策機制，主動使用建構出處資料。舉例來說，您可以建立政策，只允許部署從已驗證來源建構的程式碼。
對於 SLSA 第 1 級，建構來源必須提供給建構構件的消費者。如果是 SLSA 第 2 級，建構出處資料也必須：
- 由建構服務產生，或直接從建構服務讀取。
- 消費者可驗證真偽和完整性。這項作業應使用服務產生的數位簽章完成，該服務會建立建構出處資料。
如果是 SLSA 第 3 級，出處內容也必須包含：
- 建構定義的進入點。
- 使用者可控管所有建構參數。
Cloud Build 可為容器映像檔產生建構作業來源資訊，提供 SLSA 第 3 級建構保證。詳情請參閱「查看建構出處」。
使用暫時性建構環境
暫時性環境是臨時環境，只能在單一建構作業中存在。建構完成後，環境會遭到清除或刪除。 暫時性建構作業可確保建構服務和建構步驟在暫時性環境 (例如容器或 VM) 中執行。建構服務不會重複使用現有的建構環境，而是為每個建構作業佈建新環境，並在建構程序完成後毀損該環境。
臨時環境可確保建構作業乾淨無虞，因為不會有先前建構作業的殘餘檔案或環境設定干擾建構程序。非暫時性環境會讓攻擊者有機會注入惡意檔案和內容。臨時環境也能減少維護負擔，並降低建構環境中的不一致性。
Cloud Build 會為每個建構作業設定新的虛擬機器環境，並在建構作業完成後毀損該環境。
限制建構服務的存取權
請遵循最低權限安全原則，授予建構服務和建構資源所需的最低權限。您也應該使用非人為身分來執行建構作業，並代表建構作業與其他服務互動。
如果您使用 Cloud Build：
- 授予組織成員最低必要權限。
- 自訂代表 Cloud Build 執行的服務帳戶權限，確保該帳戶只具備您使用時所需的權限。編輯預設 Cloud Build 服務帳戶的權限，或考慮改用自訂服務帳戶。
- 使用 Cloud Build 允許的整合機構政策，控管允許叫用建構觸發程序的外部服務。
使用 VPC Service Controls 將 Cloud Build 納入服務範圍。在服務範圍內，服務之間可自由通訊，但跨範圍的通訊會受到限制，具體限制取決於您指定的規則。 Google Cloud 這個範圍也能降低資料竊取風險。
Cloud Build 僅支援在私人集區中執行的建構作業使用 VPC Service Controls。
保護憑證
建構作業通常會連結至其他系統，例如版本控管、構件商店和部署環境。保護您在建構作業中使用的憑證，有助於防止未經授權存取軟體供應鏈中的系統，以及資料外洩。
請避免直接在版本控管或建構設定中儲存硬式編碼的憑證。請改用安全金鑰儲存憑證。
在 Google Cloud中，Secret Manager 會安全地儲存 API 金鑰、密碼和其他機密資料。您可以設定 Cloud Build 使用儲存在 Secret Manager 中的密鑰。
管理依附元件
應用程式的完整性取決於您開發的程式碼和使用的依附元件是否完整。您也需要考慮要在何處發布依附元件、誰有權讀取及寫入構件存放區，以及要部署到執行階段環境的建構構件信任來源政策。
如要進一步瞭解如何管理依附元件，請參閱「管理依附元件」。
在 Cloud Build 中，您可以使用雲端建構工具執行指令。建構工具是安裝了一般語言與工具的容器映像檔。您可以使用公開登錄檔 (例如 Docker Hub) 中的公開容器映像檔、Cloud Build 提供的建構工具、社群提供的建構工具，以及您建立的自訂建構工具。您也可以使用建構包做為建構工具，包括 Google Cloud 的建構包。
查看 Cloud Build 建構作業中使用的建構工具、找出提供者，並決定是否信任軟體供應鏈中的建構工具。如要進一步控管建構工具中的程式碼，您可以建立自訂建構工具，而非使用公開來源的建構工具。
減少變更建構內容的機會
影響建構作業的因素有很多，包括：
- 並行執行且會相互影響的建構作業，或是持續存在並影響後續建構作業的建構作業。
- 接受使用者參數 (而非建構進入點和頂層來源位置) 的建構作業。
- 指定範圍的依附元件或可變更的依附元件 (例如使用
latest標記的映像檔) 的建構作業。這些方法會導致建構作業使用錯誤或不想要的依附元件版本，造成風險。
下列做法有助於降低這些風險：
- 在臨時環境中執行每個建構作業。
- 請避免使用額外參數執行建構作業，以免使用者影響建構指令碼中定義的變數。
- 限制建構服務和建構資源的存取權。
- 請參照依附元件的不可變更版本，而非標記等 ID，因為這些 ID 日後可能會指向不同版本的構件。如要進一步瞭解依附元件，請參閱「依附元件管理」。
軟體供應鏈安全性
Google Cloud 提供一系列模組化功能和工具，可協助您提升軟體供應鏈的安全防護機制。並顯示 Cloud Build 建構應用程式的安全洞察資訊。包括：
- SLSA 層級，可識別軟體供應鏈安全性的成熟度。
- 建構構件的安全漏洞、軟體物料清單 (SBOM) 和 Vulnerability Exploitability eXchange (VEX) 陳述式。
- 建構來源，這是指一組可驗證的建構中繼資料。包括建構的映像檔摘要、輸入來源位置、建構工具鍊、建構步驟和建構時長等詳細資料。
如要瞭解如何查看所建構應用程式的安全性深入分析資訊，請參閱「建構應用程式並查看安全性深入分析資訊」。
後續步驟
- 瞭解保護原始碼的最佳做法。
- 瞭解保護依附元件的最佳做法。
- 瞭解保護部署作業的最佳做法。