以安全的方式推送軟體

對機構而言，要建構軟體和應用程式來滿足客戶的需求，重點就是速度與上市時間。這些策略性要求是容器大幅成長，成為平台首選的驅動因素。過去一年來，機構藉助容器獲得許多優勢，包括縮短上市時間、降低成本，以及提高可用性、安全性和擴充性。現在，許多機構也開始考慮採用無伺服器方法。

雖然軟體解決方案縮短了推送新功能或甚至新產品的時間，但許多現有的安全性做法都無法跟上越來越快的推送速度，導致三個問題：

1. 現有作業程序拖慢開發人員的工作速度，導致延遲
2. 安全性和營運團隊做出妥協，讓機構遭受威脅
3. 開發團隊為了趕上期限，而以現有安全性程序因應，使開發作業產生安全漏洞

過去幾年來，出現了許多屬於「軟體供應鏈」攻擊的安全性漏洞。

Log4Shell 是在 2021 年 12 月，從 Apache Log4j 軟體中發現的危險安全漏洞。這個安全漏洞在 CVSS 評分標準中，危害程度經認定為最高等級 10 分，主要是因為 Log4j 是極為普及的 Java 式記錄架構。Log4Shell 會造成嚴重破壞的因素有二：首先，不肖人士能輕易利用這個安全漏洞，完全從遠端執行程式碼；第二，Log4j 通常處於多層依附元件樹狀結構，很容易遭到忽略。

IT 管理軟體公司 Solarwinds 受到國家級駭客攻擊，旗下所使用的開放原始碼軟體正式版本，都遭插入惡意程式碼。這項惡意更新隨後遭推送給 18,000 名客戶，其中包括美國財政部和商務部。

另一家 IT 管理軟體供應商 Kaseya 則遭受零時差安全漏洞攻擊。對方入侵 Kaseya VSA 伺服器並傳送惡意指令碼，推送勒索軟體來加密受影響系統上的所有檔案。

為了立即因應這些情況和其他類似事件，白宮於 2021 年 5 月發布行政命令，要求與聯邦政府有業務往來的機構必須維持一定的軟體安全性標準。

從許多方面來看，建立軟體供應鏈的程序與製造汽車的程序非常相似，以「軟體供應鏈」一詞形容軟體開發可說是恰如其分。

汽車製造商採購各種現成零件，並自行製造專屬元件，然後透過高度自動化的流程，全部組裝成一輛車。 製造商會確認每樣第三方元件採購自可信任的來源，同時 廣泛測試第一方元件，確保運作時安全無虞。 最後，製造商透過可信任的流程，將這些零件組裝成汽車。

軟體供應鏈在許多方面與汽車製造程序相似。 軟體製造商取得可執行特定功能的第三方元件 (通常屬於開放原始碼)，並開發自己的軟體，亦即其核心智慧財產。 隨後，軟體製造商透過建構程序執行程式碼，將這些元件合併成可部署的構件，再進一步部署到實際工作環境。

只要出現一個不安全的環節，就會危害軟體供應鏈。

與去年備受關注的攻擊事件一樣，程序中的每個步驟都可能變成遭攻擊者利用的弱點。

舉例來說，npm 套件平均有 12 個直接依附元件和大約 300 個間接依附元件。另外，我們發現在所有已發布的 npm 套件中，近 40% 套件所仰賴的程式碼包含已知安全漏洞。

存在安全漏洞不一定表示程式碼不安全，例如漏洞可能位在程式庫中從未實際使用的部分。不過，檢查這些漏洞仍屬必要。

這個問題的規模相當龐大。即使其中一個安全漏洞未修補，就可能讓不肖人士逮到機會入侵軟體供應鏈。

在過去數十年內，Google 持續建構全球規模的應用程式。我們長期下來提供許多內部專案做為開放原始碼，協助加快開發人員速度。同時，我們也開發各種內部處理程序，來確保軟體服務安全。

