開源安全的利器：八個頂級SBOM工具

到2025年，60%的開發或采購關鍵基礎設施軟件的組織將強制執行和標準化SBOM。今天，SBOM普及率不到20%。

軟件安全（尤其是開源軟件安全）的基本前提是你需要知道軟件中都有哪些代碼組件，或者說代碼的可見性。這也是軟件物料清單（SBOM）越來越受到業界重視的原因。從某種意義上來說，SBOM相當于食品安全領域的“添加劑成分表”。

軟件行業，甚至毫不夸張地說，整個數字經濟的基礎設施，都正在被（開源）軟件的“安全債”問題反噬。近年來，一個接一個的安全耳光接踵而至：SolarWinds軟件供應鏈攻擊，曠日持久不見天日的Log4j漏洞，以及開源工具npm維護者的“投毒”事件，都清楚地表明全球的軟件供應鏈安全問題已經到了必須懸崖勒馬的危險地步。

2022年4月Synopsis的的一項行業研究發現，97%的軟件包含開源代碼，其中計算機硬件和半導體、網絡安全、能源和清潔技術、“物聯網”設備以及互聯網和移動應用軟件相關系統中，100%都發現了開源代碼。而且開源代碼的數量也不容忽視——受調查的代碼中有78%都是開源的。最令人擔憂的是，包含開源代碼的代碼庫中有81%至少存在一個漏洞，每個應用程序平均有五個高風險或嚴重漏洞仍未修補。

如今，開源軟件已經是無處不在的“軟件添加劑”，但用戶卻沒有“成分表”可用，其危險性不言而喻。

源于制造業的物料清單這個概念對于閉源的專有軟件是無效的，但是對于開源程序，SBOM不僅是有用的，而且是必須的。因為即使是實力最雄厚的科技巨頭也需要花費數周時間才能找到軟件漏洞，修補時間往往更長。SBOM則能幫助企業快速鎖定漏洞在軟件中的位置，因而大大提高軟件漏洞的修復和緩解速度。

根據Linux基金會、開源安全基金會(OpenSSF)和OpenChain的說法，提高（開源）軟件安全性的答案是SBOM。Linux基金會研究副總裁Stephen Hendrick將SBOM定義為“唯一標識軟件包及其內容的正式且機器可讀的元數據，它可能包括有關其內容的信息，包括版權和許可數據。SBOM旨在跨組織共享，特別有助于提高軟件供應鏈參與者交付的組件的透明度。”

最佳SBOM實踐

SBOM應包括：

• 應用程序的開源庫
• 程序的插件、擴展和其他附加組件
• 開發人員內部編寫的自定義源代碼
• 有關這些組件的版本、許可狀態和補丁狀態的信息
• 自動組件加密簽名和驗證
• 自動掃描以生成SBOM，作為持續集成/持續部署(CI/CD)管道的一部分

SBOM應該使用一致的格式。流行的SBOM格式包括軟件包數據交換(SPDX)、軟件標識(SWID)標記和OWASP CycloneDX。雖然這些都是標準，但2021年的白宮行政命令并未強制規定特定的SBOM格式。到目前為止，這三者都沒有成為事實上的行業標準。

為了使SBOM發揮效力，不僅要自動創建SBOM，還要使其成為CI/CD管道的一部分。正如美國國家電信和信息管理局(NTIA)所說，最終目標是以“機器速度”生成SBOM。

SBOM三大用例

SBOM有三種不同的用例：

• 軟件生產商使用SBOM來協助構建和維護他們提供的軟件。
• 軟件采購商使用SBOM通知預購保證、協商折扣和計劃實施策略。
• 軟件運營商使用SBOM為漏洞管理和資產管理提供信息，管理許可和合規性，并快速識別軟件和組件依賴關系以及供應鏈風險。

上述用例對SBOM的需求是完全不同的。開發人員需要能夠在CircleCI、Jenkins或Travis CI等CI/CD管道上運行的工具。而運營商或客戶可能甚至不知道CI/CD管道是什么，但可能非常關心資產管理和安全補丁更新。

Gartner估計，到2025年，60%的開發或采購關鍵基礎設施軟件的組織將強制執行和標準化SBOM。今天，SBOM普及率不到20%。

如何選擇SBOM工具

市場上許多SBOM工具、捆綁代碼安全掃描程序和其他類似程序，用戶選擇起來比較困難，Gartner建議使用提供以下功能的工具：

