增強軟件供應鏈安全所需的10個安全工具

安全領袖在構建軟件供應鏈安全計劃時會面臨一個復雜的情況：可用工具與技術的飛速發展既帶來了積極作用，同時也伴隨著負面影響。

在積極方面，技術創新步伐的加快為我們提供了更多的機會來實現全面的洞察力與透明度，從而對構成軟件組合的各種組件和代碼進行深入的了解。

然而在消極方面，實驗和創新正在朝著許多不同的方向發展，導致了資源的分散和不集中，最終進展緩慢，難以達到預期的效果。其次，安全工具方面也涌現出許多新的分類縮寫與專業產品，進一步為企業找到適合其需求的產品工具增加了難度。

數世咨詢指出，在五花八門的安全工具中，一些更偏向于傳統的應用安全工具，它們正朝著開發者友好的方面發展。另一些則是適用于開發者的傳統工具，其發展方向是增加針對于安全的控制與功能以迎接供應鏈風險的挑戰。還有一些來自于DevSecOps領域的工具，其致力于促進各個團隊之間的相互協作。

我們之所以難以對軟件供應鏈安全有一個清晰的全局把控，其中一個主要原因就是整個供應鏈涉及太多環節，并且每個環節都有可能會出現問題。許多情況下，漏洞是直接嵌入在軟件中的，就像幾年前的SolarWinds事件。另外，常用的庫中也可能隱藏著漏洞，Log4j就是一個典型的例子。甚至證書頒發機構（certificate authority ，CA）都有可能會出現安全問題。 

一、軟件供應鏈安全領域并不存在“黃金標準”

盡管市場上一些軟件供應鏈安全產品堆棧以及安全平臺已經開始整合統一，但這些產品的功能組合卻五花八門。由于每個產品都具有獨特的功能和優勢，所以用戶在選擇適合自己的安全產品時仍會感到困惑。

這些平臺主要聚焦于軟件成分分析（software composition analysis ，SCA）與生成軟件材料清單（software bills of material ，SBOM）的工具類別。其中SBOM被稱為現代軟件的“成分列表”。盡管SCA和SBOM基本上已經構成了許多軟件供應鏈安全工具的核心，但對于企業的CISO來說，這些也僅是構建全面供應鏈風險管理計劃的冰山一角而已。

Gartner公司的應用安全高級總監兼分析師Dale Gardner,也曾表示：“在考慮供應鏈安全時，人們通常會專注于使用類似于SCA這樣的工具及其所生成的SBOM，這些都是解決方案中非常重要的部分，但實際上也只是一個非常局部的解決方案”

所以說，一個全面的解決方案還應涉及許多其他的關鍵要素，包括密鑰管理、依賴關系映射與管理、CI/CD（持續集成/持續交付）流水線安全、有效的存儲庫管理等等。然而實際情況下，安全團隊很難從單獨某個供應商那里獲取到自己所需的所有解決方案。

話雖如此，但缺乏整合統一未必是件壞事。因為安全工具或平臺的整合可能會使得組織陷入與供應商綁定的風險，并且這也意味著供應商可能無法跟上組織的發展與變化速度。

這種分散現象不僅源自于不同技術視角（開發人員專用工具、運維團隊專用工具以及安全部門專用工具）的有機創新，同時還涉及到多種不同的使用情景。

數世咨詢強調，組織必須對自己所面臨的風險或使用情況進行非常具體的界定，以便能夠找到正確的軟件解決方案或整體解決方案堆棧來解決這些問題。組織需要什么樣的解決方案實際上取決于其在軟件供應鏈安全場景中的位置。例如一個組織在作為軟件生產者時所需要的安全解決方案與它作為軟件使用者時的解決方案是存在差異的。并且很多時候，在整個供應鏈生命周期的某些階段，組織可能會同時扮演這兩種角色。

如何將所需的關鍵要素整合在一起，將極大地取決于組織的使用情況、基礎設施以及團隊的技能和文化構成。然而不幸的是，目前還沒有一種簡單的方式來輕松構建出這個解決方案的完整堆棧。

二、10個類別

以下是為CISO提供的一個不錯的入門清單，用于規劃適合自己的軟件供應鏈安全解決方案堆棧。這份清單包含了主要的工具類別與功能，有助于安全領導者在制定軟件供應鏈安全路線圖時考慮到可能的需求。需要注意的是，這份清單并不是百分之百的詳盡無遺，而且由于行業變化迅速，其中的內容可能會隨時需要更新。

1、SCA 與 SBOM 生成

目前階段，SCA工具最為人熟知的應用場景為軟件供應鏈安全方面，但其最初始的用途則起源于一個更加常見且普遍的使用場景。最初，這些工具的構想是幫助開發團隊跟蹤其構建過程中所使用的開源組件，以確保合規性。隨著供應鏈安全越來越受到關注，SCA工具在所跟蹤的組件上進行了更加深入的分析與漏洞管理，成為組織生成軟件物料清單（SBOM）以及管理其開源使用行為的主要方法之一。Mend.io（前身為WhiteSource）、FOSSA以及Synopsys Black Duck就是這種演進路徑的主要例子。