我們採取了以下措施，致力強化各種環境下的軟體供應鏈。

• 增加投資：我們在 2020 年 8 月宣布，將在未來五年內投入 $100 億美元來強化網路安全，包括擴大零信任計畫、協助保護軟體供應鏈，以及強化開放原始碼的安全性。
• 軟體構件供應鏈級別 (SLSA)：SLSA 為規範供應鏈完整性的端對端開放原始碼架構，與 Google 在內部導入的多種程序相等。SLSA 針對建構項目和方法提供了可稽核的依據。
• 開發運作研究與評估 (DORA)：我們 DORA 團隊為期七年的研究計畫已證實，許多技術、程序、評估、文化功能可以有效提升軟體推送及機構成效。
• 開放原始碼安全性基金會 (Open Source Security Foundation)：我們在 2019 年與多家企業共同創立開放原始碼安全性基金會，這是以保護供應鏈安全性為宗旨的跨產業論壇。
• Allstar：Allstar 是安裝在機構或存放區中的 GitHub 應用程式，用於設定並強制執行安全性政策。這項應用程式可持續強制執行最佳安全性做法，以保護 GitHub 專案。
• 開放原始碼評量表：評量表使用模糊和靜態程式碼分析工具，根據各項指標 (例如定義明確的安全性政策、程式碼審查程序、持續測試涵蓋率)，針對開放原始碼專案的風險程度給予評分。

我們認為下列兩點對克服軟體供應鏈安全性問題相當重要：

1. 業界標準和架構。
2. 採用最小權限原則導入這些標準的代管服務稱為零信任架構。在零信任架構中，所有人員、裝置或網路都必須取得系統信任才能存取資訊，無法透過繼承方式運作。

讓我們逐一探討以上兩點：

目前 SLSA 是匯集業界共識而制定出的一套安全準則，可逐步採用。就強制性而言，SLSA 的最終形式與最佳做法清單不同：SLSA 支援自動建立可稽核的中繼資料，並將其傳送至政策引擎，進而提供「SLSA 認證」給特定套件或建構平台。

SLSA 的漸進式標準可做為行動依據，在每個步驟都能保障安全。一旦構件達到最高等級，客戶即可確定構件未遭到竄改，並安全地回溯來源。這是現今大部分軟體難以、甚至是不可能做到的一點。

SLSA 涵蓋四個等級，其中 SLSA 4 代表最理想的狀態。SLSA 4 以下等級屬於漸進式標準，每個標準等級都有相應的完整性防護保證。各等級的要求標準如下：

SLSA 1 要求建構程序必須完全採取指令碼/自動化作業，並產生來源。來源是構件的建構方式中繼資料，其中包含建構程序、頂層來源和依附元件。掌握來源後，軟體客戶就能依據風險做出相關安全性決策。雖然 SLSA 1 的來源無法防範竄改，但可用於進行基本的程式碼原始碼識別，有助於管理安全漏洞。

SLSA 2 要求採用版本管控，而且使用的託管建構服務應產生經過驗證的來源。這些額外要求可讓客戶對軟體來源更安心。這個等級的來源可進一步防止受信任的建構服務遭竄改。此外，SLSA 2 也提供簡單的升級路徑，讓軟體構件安全性輕鬆升級到 SLSA 3。

SLSA 3 進一步要求原始碼和建構平台符合特定標準，以分別保證原始碼的可稽核性，以及來源的完整性。SLSA 3 可防範特定類別的威脅 (例如跨建構程序的汙染情形)，防止竄改的效果優於前兩個等級，提供更強大的保護。

SLSA 4 要求雙人審查所有變更，並採取可重現的密封建構程序，是目前最高的完整性保證等級。雙人審查是發現錯誤並防止不良行為的業界最佳做法，密封建構程序則可保證來源具有完整的依附元件清單。可重現的建構程序雖然不是強制要求，但有助於提升可稽核性及可靠性。整體來看，SLSA 4 能讓客戶充分放心，相信軟體未遭竄改。您可以前往 GitHub 存放區參閱以上建議等級的詳細資料，其中包括相應原始碼和建構程序/來源要求。

