依附元件管理

本文說明應用程式依附元件，以及管理這些依附元件的最佳做法，包括監控漏洞、驗證構件、減少依附元件足跡，以及支援可重現的建構作業。

軟體依附元件是指應用程式運作所需的軟體，例如軟體程式庫或外掛程式。您在編譯程式碼、建構、執行、下載或安裝軟體時，可能會解析依附元件。

依附元件可能包括您建立的元件、專屬第三方軟體和開放原始碼軟體。您管理依附元件的方式可能會影響應用程式的安全性和可靠性。

導入最佳做法的具體做法可能因構件格式和使用的工具而異，但一般原則仍適用。

直接和遞移依附元件

您的應用程式可以同時包含直接和遞移依附元件：

直接依附元件
應用程式直接參照的軟體元件。
遞移依附元件
應用程式的直接依附元件在功能上需要使用的軟體元件。每個依附元件都可以有自己的直接和間接依附元件，進而建立遞迴的遞移依附元件樹狀結構，這些依附元件都會影響應用程式。

不同的程式設計語言提供的依附元件及其關係可見度層級不同。此外，部分語言會在安裝或部署套件時，使用套件管理員來解析依附元件樹狀結構。

在 Node.js 生態系統中，npm 和 yarn 套件管理工具會使用鎖定檔案，識別用於建構模組的依附元件版本，以及套件管理工具為特定模組安裝作業下載的依附元件版本。在 Java 等其他語言生態系統中，對依附元件內省的支援較為有限。此外，建構系統必須使用特定依附元件管理工具，有系統地管理依附元件。

舉例來說，假設 npm 模組 glob 的版本為 8.0.2。您可以在 package.json 檔案中宣告 npm 模組的直接依附元件。在 glob 的 package.json 檔案中，dependencies 區段會列出已發布套件的直接依附元件。devDepdencies 區段列出維護人員和貢獻者在 glob 中進行本機開發和測試時的依附元件

  • 在 npm 網站上，glob 頁面會列出直接依附元件和開發依附元件，但不會指出這些模組是否也有自己的依附元件。

  • 如要進一步瞭解 glob 的依附元件，請前往 Open Source Insights 網站。glob 的依附元件清單包含直接和間接 (遞移) 依附元件。

    遞移性依附元件可能位於依附元件樹狀結構的深處。 例如：

    1. glob 8.0.2 直接依附於 minimatch 5.0.1。
    2. minimatch 5.0.1 具有直接依附元件 brace-expression 2.0.1。
    3. brace-expression 2.0.1 直接依附於 balanced-match 1.0.2。

如果無法查看間接依附元件，就很難找出並解決源自程式碼未直接參照元件的安全性漏洞和其他問題。

安裝 glob 套件時，npm 會解析整個依附元件樹狀結構，並將下載的特定版本清單儲存到 package.lock.json 檔案，方便您記錄所有依附元件。在相同環境中後續安裝時，系統會擷取相同版本。

依附元件洞察工具

您可以使用下列工具瞭解開放原始碼依附元件，並評估專案的安全防護機制。這些工具會提供各種套件格式的資訊。

Google Cloud 控制台中的安全性洞察資料
Google Cloud 可提供 Cloud Build、Cloud Run 和 GKE 中構件的安全洞察，包括安全漏洞、依附元件資訊、軟體物料清單 (SBOM) 和建構出處。其他 Google Cloud 服務也提供相關功能，可提升整個軟體開發生命週期的安全防護機制。詳情請參閱軟體供應鏈安全性總覽。
開放原始碼工具

您可以使用多種開放原始碼工具，包括：

  • Open Source Insights：這個網站提供已知直接和間接依附元件、已知安全漏洞，以及開放原始碼軟體的授權資訊。開放原始碼洞察專案也會以Google Cloud 資料集的形式提供這項資料。您可以使用 BigQuery 探索及分析資料。

  • 開放原始碼安全漏洞資料庫：可搜尋的安全漏洞資料庫，會將其他資料庫的安全漏洞匯總到一個位置。

  • 評量表：自動化工具，可協助您找出 GitHub 專案中具有風險的軟體供應鏈做法。並針對存放區執行檢查，為每項檢查評分 (0 到 10 分)。然後使用這些分數評估專案的安全狀態。

  • Allstar：這項 GitHub 應用程式會持續監控 GitHub 機構或存放區，確保符合設定的政策。舉例來說，您可以對 GitHub 機構套用政策，檢查是否有機構外部的協作者具備管理員或推送存取權。