SCA并不是生成SBOM的唯一選擇。其他一些SBOM生成方法包括使用命令行界面（CLI）工具（如CycloneDX CLI和SPDX Tool），運行時分析工具（如Rezilion），或二進制分析工具（如ReversingLabs）等。但對于那些構建軟件供應鏈解決方案堆棧或生態系統的供應商來說，SCA往往是其必備的基礎工具。其中就包括一些SCA廠商，他們通過內部開發或收購進入了其他工具類別的領域。還有一些可能從一開始就采用面向開發人員的平臺思維，將SCA工具納入到供應鏈工具的組合中，Snyk就是一個很好的例子。最近在供應鏈安全領域新出現了許多合作關系。例如，Synopsys和ReversingLabs之間的合作。通過合作，他們可以將各自的技術和產品整合在一起，為客戶提供更加全面強大的供應鏈安全功能。這樣的合作關系使得客戶能夠從多個廠商中選擇最適合他們需求的解決方案，而無需被限制在某個單一平臺上。

2、代碼掃描與滲透測試

軟件供應鏈的安全問題本質上是一個應用安全（AppSec）問題。因此，我們可以利用傳統的安全代碼掃描工具來在解決方案中發揮作用。靜態應用程序安全測試（static application security testing，SAST）、動態應用程序安全測試（dynamic application security testing，DAST）、交互式應用程序安全測試（interactive application security testing，IAST）和運行時應用程序掃描保護（runtime application scanning protection，RASP）等工具，以及恰到好處的滲透測試都可以幫助組織測試其內部代碼，并進一步檢查第三方代碼，來作為“后備措施”，以抵御常規SCA或SBOM測試工具和技術所遺漏的風險。

通過全面的代碼掃描來維護多個安全層級至關重要，同樣重要的還有滲透測試的抽樣檢查。

SCA和SBOM產品主要依賴于已知的、先前確認的漏洞數據庫，這些漏洞在過去已經被公開披露并記錄在漏洞庫中。這些產品通過檢查軟件構件及其依賴關系，來識別是否存在已知漏洞。這種方法僅對于防范已知的、常見的漏洞來說是有效的。但通過一次徹底的應用程序滲透評估，能夠更加全面地發現潛在的漏洞和安全風險，特別是那些可能存在于第三方庫和框架中的未知漏洞。

3、SBOM 優化與集成

隨著組織開始創建并接收SBOM，工件的集成、優化和管理也逐漸成為其運作中日益重要的一部分。例如，添加漏洞可用性交流（vulnerability exploitability exchange ，VEX）信息將成為賦予SBOM上下文的日益關鍵的部分。同樣的，這些工具也可以通過OpenSSF評分卡數據和CISA的已知被利用漏洞（Known Exploited Vulnerabilities ，KEV）數據庫的利用預測評分系統（exploit prediction scoring system，EPSS）等數據來豐富SBOM信息。

此外，對軟件組合和業務線上的SBOM信息進行集成將成為安全領袖日益關注的問題。這仍然是一個新興領域，一個尚未形成被行業分析師所確認的類別。因此CISO必須在SCA和其他類型的工具中尋找這些功能，包括開源工具和那些正在開拓全新領域的新平臺，才能夠定義出自己獨特的類別。目前，像Cybellum、Anchore和Rezilion，以及像Bomber這樣的新開源工具均在該領域中表現出不錯的潛力。

4、密鑰管理

在過去，共享密鑰掃描與管理被視為一個獨立的工具類別，是一種單獨的工具或解決方案。然而，隨著對軟件供應鏈安全的關注不斷增加，越來越多的軟件供應鏈安全工具開始將這一功能納入其中，成為了軟件供應鏈安全工具的一部分。這是因為目前在軟件開發和生產環境中，將敏感信息和憑據嵌入到源代碼、配置文件或基礎架構代碼中的現象仍屢見不鮮。這種做法可能會導致敏感信息的泄露與安全漏洞的產生，因此迫切需要解決這個問題。

最近更新的一份Gartner報告建議：例如憑據文件、私鑰、密碼以及API令牌等密鑰信息不應上傳到源代碼控制倉庫中。而應當使用密鑰管理工具來安全地存儲和加密這些機密信息，強制實施訪問控制，并進行密鑰管理（即創建、定期更改以及刪除）。

所以，密鑰管理是最基本的工具組件，可以有效地阻止攻擊者通過利用共享密鑰來破壞組織的軟件供應鏈完整性。

5、依賴項管理與映射

依賴項管理與分析是另一個較為模糊的類別，它與其他工具類別（如SCA和SBOM集成）具有很高的重疊度。之所以將其單獨分為一類，是因為它直接涉及到一些最為棘手的軟件供應鏈安全問題的核心。

如今一些安全專家認為當前的SBOM狀態存在一個主要問題，即SBOM仍然難以準確傳達與所列出的軟件相關的傳遞性依賴關系。