軟體供應鏈可細分為五個不同階段：程式碼、建構、套件、部署和執行。接下來，我們會逐一說明各階段的安全性做法。

Google Cloud 提供的全代管工具涵蓋程式碼、建構、部署和執行階段，且預設採用上述標準和最佳做法。

要保護軟體供應鏈安全，就必須建立、驗證及維護信任鏈，藉此確立程式碼來源，並確保在實際工作環境中執行的項目符合預期。為了做到這點，Google 在整個軟體開發和部署過程中產生及檢查認證，藉由程式碼審查、驗證程式碼來源、強制執行政策等，確保環境達到一定程度的安全性。我們結合這些程序，將軟體供應鏈風險降到最低，同時提高開發人員工作效率。

我們透過身分與存取權管理、稽核記錄等常見安全基礎架構服務，提供基本安全性。接下來，我們會在軟體生命週期中，全程定義、檢查並強制執行認證，以保障軟體供應鏈安全。

現在讓我們進一步瞭解，如何透過 Google Cloud 的政策和來源，在開發過程中實現環境安全性。

從開發人員著手設計應用程式及編寫程式碼時，就要開始保護軟體供應鏈安全。 不論是第一方軟體或開放原始碼元件，都會面臨安全性挑戰。

開放原始碼軟體和依附元件

開放原始碼能協助開發人員加快建構速度，進而提高機構的應變能力和效率。 不過，開放原始碼軟體終究不是完美無缺。雖然業界相當仰賴這類軟體，我們卻未深入瞭解其依附元件，以及伴隨的風險等級。 對大多數企業而言，風險主要來自安全漏洞或授權。

開放原始碼軟體、套件、基本映像檔，以及您仰賴的其他構件，構成了「信任鏈」的基礎。

舉例來說，假設貴機構正在建構軟體「a」。上圖顯示的相關信任鏈，也就是專案隱含的依附元件數量。在圖表中，「b」到「h」是直接依附元件，「i」到「m」是間接依附元件。

現在，如果這個相依元件樹狀結構的深處有個安全漏洞，那麼許多元件可能很快就會發生問題。此外，依附元件的變更頻率相當高，每天平均有 40,000 個 npm 套件的依附元件發生變更。

Open Source Insights 是由 Google Cloud 建構的工具，可提供轉換依附關係圖，讓您透過依附元件樹狀結構，查看所有依附元件及其完整依附關係。Open Source Insights 會持續更新，並集中提供安全性建議、授權資訊和其他多種語言的安全性資料。您可以將 Open Source Insights 搭配開放原始碼評量表使用，為開放原始碼專案給予風險分數，協助開發人員從數百萬個開放原始碼套件中做出更明智的選擇。

要解決這個問題，就必須將依附元件視為與程式碼一樣重要。越是把依附元件放在供應鏈底端，檢查難度就越高。為確保您的依附元件安全無虞，我們建議從供應面著手：

• 使用 Open Source Insights 和 OSS 評量表等工具，進一步瞭解您的依附元件。
• 透過自動化程序掃描並驗證所有程式碼、套件和基本映像檔，這是工作流程中重要的一環。
• 控管人員存取依附元件的方式。請務必嚴格控管第一方程式碼和開放原始碼存放區，並針對整個程式碼審查和稽核要求設下限制。

稍後，我們會進一步探討建構和部署程序。另外，其他同樣重要的做法包括驗證建構來源、採用安全建構環境，以及在部署時確認映像檔經過簽署並隨後通過驗證。

開發人員也可以部署以下幾種安全的程式設計方法：

• 自動測試
• 使用可保護記憶體安全的軟體語言
• 委託書程式碼審查
• 確保修訂版本的真實性
• 及早發現惡意程式碼
• 避免公開機密資訊
• 要求記錄並建構輸出內容
• 善用授權管理功能

