2026 年每日通報的 CVE 數量比前一年多 131%。

供應鏈

什麼是軟體供應鏈安全?

軟體供應鏈安全是保護軟體在送達使用者之前所包含的一切:開源套件、建置系統、管線中的工具,以及版本發布本身。攻擊者越來越常鎖定這些環節,而不是您的應用程式,因為只要一個套件或建置步驟遭入侵,就能波及所有使用它的產品。

更新日期

什麼是軟體供應鏈?

軟體供應鏈涵蓋讓軟體從開發者的編輯器走到正式環境的所有人與所有事物。可以將它分為四個階段,每個階段都有各自的風險。

階段 包含什麼 可能出什麼問題
原始碼 您的程式碼、儲存庫與開發者帳戶 憑證遭竊、惡意 commit、機密外洩
相依套件 開源套件、基礎映像檔、第三方程式碼 有漏洞的版本、惡意版本、錯字搶註套件
建置 CI 執行器、GitHub Actions、建置工具、快取 遭入侵的 actions、遭汙染的快取、管線機密遭竊
版本發布 建置產物、registry、部署、更新 建置產物遭調包、更新遭竄改、沒有出貨內容的紀錄

為什麼現在格外重要

您出貨的內容大多不是您寫的。現代應用程式主要由開源軟體組成,而每個直接相依套件又會帶進團隊中沒人選擇過的其他套件。這些套件擁有與您自己的程式碼相同的存取權限,它們的安裝腳本還可能在您的 CI 管線中、就在您的機密旁邊執行。

過去幾年的事件顯示了這一點如何被利用:

  • SolarWinds:建置遭入侵,因此乾淨的原始碼樹產出了遭汙染的版本。
  • Log4Shell:一個日誌函式庫的缺陷,波及了根本不知道自己使用它的產品。
  • xz utils:一名受信任的貢獻者在 Linux 發行版中所使用的專案裡植入了後門。
  • tj-actions:一個遭挾持的 GitHub Action 在使用它的管線中執行攻擊者的程式碼,機密就在可觸及的範圍內。
  • Shai-Hulud:一隻蠕蟲透過 npm 套件散播,從安裝這些套件的電腦與 CI 作業中竊取權杖。

若想逐步了解這些攻擊如何運作,請參閱什麼是供應鏈攻擊。

軟體供應鏈安全如何運作

一套計畫需要四件事,其餘都是細節。

  1. 掌握您出貨的內容。為每個版本保留一份來自產出該版本之建置的準確 SBOM,並包含遞移相依套件。
  2. 控管進入的內容。固定版本、使用鎖定檔(lockfile)、限制建置可以從哪裡擷取內容,並審查新套件。
  3. 保護建置。隔離作業、限制機密、以 commit 固定 actions,並限制對外流量,讓遭入侵的套件無法把您的權杖送到任何地方。請參閱 執行器安全與 為何供應鏈安全應該在 CI 中落實。
  4. 持續關注已出貨的內容。新的漏洞會影響已在正式環境中執行的軟體。請持續監控、追溯受影響的版本,並追蹤每個修正直到新版本發布。

詳細的檢查清單請參閱 軟體供應鏈安全最佳實務。

框架與法規

名稱 內容 最適合
SLSA 建置完整性與來源證明的等級 強化軟體的建置方式
NIST SSDF 安全開發實務,SP 800-218 完整的安全開發計畫
NIST SP 800-161 網路安全供應鏈風險管理 全組織的風險管理
OpenSSF Scorecard 自動檢查開源專案的健全度 審查相依套件
Cyber Resilience Act(CRA) 規範具數位元素產品的歐盟法規 在歐盟銷售。請參閱什麼是 CRA

涉及哪些工具?

沒有任何單一產品能涵蓋所有面向。這個類別可細分為 SCA 工具、SBOM 工具、CI/CD 與執行器安全、套件防火牆、應用程式資安態勢管理,以及二進位分析。各類工具的功能與供應廠商,請參閱軟體供應鏈安全工具比較與 它們的費用。

從哪裡開始

  1. 從您最重要產品的 CI 建置產生一份 SBOM,並實際閱讀它。
  2. 開啟相依套件漏洞警示,並決定由誰負責處理。
  3. 以 commit 固定您的 GitHub Actions,並檢視您的工作流程能存取哪些機密。
  4. 將建置的對外流量限制在它們實際需要的主機。
  5. 為已出貨的內容建立監控,而不只是正在建置的內容。

CRACI 的做法

CRACI 從建置著手,因為建置是唯一能看見一切的地方。它以更快、成本更低的執行器取代您的 GitHub 託管執行器,記錄每個作業擷取的每個套件,涵蓋相依樹的每一層,也包括從 CI 快取還原的套件。對外連線政策會封鎖建置不需要的連線,因此即使面對前所未見的攻擊也能保護您。CRACI 接著會持續將已出貨的內容與新漏洞比對,並追蹤每個漏洞從分級研判到修正版本發布的全過程。請參閱 CRACI 的軟體供應鏈安全。

軟體供應鏈安全:常見問題

什麼是軟體供應鏈安全?

它是保護軟體在送達使用者之前所包含之一切的做法:開源相依套件、建置系統、管線工具與版本發布。

軟體供應鏈攻擊有哪些例子?

在 SolarWinds 攻擊中,建置遭入侵,因此客戶從受信任的廠商收到了遭汙染的更新。在 Shai-Hulud 攻擊中,一隻蠕蟲透過 npm 套件散播,並從安裝這些套件的電腦竊取權杖。

供應鏈安全與應用程式安全有什麼不同?

應用程式安全關注的是您所寫程式碼中的缺陷。供應鏈安全關注的是並非您所寫的內容,以及您的軟體如何被建置與發布。一套計畫兩者都需要。

只有 SBOM 就足以確保供應鏈安全嗎?

不夠。SBOM 告訴您出貨了什麼,這是基礎。您還需要控管進入的內容、保護建置,並持續監控已發布的內容。

主要的框架有哪些?

SLSA 針對建置完整性,NIST SSDF 針對安全開發實務,NIST SP 800-161 則針對供應鏈風險管理。在歐盟,Cyber Resilience Act 為具數位元素的產品訂定法律要求。

軟體供應鏈安全由誰負責?

通常由應用程式資安或產品資安團隊負責,並與執行管線的平台及 DevOps 團隊合作。修正工作再交由負責各項服務的工程團隊。

看看您的建置實際引入了什麼

在 CRACI 上執行一個 GitHub Actions 工作流程,取得建置的 SBOM 紀錄及其網路軌跡。

預約示範