攻擊者的目標是由開源和商業軟件依賴項、第三方 API 和 DevOps 工具鏈組成的軟件供應鏈。軟件工程領導者可以使用軟件供應鏈安全工具來保護他們的軟件免受這些攻擊的連鎖影響。

主要發現

• 越來越多的軟件工程團隊現在負責解決軟件供應鏈安全 (SSCS) 需求。

• 軟件工件、開發人員身份、開發工具和交付管道之間相互依賴的碎片化網絡造成了軟件供應鏈中的可見性差距。

• 不正確的工件完整性驗證允許攻擊者毒害軟件交付管道并危害正在交付的軟件。

• 缺乏自動化工具來執行安全策略和檢測錯誤配置，削弱了軟件交付過程的安全態勢。

建議

負責保護軟件供應鏈安全的軟件工程領導者應該：

• 根據 SSCS 工具在整個軟件開發生命周期 (SDLC) 中滿足三個關鍵用例的能力（提高可見性、保護完整性和增強安全態勢）對其進行評估。

• 通過使用 SSCS 工具通過軟件成分分析和軟件物料清單 (SBOM) 以及 SDLC 中所有管道活動和交互的審計跟蹤來管理第三方風險，從而減少軟件供應鏈中的可見性差距。

• 通過簽署和驗證構建工件，確保來源數據到位并防止使用不合規的工件，在整個軟件交付過程中保護軟件的完整性。

• 通過使用 SSCS 工具自動執行 SDLC 中的策略以及檢測和解決 DevOps 工具中的配置錯誤，改善軟件交付過程的安全態勢。

戰略規劃假設

到 2028 年，大型企業中 85% 的軟件工程團隊將部署軟件供應鏈安全工具，而 2025 年這一比例為 60%。

市場定義

Gartner?將軟件供應鏈安全 (SSCS) 工具定義為那些通過在開發和交付過程中防止受到攻擊來構建安全軟件的工具。這些保護措施擴展到源代碼、開發人員身份、開發工具、交付管道和部署后補丁。SSCS 工具通過基于策略的依賴項管理、軟件組合分析 (SCA) 和軟件物料清單 (SBOM) 檢查來降低第三方風險。它們在通過開發和交付管道時通過簽名和驗證來確保工件的出處和可追溯性。SSCS 工具支持 SaaS 和混合部署模型，并補充 DevOps 平臺以提高組織的 DevSecOps 成熟度。

軟件供應鏈超越組織邊界，由外部實體和內部系統組成。內部系統包括軟件交付管道、軟件依賴項和軟件開發環境。外部實體包括合作伙伴、開源軟件 (OSS) 和供應商。組織對內部系統有更大的控制權，而對外部實體幾乎沒有控制權。SSCS 工具可保護組織免受內部威脅和受感染的外部實體的侵害。

軟件工程團隊還可以使用這些工具，通過自動執行安全和合規政策以及自動認證來滿足監管和政府要求。政府認識到軟件是當今最關鍵的基礎設施。因此，如果對軟件的開發方、開發方式和組成部分缺乏了解，不僅會對企業構成危險，還會對整個社會構成危險。

SSCS?工具可幫助組織實現以下切實成果：

• 識別并減輕因廣泛使用開源軟件而產生的安全和合規風險。

• 減少由于對用于軟件開發、交付和運行時的工具、環境、管道和基礎設施的攻擊而導致的開發人員摩擦和生產力損失。

• 保護組織免受上游軟件依賴項的攻擊以及下游軟件用戶的受損產品的攻擊。

• 保護組織的知識產權，這些知識產權越來越多地存在于軟件中。

• 通過使軟件交付基礎設施可審計以及自動執行應用程序安全策略來滿足治理和監管要求。

強制功能

該市場的強制性特征包括：

開發

• 使用SCA識別已知漏洞、軟件許可證和運營風險（例如嵌入式 OSS 的可行性、可信度和可維護性），從而降低第三方風險。

• 通過掃描內部開發的代碼中的秘密和潛在的安全漏洞來降低第一方風險。

• 支持生成、管理和處理軟件開發過程中生成和使用的工件的 SBOM。

交付管道

• 通過簽署和驗證構建工件、源代碼提交和可部署二進制文件來保護持續集成/持續交付（CI/CD ）管道中的軟件完整性。

• 提供準確、完整的開發工具、開發人員身份和軟件工件清單，以全面了解從開發到交付的路徑。

• 通過檢測和修復 DevOps 工具（例如源代碼存儲庫和工件注冊表）中的錯誤配置以及啟用或防止使用不合規的工件，自動化策略實施以增強交付管道的安全態勢。

部署后

• 啟用受影響模塊和組件的追溯能力以返回其原始來源。

• 監控部署后暴露的新風險和漏洞，并提供活動審計跟蹤以檢測和從供應鏈攻擊中恢復。