保護軟體供應鏈安全的下一步，是大規模建立安全的建構環境。基本上，建構程序的第一步是從存放區匯入任一種語言的原始碼，並依據設定檔中的規格執行建構作業。

Google 等雲端服務供應商可提供最新的代管建構環境，讓您視需求建構任何規模的映像檔。

在建構過程中，請思考以下幾點：

• 您的密鑰在建構程序期間與之後是否安全？
• 誰能存取建構環境？
• 新型攻擊向量或竊取風險造成的影響如何？

要打造安全的建構環境，必須從密鑰著手。密鑰相當重要，而且較容易維護安全。首先，請確保密鑰一律不是明文，而且盡可能不納入建構作業的一部分。務必確認密鑰已加密，並將建構作業參數化，以視需要使用及參照外部密鑰。這麼做也可以簡化密鑰的定期輪替作業，將任何外洩情形的影響降到最低。

下一步是設定建構作業的權限。建構程序涉及不同的使用者和服務帳戶。例如部分使用者必須能管理 Secret，其他使用者則必須能加入或修改步驟來管理建構程序，或是必須檢閱記錄檔。

設定權限時，請務必遵循以下最佳做法：

• 遵照最小權限原則至關重要。請導入精細的權限，讓使用者和服務帳戶取得有效完成工作所需的精確權限。
• 您必須知道使用者與服務帳戶的互動方式，並清楚瞭解建構作業從設定、執行，到下游影響力的責任鏈。

接下來，請在擴充這項程序時，盡可能界定建構作業範圍，然後透過將設定視為程式碼和參數化的方法，使用自動化程序向上擴充。這樣一來，您即可有效率地稽核建構程序的任何變更。此外，請針對敏感的建構和部署作業設下核准閘道、設定基礎架構變更的提取要求，並定期進行稽核記錄的人工審查，以符合法規要求。

最後，請確認網路符合您的需求。在大多數情況下，最好將您自己的原始碼託管在設下防火牆的私人網路中。您可以運用 Google Cloud 的 Cloud Build 私人集區功能，在私人網路範圍內建立鎖定的無伺服器建構環境，或是運用 VPC Service Controls 功能，防止您的智慧財產遭竊。

二進位授權

雖然身分與存取權管理 (IAM) 是必要機制，也是合理的防護起點，但並不能保證萬無一失。一旦憑證出現漏洞，就會面臨重大安全性風險。因此，您可以轉換至較不易出錯的認證型系統，以降低對 IAM 的依賴。Google 使用的是二進位授權系統，只會允許部署受信任的工作負載。

二進位授權服務會全程透過認證和政策檢查，協助建立、驗證並維護信任鏈。具體來看，二進位授權會在程式碼或其他構件進入實際工作環境時產生加密編譯簽章 (認證)，然後在部署前檢查這些認證是否符合政策。

使用 Google Cloud Build 時，系統會擷取一組認證並加入整個信任鏈。例如系統會為執行的任務、使用的建構工具和程序等產生認證。值得注意的是，Cloud Build 能擷取建構設定原始碼來驗證建構作業是以指令碼編寫而成，有助於您達成 SLSA 等級 1。與手動設定的建構作業相比，以指令碼編寫的安全性更高，而且符合 SLSA 等級 1 的要求。此外，您可以使用容器映像檔摘要，為任何映像檔建立唯一簽章，藉此查詢建構作業的來源及其他認證。這也是符合 SLSA 等級 1 要求的做法。

建構完成後，您就會得到可隨時用於實際工作環境的容器映像檔。 請務必將映像檔儲存在安全位置，以防他人竄改現有映像檔及上傳未經授權的映像檔。 套件管理員可能必須具備第一方程式碼和開放原始碼建構作業的映像檔，以及應用程式所使用的語言套件。