• 在構建過程中創建SBOM。
• 分析源代碼和二進制文件（如容器圖像）。
• 為這些工件生成SBOM。
• 編輯SBOM。
• 以人類可讀的格式查看、比較、導入和驗證SBOM。
• 將SBOM內容從一種格式或文件類型合并和翻譯成另一種格式或文件類型。
• 支持通過API和庫在其他工具中使用SBOM操作。

值得注意的是，即便是當今最好的一些SBOM工具，也未能覆蓋Gartner的建議功能清單，因此我們建議用戶多嘗試一些工具，來尋找最適合自己的，或者向供應商和開發人員提供反饋。對于很多企業來說，能夠在2025年之前完成這項任務并制訂出最佳實踐計劃就很不錯。

八個值得關注的SBOM工具

Anchore

Anchore從事SBOM業務已有六年，主要基于兩個開源項目。一個是Syft，一個用于從容器映像和文件系統生成SBOM的命令行界面(CLI)工具和庫。另一個是Grype，一個用于容器映像和文件系統的易于集成的漏洞掃描工具。

上述兩個工具可以一起使用，在開發流程的每個階段生成SBOM（從源代碼存儲庫和CI/CD管道到容器注冊表和運行時）。這些SBOM保存在一個集中的存儲庫中，以實現完整的可見性和持續監控，甚至覆蓋部署后。它支持CycloneDX、SPDX和Syft自己的SBOM格式。

Anchore將其SBOM功能捆綁到Anchore Enterprise 4.0軟件SCM（供應鏈管理）平臺中。Anchore的目標是成為一體化軟件供應鏈和SBOM安全公司。

FOSSA

FOSSA的旗艦程序是開源許可證合規管理器和開源漏洞掃描程序。

在FOSSA的方法中，用戶可以將其SBOM工具與版本控制系統（例如GitHub、BitBucket或GitLab）集成。或者，用戶也可以使用它的CLI并在本地運行它，或者將其集成為CI/CD管道的一部分。

無論哪種方式，當掃描項目時，FOSSA都會自動識別目標代碼庫的直接依賴關系和深度依賴關系。一些深度嵌入的代碼問題，例如調用Log4j的間接依賴關系，會隱藏在程序中，仍然可被黑客利用來造成嚴重破壞。

Mend

Mend曾經的名字是WhiteSource，提供了多種軟件組合分析(SCA)工具。SBOM包含在其Mend SCA工具中。因此，Mend與其說是開發者程序或CI/CD工具，不如說是程序員的開源許可和安全機制。

因此，Mend可用于跟蹤每個組件，包括直接和傳遞依賴關系、識別漏洞、提供修復路徑以及在組件更改時自動更新SBOM記錄。該公司聲稱其獲得專利的可達性路徑分析可向用戶展示哪些漏洞可以安全地忽略。

Rezilion

DevSecOps公司Rezilion使用SBOM作為其整體軟件安全和漏洞系統的一部分。它的動態SBOM使用動態運行時分析來跟蹤代碼更改時的軟件攻擊面。因此，它會不斷查找代碼組件的已知弱點。

除了提供CI/CD、導入和生產環境中所有軟件組件的實時清單之外，它還會不斷更新SBOM。用戶可以將SBOM導出為CycloneDX和Excel電子表格。

SPDX SBOM Generator

作為一個獨立的開源工具，SPDX SBOM Generator可在用戶當前的包管理器或開發系統中創建SPDX SBOM。用戶可以使用它的CLI從代碼中生成SBOM數據。它報告代碼的組件、許可證、版權和安全參考。此數據以SPDX v2.2規范導出。如果你只需要基礎的SBOM功能，那么SPDX SBOM Generator是個不錯的選擇。

Tern

Tern也是一個開源SBOM項目，可與SPDX SBOM Generator很好地匹配使用。這個SCA工具和Python庫不使用包管理器或構建系統，而是為容器映像和Dockerfile生成一個SBOM。它還能在SPDX中生成SBOM。

TauruSeer

該SBOM工具以軟件即服務(SaaS)的方式提供。TauruSeer依靠獲得專利的以應用程序為中心的集成方法，將其Cognition Engine安全掃描與其SBOM相結合。該軟件包能保護和跟蹤您的開發人員和客戶的代碼。

Vigilant Ops

Vigilant Ops是一家醫療設備網絡安全公司，憑借其InSight平臺，已將注意力轉向SBOM。其SaaS平臺生成、維護和經過認證的SBOM共享。它使用持續的漏洞監控和警報來整合安全性。其SBOM認證使用專利算法來確保所有組件都經過驗證，并與漏洞相關聯。

Vigilant Ops的安全功能也可以與其他程序生成的SBOM一起使用。相關數據在靜態和傳輸中都是加密的。