CISO及其團隊需要尋求一種更好的方式來映射和管理跨越應用程序、API、CI/CD流水線組件以及基礎架構即代碼的隱藏依賴關系網絡。對此，一些可用工具包括依賴映射工具，不僅被用于依賴管理方面，而且還被性能和可靠性方面的利益相關者所使用。例如Datadog和Atlassian所推出的工具。

6、可信存儲庫與注冊表

雖然資源庫和容器注冊表本身并不是安全工具，但它們可以與嚴格的策略和程序結合起來使用，從而在管理供應鏈風險方面發揮重要作用。創建可信的資源庫與容器注冊表是為開發者建立“安全導向措施”基礎設施的重要組成部分。通過提供經批準組件的中心化來源是避免安全問題發生的積極主動措施，有助于建立對組織軟件的有效治理機制。

這些資源庫充當了經過審核的構件與軟件組件的可信來源，在一定程度上推動實現了軟件‘成分’的可見性、可審計性、可追溯性以及集中治理。

7、安全代碼簽名

在軟件開發過程中，開發人員會提交軟件，并對其進行部署。通過對這些軟件進行代碼簽名，可以有效地驗證軟件的來源和完整性。于是，在軟件的整個生命周期中，代碼簽名也逐漸成為了一種確保代碼和容器完整性的最佳實踐。這不僅可以保護軟件免受未經授權的篡改與損壞，同時還能在向外部客戶交付產品時建立起信任。所以代碼簽名證書自然而然就成為了軟件供應鏈攻擊者所青睞的目標，因此CISO及其團隊需要謹慎選擇合適的工具并建立控制，以確保其代碼簽名過程真正安全。該領域中的重要參與者包括Garantir、Keyfactor、CircleCI、Cosign和Venafi。

8、CI/CD 流程安全

持續集成/持續交付流水線是開發人員用來生成其代碼的軟件“工廠”所包含的一部分，是整個供應鏈的固有組成部分。因此，加固這些環境的安全工具也成為了健全供應鏈安全計劃必不可少的一部分。除了解決密鑰管理之外，還需要重視其他重要方面，例如CI/CD政策與治理管理、特權訪問控制以及強大的身份驗證機制。這些都是確保整個供應鏈安全的關鍵要素，需要受到充分的重視并實施。

9、第三方風險管理平臺

到目前為止，本文所描述的大多數工具都主要關注于深入挖掘組織內部開發軟件中所使用的第三方組件。但是，對于那些未能獲取到太多可見性的第三方商業軟件，組織又該如何應對呢？這就是第三方風險管理（Third-Party Risk Management，TPRM）工具和流程發揮作用的地方。盡管聯邦SBOM要求可能會在未來幾年內推動軟件供應商提供更多透明度，讓組織更清楚地了解其軟件的構成和依賴關系，但目前大多數組織在軟件供應鏈安全方面仍然缺乏充分的了解，處于相當盲目的狀態。雖然像SecurityScorecard或RiskRecon等第三方風險評分工具無法完全解決這個問題，但它們至少可以充當風險的代理，幫助組織判斷需要與某些供應商和軟件提供商合作，從而深入挖掘其代碼。

第三方風險管理（TPRM）在軟件開發中的優勢就在于，當軟件開發中存在與第三方軟件供應商有關的風險時，TPRM可以對這些風險進行識別與評估。一旦風險被發現，TPRM就成為了一個指導性工具，有助于開發團隊將更多精力放在SCA和深入了解軟件組件的過程中。與那些一刀切的解決方案相比，這種方法更加具有針對性和有效性。

目前，軟件供應鏈安全領域仍然缺乏在應用安全風險和業務風險之間建立堅實聯系的工具。未來供應商和從業者將會探索如何將第三方供應商風險管理（TPRM）平臺和更廣泛的供應鏈風險管理（SCRM）流程與軟件構建物料清單（SBOM）以及持續集成/持續交付（CI/CD）流程的數據進行關聯。未來的重要創新機會也正存在于此。

10、基礎設施即代碼（IaC）安全與云原生應用程序保護平臺（CNAPP）

用于測試和部署代碼的基礎設施本身也是代碼，并且是供應鏈的基礎組成部分。因此，CISO至少應考慮將基礎設施即代碼（IaC）掃描和安全工具納入其更廣泛的供應鏈安全計劃中。這些工具往往處于軟件供應鏈安全工具和云原生應用程序保護平臺（CNAPP）之間，這涉及到云安全和一般安全運營領域。但是CNAPP提供了許多其他供應鏈的安全支持，特別是有關容器可見性和運行時安全方面。容器正日益成為軟件供應鏈中主要的攻擊目標，而運行時安全措施則可以在生產環境中為工作負載提供支持和保障。

三、數世咨詢點評

軟件供應鏈安全工具類別的不斷發展和廣泛應用為組織提供了強大的安全保障。通過使用這些工具，組織能夠更好地了解和管理軟件供應鏈中的潛在風險，保護其信息資產和業務免受供應鏈攻擊的威脅。然而，鑒于軟件供應鏈的復雜性和多樣性，組織仍需綜合運用多種工具，并不斷關注和適應安全威脅的演變，以確保軟件供應鏈的持續安全。