Google Cloud 的 Artifact Registry 可為您提供這類存放區。Artifact Registry 讓機構能集中管理容器映像檔和語言套件 (例如 Maven 和 npm)。 這項服務與其他 Google Cloud 工具和執行階段完全整合，並支援原生構件通訊協定。 您可以輕鬆將這項服務與 CI/CD 工具相互整合，設定自動化管道。

與建構步驟類似，您必須遵循最低權限原則，妥善設定 Artifact Registry 的存取權限。 這麼做除了能限制未經授權的存取之外，也能讓套件存放區發揮更大效用。 例如 Artifact Registry 會透過安全漏洞掃描功能，確認映像檔可以安全部署。安全漏洞資料庫會不斷重新整理及更新，這項服務據此掃描映像檔以評估新威脅，並在發現安全漏洞時傳送快訊。

這個階段產生的額外中繼資料包括一項驗證，用於證明構件的安全漏洞掃描結果是否符合特定安全性門檻。這項資訊隨後會儲存至我們的分析服務，服務將彙整構件的中繼資料並分析結構，以便用於二進位授權。 這項服務可以自動防止將有風險的映像檔部署到 Google Kubernetes Engine (GKE)。

軟體安全性供應鏈的最後兩個階段是部署和執行。雖然這兩個步驟各自獨立，但建議您一併思考這些步驟，確保只有已授權的建構作業可以進入實際工作環境。

Google 制定了一套最佳做法，來協助判斷哪些類型的建構作業應獲得授權。首先，請確保供應鏈完整性，讓供應鏈只會產生您可以信任的構件。接下來，將安全漏洞管理納入軟體推送生命週期的一環。最後，我們結合這兩個步驟，強制系統根據完整性和安全漏洞掃描政策執行工作流程。

進入這個階段，代表您已經過程式碼、建構和套件階段，可以針對您沿著供應鏈路徑擷取到的認證，透過二進位授權驗證真實性。在強制執行模式下，系統只會在認證符合機構政策時部署映像檔。如果在稽核模式下，系統會記錄違反政策情形，並觸發快訊。您也可以使用二進位授權，限制執行版本，除非版本是由經認可的 Cloud Build 程序建構而成。二進位授權可確保部署的程式碼一律經過確實審查及授權。

將映像檔部署至受信任的執行階段環境至關重要。我們的代管型 Kubernetes 平台「GKE」，會採取安全性優先的做法來處理容器。

GKE 能妥善處理您必須留意的許多叢集安全性問題。自動叢集升級功能則可讓您使用發布版本，自動修補及更新 Kubernetes。安全啟動、受防護的節點和完整性檢查，可確保節點的核心和叢集元件未經修改且正在執行所需設定，讓惡意節點無法加入您的叢集。最後，機密運算功能可讓您以記憶體加密的節點執行叢集，因此即使資料正在處理中，也能維持機密性。此外，GKE 能為靜態和透過網路傳輸的資料加密。有了 GKE，您即可在安全的私人機密環境執行容器化工作負載。

不僅如此，GKE 還可透過負載平衡器的憑證管理、Workload Identity 和進階網路功能，提高應用程式安全性，並運用強大功能設定及保護輸入叢集的 ingress。同時，GKE 也提供沙箱機制環境，讓您執行不受信任的應用程式時，仍可保護其餘工作負載。

GKE Autopilot 可自動導入 GKE 的最佳安全性做法和功能，進一步縮小受攻擊面，以及減少可能造成安全性問題的錯誤設定。

當然，即使在部署階段也必須繼續進行驗證。二進位授權服務也支援持續驗證，能確保應用程式經過部署後繼續遵循定義的政策。如果執行中的應用程式不符合現有或新加入的政策，系統會建立並記錄相關快訊，這樣您就能確保在實際工作環境中執行的應用程式都符合政策。

安全漏洞管理