通用功能

該市場的通用功能包括：

• 通過應用安全策略和許可證過濾器來支持開源組件的管理，確保僅使用經過批準和審查的開源組件。

• 支持生成機器可讀文檔（例如 VEX、CSAF），以便有效披露漏洞并確定影響交付軟件的常見漏洞和暴露（CVE）的優先級。

• 支持可達性分析，通過識別應用程序是否依賴于易受攻擊的代碼片段和/或受影響的依賴項來分析和確定風險的優先級。

• 掃描容器鏡像來檢測安全漏洞并識別違反政策的行為。

• 支持二進制SCA ，無需訪問源代碼即可識別和掃描開源和專有組件（例如供應商工件）中的漏洞和/或惡意代碼。生成的組件庫存通過 SBOM 報告。

• 支持 SBOM 生命周期管理功能，實現多個供應商和消費者通過公共交換點發現、訪問和安全交換 SBOM。

• 檢測并防止人類和機器身份對 SDLC 工具和環境的未經授權的訪問。

• 支持提取威脅情報以告知依賴性掃描和使用政策。

• 觸發工作流以替換在構建和部署期間或之后被篡改或受漏洞影響的工件。此工作流可能涉及自動創建用戶案例來跟蹤升級，并進行相應的升級影響分析。

市場描述

現代軟件應用程序很少完全從頭開始構建；相反，它們依賴于第三方組件，包括商業和開源軟件、API、庫、插件和日益生成的 AI 模型。這些依賴關系共同構成了軟件的“供應鏈”。SSCS 涉及減輕與此依賴鏈相關的風險。

軟件供應鏈還包括用于開發、交付和運營軟件的自動化工具、開發環境、開發人員身份和交付管道。這些實體及其交互和關系都帶來了另一種風險。請注意，交付管道是臭名昭著的針對tj-actions?、SolarWinds和Ultralytics?的軟件供應鏈攻擊中的攻擊媒介。???

為了確保供應鏈安全，軟件工程團隊必須了解 SDLC 管道、存儲庫和工件，保護其完整性并改善應用程序安全態勢。SSCS 工具可幫助軟件工程團隊實現這些成果（見圖1?）。

圖 1：軟件供應鏈安全工具功能

SSCS?并非新興需求，因為自從開發人員不再依賴自己的源代碼和工具以來，軟件供應鏈就一直存在。組織通常使用一組不同的工具和實踐來減輕相關風險，例如軟件成分分析、應用程序安全測試 (SAST/DAST) 和應用程序安全態勢管理。然而，一些問題仍然很大程度上未得到解決，需要專門的能力。例如：

• 軟件完整性——確保組件與其聲明相符且未被篡改。

• 出處——確定軟件組件的來源。

• 可見性——提供 SDLC 中的資產清單和訪問權限的全面視圖。

• 可追溯性——在產品流向生產過程時對其進行識別、追蹤和追溯。

SSCS?工具通過統一的界面將這些功能整合在一起，該界面與用于軟件開發和交付的 DevOps 工具集成。參見圖 2，了解 SSCS 工具功能如何滿足開發、交付和部署后場景中的安全需求。

圖 2：SSCS 工具在開發、交付和部署后保護軟件的功能

確保軟件交付管道的安全是確保交付軟件安全的先決條件。

市場方向

大多數軟件工程領導者將應用程序安全技能評為“高度重要”。在 2025 年 Gartner 軟件工程調查中，近三分之二的受訪者認為應用程序安全對于交付滿足業務需求的軟件非常重要（見圖3?）。1這對 SSCS 工具來說是個好兆頭，因為它們解決了應用程序安全中的一個關鍵挑戰——保護軟件供應鏈。

圖 3：大多數軟件工程領導者認為應用程序安全技能非常重要

軟件供應鏈的日益復雜以及由此產生的組織與其技術生態系統之間的相互依賴關系也將擴大和加速對 SSCS 工具的需求。根據世界經濟論壇的《2025?年全球網絡安全展望報告》，軟件供應鏈漏洞正成為生態系統中最大的網絡風險。當被問及“復雜性的哪個方面給您的組織帶來最大的挑戰或擔憂”時，復雜供應鏈相互依賴關系中的漏洞成為最大的挑戰。?

競爭態勢、購買者行為和影響市場的外部力量

• 市場細分之間的重疊度不斷增加：建立軟件供應鏈的信任需要整個 SDLC 的可見性、完整性和態勢管理。這會導致與相鄰市場（如應用程序安全態勢管理 (ASPM)、應用程序安全測試和云原生應用程序保護平臺 (CNAPP)）重疊。

• 增加內部采購：由于數字產品為組織提供了競爭優勢，組織正在將部分軟件開發外包。這不可避免地需要投資于 DevOps 相關工具，以及確保完整 SDLC 的工具。軟件工程團隊將尋求了解其軟件供應鏈并監督其供應商和開源軟件的安全級別。