納入依附元件的方法

將依附元件納入應用程式的常見方法有幾種：

直接從公開來源安裝
直接從公開存放區 (例如 Docker Hub、npm、PyPI 或 Maven Central) 安裝開放原始碼依附元件。這種做法很方便，因為您不需要維護外部依附元件。不過，由於您無法控管這些外部依附元件，軟體供應鏈更容易遭受開放原始碼供應鏈攻擊。
將依附元件副本儲存在原始碼存放區中
這種做法也稱為「供應商化」。您不必在建構期間從公開存放區安裝外部依附元件，而是下載並複製到專案來源樹狀結構中。您可以進一步控管使用的供應商依附元件，但有幾項缺點：
  • 供應商提供的依附元件會增加來源存放區的大小，並導致更多流失。
  • 您必須將相同的依附元件提供給每個個別應用程式。如果來源存放區或建構程序不支援可重複使用的來源模組，您可能需要維護多個依附元件副本。
  • 升級供應商依附元件可能較為困難。
將依附元件儲存在私人登錄檔中

私有登錄檔 (例如 Artifact Registry) 不僅提供從公開存放區安裝的便利性，還能控管依附元件。Artifact Registry 的優點如下：

  • 集中管理所有應用程式的建構構件和依附元件。
  • 設定 Docker 和語言套件用戶端，與 Artifact Registry 中的私人存放區互動，就像與公開存放區互動一樣。

  • 進一步控管私人存放區中的依附元件：

    • 使用 Identity and Access Management 限制每個存放區的存取權。
    • 使用遠端存放區，從上游公開來源快取依附元件，並掃描這些依附元件的安全性漏洞 (私人搶先體驗版)。
    • 使用虛擬存放區，將遠端和私人存放區分組，為每個存放區設定優先順序，以便在下載或安裝構件時控管搜尋順序 (私人搶先體驗版)。

  • 將 Artifact Registry 與其他 Google Cloud 服務搭配使用，包括 Cloud Build、Cloud Run 和 Google Kubernetes Engine。在軟體開發生命週期中自動掃描是否有安全性漏洞、產生建構出處、控管部署作業，以及查看安全性狀態的洞察資訊。

請盡可能使用私人註冊資料庫管理依附元件。如果無法使用私人登錄檔，請考慮供應商提供的依附元件，以便控管軟體供應鏈中的內容。

固定版本

版本固定是指將應用程式依附元件限制在特定版本或版本範圍內。理想情況下，您會釘選單一版本的依附元件。

固定依附元件版本有助於確保應用程式建構作業可重現。但這也表示建構作業不會包含依附元件的更新，包括安全性修正、錯誤修正或改善項目。

如要緩解這個問題，可以使用自動化依附元件管理工具，監控來源存放區中的依附元件是否有新版本。這些工具會更新需求檔案，視需要升級依附元件，通常還會提供變更記錄資訊或其他詳細資料。

版本固定只適用於直接依附元件，不適用於遞移依附元件。舉例來說，如果您釘選套件版本 my-library，釘選會限制 my-library 的版本，但不會限制 my-library 具有依附元件的軟體版本。在部分語言中，您可以使用鎖定檔案，限制套件的依附元件樹狀結構。

驗證簽章和雜湊

您可以使用多種方法，驗證做為依附元件的構件是否為正版。

雜湊驗證

雜湊是系統為檔案產生的值，可做為專屬 ID。 您可以比較構件的雜湊值與構件供應商計算的雜湊值，確認檔案完整性。透過雜湊驗證，您可以識別依附元件是否遭到替換、竄改或損毀，例如透過中間人攻擊或構件存放區遭入侵。