除了確保完整性，另一個保障供應鏈安全的層面是，確保迅速發現並修補安全漏洞。攻擊者已改進手法，能夠主動將安全漏洞插入上游專案。因此，在軟體推送生命週期的所有階段中，都必須管理安全漏洞及偵測瑕疵。

一旦程式碼可供部署，請使用 CI/CD 管道，並藉助多種工具完整掃描原始碼及產生的構件。這些工具包括靜態分析工具、模糊工具和各種安全漏洞掃描工具。

當工作負載部署至實際工作環境，開始運作並為使用者提供服務後，您就必須監控新興威脅，並規劃即時補救措施。

結論

總而言之，要保護軟體供應鏈安全，必須採用 SLSA 等最佳做法，並透過受信任的代管服務執行這些最佳做法。

重點包括：

• 首先，確保程式碼和依附元件可信任。
• 保護建構系統，並使用認證來確認建構作業遵循所有必要步驟。
• 確認所有套件和構件都受到信任，而且無法遭竄改。
• 強制執行控管機制，控管誰可以部署什麼，並維護稽核追蹤記錄。使用二進位授權，驗證要部署的每個構件認證。
• 在受信任的環境執行應用程式，確保應用程式完全不會在執行期間遭到竄改。隨時留意任何新發現的安全漏洞，以便保護部署作業。

Google 將這個歷程中每個步驟的最佳做法，導入我們的產品組合，讓您擁有值得信賴的建構基礎。

準備開始保護軟體供應鏈了嗎？其實，無論從哪裡著手都可以。這是因為，僅憑一項行動不足以保護整個供應鏈，而且就整體供應鏈安全而言，每項行動的重要性不分高低。話雖如此，您還是可以參考以下四個入門建議。

1. 修補軟體

如果部署至實際工作環境的程式碼有已知安全漏洞，您等於為攻擊者敞開大門。這時因為攻擊者已取得可趁之機，再怎麼妥善保護軟體供應鏈都沒用。結論是，修補程式碼才是重點。

2. 控管正在環境中執行的程式碼

完成修補後，您會想控管軟體供應鏈本身。首先，您必須能宣告目前執行的程式碼確實來自建構工具或受信任的存放區。這種程度的控管有助於防止刻意攻擊和意外錯誤，例如開發人員未發現部署的項目不安全。這麼做能奠定穩固的基礎，讓您進一步加入點擊測試、二進位授權等工具。

3. 確保第三方廠商套件安全無虞

第三方廠商軟體遭入侵的頻率漸增，成為新的供應鏈安全性問題。這使不肖人士能在未經授權的情況下存取目標客戶部署作業，甚至使用勒索軟體加以攻擊。您在環境中執行的第三方廠商套件 (例如系統管理產品、網路管理產品、安全性產品) 通常擁有高權限。因此，建議您要求這些廠商採取比樣板安全性聲明更高的防護措施，為您使用的套件提供一定程度的安全性保證。您可以詢問對方符合哪個 SLSA 等級，或是否為近期白宮行政命令的規範對象。

4. 取得原始碼的私人副本

如果您使用的是開放原始碼軟體，請勿使用直接從網際網路提取的版本來進行建構。請改為使用可持續修補的私人副本，這樣即可讓每個建構作業都有乾淨的起點，而且能完全掌握原始碼出處。

開發運作最佳做法

1. 六年《開發運作現狀報告》：這系列文章深入探討軟體推送效能的預測功能，並能快速檢驗您的現狀及建議改善方式。
2. Google Cloud 2021 年加速發展：開發運作現狀報告
3. Google Cloud 白皮書：以雲端原生方式重新建立架構：這是大規模提高開發人員生產力的革命性方法

保護軟體供應鏈

1. Google Cloud 網誌：什麼是零信任身分識別安全機制
2. Google 安全性網誌：隆重推出 SLSA，這是一種供應鏈完整性的端對端架構
3. Google Cloud 白皮書：改用安全機制：確保軟體供應鏈安全無虞