• 分擔安全責任：向 CISO 報告的應用程序安全團隊傳統上是應用程序安全所有方面（包括SSCS）的唯一托管人。近年來，這種情況發生了變化，軟件工程團隊和平臺工程團隊與App?S?ec 團隊共同承擔應用程序安全的責任。因此，SSCS 工具承擔雙重責任，成為跨用戶角色的共享事實來源，同時為每個用戶角色提供量身定制的功能。

• 國家支持的攻擊：許多開源軟件很容易受到國家惡意行為者的滲透。因此針對全球各個行業國家支持的軟件供應鏈攻擊變得越來越復雜和普遍。這些攻擊要么利用了軟件本身的漏洞（如Kaseya的情況），要么破壞了 SDLC（如SolarWinds和NotPetya攻擊的情況）。SSCS 工具對于降低這些風險至關重要。?

• 開放式 AI 模型的使用：開放式大型語言模型 (LLM) 易于訪問且將其集成到應用程序中的門檻較低，這為軟件供應鏈風險增加了新的維度。2025年 Gartner 軟件工程調查顯示，47% 的受訪者將 LLM 集成到現有應用程序中。買家將期望SSCS工具能夠發現 LLM 的使用情況、掃描模型中的風險并實施政策以防止使用未經批準的 LLM。風險示例包括模型來源薄弱、不受支持的模型以及阻礙模型使用的地緣政治障礙。Gartner預測，到 2025 年，對軟件供應鏈和基礎設施技術堆棧的毒害將占企業使用的 AI 惡意攻擊的 70% 以上。開源模型和數據科學軟件（如Jupyter Notebook或Python庫）是新的 AI 攻擊媒介。因此，更多的人工智能模型市場將包括對下載的第三方和開源模型的安全模型掃描。

• 合規和政府授權：世界各地的政府、政策制定者和監管機構都在強制要求進行第三方供應商評估、持續漏洞掃描和 SBOM，以構建可信的軟件供應鏈。強制性法規的例子包括美國政府網絡安全行政命令 14144?、歐盟網絡彈性法案、歐盟 NIS2?指令和聯邦食品、藥品和化妝品法案 (FD&C?法案)?。?????

SSCS?監管合規工具

組織將使用 SSCS 工具作為主要機制，以確保安全軟件開發實踐符合法規要求。涉及 SBOM（由 VEX 豐富）和 SLSA 證明的 SSCS 功能使賣方和買方都能遵守政府和法規要求。

市場分析

根據Gartner?2025 年大型企業技術采用路線圖調查，60% 的軟件工程領導者表示他們已經部署或正在部署 SSCS，另有 12% 正在試用，13% 處于規劃階段。我們的調查顯示，與強化 DevOps 管道相比，部署 SSCS 的組織更有可能從代碼掃描、機密掃描、軟件成分分析和 SBOM 管理開始。

通過工件完整性驗證和自動策略實施來強化 DevOps 管道的功能的采用率相對較低。這是因為開發人員在持續集成/持續交付 (?CI/CD?) 管道中與簽名和驗證工作流相關的經驗一直很差。DevOps 管道中工具的異構性加劇了創建工件證明和確保管道完整性的挑戰。

市場規模和細分

Gartner?估計 SSCS 工具的市場規模約為 12 億美元。該市場由幾家知名的軟件組合分析、DevOps 平臺和云原生應用程序保護平臺提供商代表，這些提供商提供捆綁功能以及大量一流的 SSCS 專業提供商。

SSCS?工具市場可以根據其專業功能進行細分：

• 確保開源軟件（OSS）的使用安全

• 解決 CI/CD 安全風險

確保開源軟件的使用安全

目前，OSS 占所有軟件包的 70%?到 90%?。然而，只有 15%?的組織對其 OSS 管理實踐非常有信心；大多數組織都有顧慮。因此，一部分提供商專門致力于確保安全使用開源軟件包和第三方依賴項。這些功能包括：??

• 用于識別漏洞和進步的基本軟件成分分析，例如可達性分析、升級影響分析和二進制分析（無需訪問源代碼）。

• 支持策略驅動的軟件包管理，以確保開發人員只使用經過批準和審查的開源組件。

• SBOM?可以深入了解其軟件的組件和依賴關系。此功能與 SCA 和 ASPM 相結合，可通過識別軟件供應鏈中的漏洞來更好地進行風險管理。

我們看到三種市場力量推動著這些功能的快速采用：

• 越來越依賴開源軟件需要在工具和技術上進行相應的投資以管理和確保其使用。

• 加速采用開源組件、工具和編程語言（例如Python?），這在很大程度上受到生成式 AI 用例的推動。