使用雜湊驗證時，您必須信任從構件存放區收到的雜湊未遭入侵。

驗證簽章

簽章驗證可為驗證程序增添額外安全性。 軟體維護人員和/或構件存放區可以簽署構件。

維護人員可透過 sigstore 等服務簽署軟體構件，消費者則可驗證這些簽章。

二進位授權可驗證部署至 Google Cloud 執行階段環境的容器映像檔是否已簽署各種條件的認證。

鎖定檔案和已編譯的依附元件

鎖定檔案是完全解析的需求檔案，可準確指定應用程式應安裝的各項依附元件版本。鎖定檔通常由安裝工具自動產生，會結合版本固定和簽章/雜湊驗證，以及應用程式的完整依附元件樹狀結構。

安裝工具會完整解析頂層依附元件的所有下游轉換依附元件，藉此建立依附元件樹狀結構，然後將依附元件樹狀結構納入鎖定檔案。因此只能安裝這些依附元件，讓建構作業更具重現性及一致性。

混合使用私人和公開依附元件

現代的雲端原生應用程式通常會同時仰賴開放原始碼、第三方程式碼，以及封閉原始碼的內部程式庫。Artifact Registry 可讓您在多個應用程式之間共用業務邏輯，並重複使用相同的工具安裝外部和內部程式庫。

不過，如果混用私有和公開依附元件，軟體供應鏈就更容易受到依附元件混淆攻擊。如果發布的專案與內部專案同名，攻擊者可能會利用設定錯誤的安裝程式，安裝自己的惡意程式碼，而非內部依附元件。

如要避免依附元件混淆攻擊，可以採取下列措施：

  • 將依附元件納入鎖定檔案，驗證依附元件的簽章或雜湊。
  • 將第三方依附元件和內部依附元件的安裝作業分成兩個不同的步驟。
  • 將所需的第三方依附元件明確鏡像到私人存放區，可手動或透過提取式 Proxy 進行。Artifact Registry 遠端存放區是上游公開存放區的提取式 Proxy。
  • 使用虛擬存放區，將遠端和標準 Artifact Registry 存放區整合至單一端點。您可以設定上游存放區的優先順序，確保系統一律優先使用同名公開構件，而非私人構件版本。
  • 使用可信來源的公開套件和基礎映像檔。

移除未使用的依附元件

隨著需求改變和應用程式演進，您可能會變更或停止使用部分依附元件。繼續為應用程式安裝未使用的依附元件，會增加依附元件的足跡，並提高您因這些依附元件中的安全漏洞而遭入侵的風險。

應用程式在本機運作後，常見做法是將開發期間安裝的所有依附元件，複製到應用程式的 requirements 檔案中。然後部署應用程式和所有這些依附元件。這個方法有助於確保部署的應用程式正常運作，但也很可能導入您在正式環境中不需要的依附元件。

在應用程式中新增依附元件時，請務必謹慎。每個依附元件都可能導入更多您無法完全掌控的程式碼。在例行 Linting 和測試管道中，整合稽核需求檔案的工具，判斷您是否實際使用或匯入依附元件。

部分語言提供工具，協助您管理依附元件。舉例來說，您可以使用 Maven Dependency 外掛程式來分析及管理 Java 依附元件。

安全漏洞掃描

快速回應依附元件中的安全漏洞，有助於保護軟體供應鏈。

您可以透過安全漏洞掃描，自動且持續評估依附元件是否會將安全漏洞帶入應用程式。安全漏洞掃描工具會使用鎖定檔案，準確判斷您依賴的構件，並在出現新的安全漏洞時通知您，有時甚至會建議升級路徑。

舉例來說，Artifact Analysis 可找出容器映像檔中的作業系統套件安全漏洞。這項功能會在映像檔上傳至 Artifact Registry 時掃描映像檔，並在映像檔推送後持續監控最多 30 天，以找出新的安全漏洞。

您也可以使用隨選掃描功能，在本機掃描容器映像檔的 OS、Go 和 Java 安全漏洞。這有助於您及早找出安全漏洞，並在將映像檔儲存在 Artifact Registry 之前解決問題。

後續步驟