• 強制使用 SBOM 的監管和合規要求。

解決 CI/CD 安全風險

第二部分 SSCS 工具提供商專門確保軟件組件的來源和完整性。這一直是應用程序安全領域的一個長期安全漏洞，需要通過簽名提交、工件證明和配置漂移檢測等技術來強化 CI/CD 管道。

多個開源基金會和政府機構已發布指南和框架來彌補這一 CI/CD 安全漏洞。這部分提供商專門實施這些指南和框架，而不會引入開發摩擦。軟件工程領導者可以使用這些參考資料作為方便的清單來評估 SSCS 工具功能并驗證供應商的聲明：

• OWASP?十大 CI-CD?安全風險，十大OWASP 基金會項目

• 軟件工件的供應鏈級別，或 SLSA（“salsa”），是作為開放源代碼安全基金會的一部分發起的一項合作努力。

• DevSecOps CI/CD?管道中軟件供應鏈安全的集成策略，NIST 特別出版物 800-204D。

• 安全軟件開發框架 (SSDF)?版本 1.1?，NIST 特別出版物 800-218。

• CIS?軟件供應鏈安全指南、互聯網安全中心指南。

• 保護軟件供應鏈 —?開發人員推薦實踐指南、持久安全框架軟件供應鏈工作小組。

代表供應商

Gartner?估計，市場上有大約 35 家供應商滿足本指南中概述的四項關鍵能力中的三項。對于此處列出的 29 家供應商，Gartner 能夠通過兩個公開來源驗證，這些供應商的當前產品已在市場上銷售至少一年，并且解決了 CI/CD 安全風險以及第三方依賴風險。代表性 SSCS 供應商包括具有以下特征的商業供應商組合：

1.????提供獨立 SSCS 功能的供應商

2.????包含 SSCS 功能的 ASPM 供應商

3.????提供 SSCS 功能的 CNAPP 供應商

4.????添加了 SSCS 功能的 AST 和/或 SCA 供應商

5.????包含 SSCS 功能的 DevOps 平臺

請參閱表 1-5 以獲取代表性供應商及其產品、服務或解決方案的相應列表。

表1?：提供獨立 SSCS 功能的代表性供應商

供應商	產品、服務或解決方案名稱
ActiveState	ActiveState
BlueFlag Security	BlueFlag Security
?Endor ? Labs	Endor Labs?軟件供應鏈安全平臺
Lineaje	Lineaje SBOM360
ReversingLabs	Spectra Assure
Xygeni Security	Xygeni CI/CD?安全

來源：Gartner（2025 年 4 月）

表2?：具有 SSCS 功能的代表性 ASPM 供應商

供應商	產品、服務或解決方案名稱
?Apiiro	Apiiro
?Arnica	Arnica
BoostSecurity	BoostSecurity
?Cycode	Cycode
Jit	Jit ASPM?平臺
Legit Security	Legit Security
OpsMx	OpsMx Delivery Shield
OX Security	OX?軟件供應鏈安全
Scribe	Scribe

來源：Gartner（2025 年 4 月）

表3?：提供 SSCS 功能的代表性 CNAPP 供應商

供應商	產品、服務或解決方案名稱
Aqua Security	Aqua Security
?Palo Alto	Prisma Cloud
Wiz	Wiz Code

來源：Gartner（2025 年 4 月）

表4?：具有附加 SSCS 功能的代表性 AST 和/或 SCA 供應商

供應商	產品、服務或解決方案名稱
?Anchore	Anchore平臺
FOSSA	FOSSA
Checkmarx	Checkmarx One
Snyk	Snyk
Sonatype	Sonatype
Veracode	Veracode

來源：Gartner（2025 年 4 月）

表5?：包含 SSCS 功能的代表性 DevOps 平臺

供應商	產品、服務或解決方案名稱
?GitHub	GitHub?高級安全
?GitLab	GitLab DevSecOps?平臺
Harness	Harness供應鏈安全
JFrog	JFrog軟件供應鏈平臺
?Red Hat	Red Hat Trust?應用程序管道

來源：Gartner（2025 年 4 月）

市場建議

• 通過使用 SSCS 工具來提高可見性、保護完整性并增強整個 SDLC 的安全態勢，從而縮小信任差距。

• 通過將 SSCS 功能集成到 DevOps 管道中以遵守行業認可的準則（例如 SSDF 和 SLSA），推進安全軟件開發實踐。與應用程序安全團隊合作，定義組織的 SSCS 策略，并與平臺工程團隊合作，在內部 DevOps 工具鏈中創建安全默認值。

• 通過選擇能夠與現有的 DevSecOps 工具集成并支持我們市場定義中概述的強制和可選功能的供應商來合理化工具。SSCS 工具供應商從不同的優勢地位進入市場，包括 SCA、SBOM 和 SLSA 合規性。