2026 年最佳 SBOM 工具

簡短回答

• 為容器映像檔與檔案系統免費產生 SBOM：Syft；如果您也需要漏洞、機密與 IaC 掃描工具，則選 Trivy。
• 從原始碼產生 CycloneDX：來自 CycloneDX 社群的 cdxgen。
• 為已打包的建置產出產生 SPDX：Microsoft SBOM Tool。
• AWS 上的工作負載：Amazon Inspector SBOM Generator，其結果會提供給 Amazon Inspector。
• 快速取得 GitHub 儲存庫的 SBOM：GitHub 的相依關係圖匯出。
• 免費、可自架的 SBOM 監控平台：OWASP Dependency-Track。
• 以授權合規為優先：FOSSA。供應商與產品組合 SBOM：Manifest 或 Cybeats。容器機群與政府政策套件：Anchore Enterprise。
• 記錄您自己的建置實際取用了哪些內容的 SBOM，並附有漏洞監控與來源證明資料：CRACI，適用於 GitHub Actions。

SBOM 工具的用途

軟體物料清單（SBOM）以 CycloneDX 或 SPDX 等機器可讀格式，列出軟體中的元件、函式庫與相依套件。SBOM 工具分為兩類。產生工具負責撰寫 SBOM。管理工具負責儲存來自眾多產品與供應商的 SBOM、將其與漏洞資料比對、套用政策並加以分享。管理工具仰賴產生工具提供的內容。

SBOM 在什麼時候產生，與用哪個工具產生同樣重要。CISA 關於 SBOM 類型的指引區分了從開發環境與原始碼檔案產生的 source SBOM、在建置可發布建置產物的過程中產生的 build SBOM，以及在建置之後透過分析可執行檔與容器映像檔等建置產物產生的 analyzed SBOM。以下大多數產生工具產生的是 source 或 analyzed SBOM。CRACI 產生的則是 build SBOM。建置時 SBOM 詳細說明了其中的差異。

本頁適合誰

本頁適合因 Cyber Resilience Act（CRA）、客戶問卷或自身漏洞工作而需要 SBOM，並正在評估各種選項的團隊。CRACI 是我們打造的產品，請將這點納入考量。關於其他工具的每一項說法都來自該工具自家的文件，而每個工具都有一頁更詳細的 CRACI vs X 比較頁面。

如何選擇 SBOM 工具

• 您需要產生 SBOM、管理 SBOM，還是兩者都要？產生工具給您一份檔案。管理工具則給您一個地方，保存來自眾多產品與供應商的檔案，加以充實並據以採取行動。
• 軟體是您自己的，還是外購的？對於自己的建置，您掌控輸入，因此可以記錄它。對於供應商軟體，您需要收件、驗證，有時還需要二進位分析。
• 您需要多確定清單是完整的？產生工具是在事後讀取檔案，而它們之間的差異比多數人預期的更大（見下文）。build SBOM 描述的則是建置實際使用的內容。
• 您的客戶要求哪種格式？CycloneDX 與 SPDX 都廣受接受；多數工具至少能產生其中一種。
• 您使用哪種 CI，是否必須自架？開源產生工具可以在任何地方執行。CRACI 目前以代管服務形式支援 Linux 上的 GitHub Actions，GitLab CI、Jenkins 與客戶自架執行器已列入產品藍圖。

如果有多個團隊必須以相同方式產生 SBOM，請參閱跨工程團隊的 SBOM 產生。

SBOM 產生工具

這裡比較的是每個產生工具的功能，而不是它回傳了多少個元件。

CRACI

CRACI 是記錄工具，而不是掃描工具。您的 GitHub Actions 作業在 CRACI 執行器上執行，具備套件感知能力的代理伺服器會記錄每個作業取用的內容，包括從 CI 快取還原的套件。CycloneDX 或 SPDX 格式的 SBOM 包含建置使用的遞移相依套件，並標示每個作業與每個快取的完整性。之後，CRACI 會持續重新評估受監控的 SBOM，因此同時扮演產生工具與管理工具的角色。最適合在 GitHub Actions 中建置的軟體。注意：它無法掃描映像檔或目錄，且目前在 GitHub Actions 上執行 Linux 作業（其他 CI 系統、Windows 與 macOS 已列入產品藍圖）。 CRACI 的 SBOM 產生

Syft

Syft 是 Anchore 推出、採用 Apache-2.0 授權的免費產生工具，適用於容器映像檔與檔案系統。它能辨識數十種套件類型，可產生 CycloneDX、SPDX 與 Syft JSON，並能建立已簽署的 in-toto SBOM 證明。其搭配工具 Grype 會將 SBOM 與漏洞比對。最適合映像檔，以及任何需要免費產生工具的管線。注意：cataloger 依掃描類型選用，因此在已安裝的 express checkout 上，一個旗標就決定了 npm 套件是否會出現在結果中。 CRACI vs Syft 與 Grype

Trivy

Aqua Security 推出的 Trivy 是一款多功能、採用 Apache-2.0 授權的掃描工具，適用於映像檔、檔案系統、儲存庫、VM 映像檔與 Kubernetes。它能找出漏洞、IaC 錯誤組態、機密與授權，並順帶產生 CycloneDX 或 SPDX。最適合希望以一個免費執行檔完成多項資安檢查的團隊。注意：對於儲存庫，它讀取的是鎖定檔，因此 express 5.2.1（沒有鎖定檔）與 claude-code（沒有 manifest）都不會給它任何可讀的內容，正如其文件所述。 CRACI vs Trivy

cdxgen

cdxgen 是 OWASP CycloneDX 專案，採用 Apache-2.0 授權，可從原始碼與容器映像檔建立 CycloneDX BOM。最適合以 CycloneDX 為標準、並希望使用該格式社群自家產生工具的團隊。注意：與其他掃描工具一樣，它只能回報眼前檔案所宣告的內容。 CRACI vs 自建 SBOM 工具組合

Microsoft SBOM Tool

Microsoft SBOM Tool 是採用 MIT 授權的產生工具，可產生 SPDX 2.2，或依需求產生 SPDX 3.0，並能依 SPDX 規格驗證 SBOM。它需要在命令列指定建置產出資料夾、套件名稱、版本與供應商，因此屬於建置後的步驟，可在 GitHub Actions 與 Azure Pipelines 中執行。最適合希望為已打包的建置產出產生 SPDX 的團隊。注意：若指向已提交的儲存庫，而非建置產出資料夾，它幾乎沒有可描述的內容。由於它在命令列接收供應商資訊，因此能填入供應商欄位。 CRACI vs 自建 SBOM 工具組合

GitHub 相依關係圖匯出

GitHub 的相依關係圖彙整了儲存庫的 manifest 與鎖定檔，以及透過相依性提交 API 送出的任何內容，並可從介面或 REST API 匯出為 SPDX。它是 Dependabot 警示的資料來源，包含在每一種 GitHub 方案中。最適合已在使用 GitHub、需要快速取得 SBOM 的團隊。注意：它反映的是預設分支，而不是固定的 commit，而且是依據 GitHub 對儲存庫所掌握的資訊建立，而不是依據掃描工具讀取的檔案。 CRACI vs GitHub Advanced Security

Amazon Inspector SBOM Generator

Sbomgen 是 Amazon Inspector 本身進行映像檔、Lambda 與 EC2 掃描所使用的產生工具，以獨立的 Linux 執行檔提供。它可從容器映像檔、目錄、封存檔、掛載的磁碟區，以及編譯後的 Go 與 Rust 二進位檔讀取套件中繼資料，涵蓋作業系統套件（APK、DPKG、RPM）與 C#、Go、Java、Node.js、PHP、Python、Ruby、Rust 等程式語言，並產生 CycloneDX。它可以將 SBOM 傳送到 Amazon Inspector Scan API 以取得漏洞檢測結果，這需要 AWS 帳戶。最適合工作負載已在 AWS 上執行的團隊。注意：它只能在 Linux 上執行，而且與其他掃描工具一樣，只能找出它所讀取檔案中宣告的內容。

Safeguard

Safeguard 的 CLI 會執行 Syft 與 Grype，從儲存庫、容器映像檔與上傳的 manifest 產生 CycloneDX 與 SPDX SBOM，其平台還提供由 AI 撰寫的修正 pull request 與政策關卡。最適合希望以單一訂閱同時取得掃描與自動修正的團隊。注意：與其他掃描工具一樣，它列出的是所讀取檔案中宣告的內容。CRACI vs Safeguard

掃描產生的 SBOM 取決於什麼

將上述產生工具指向同一個儲存庫，它們會回傳不同的清單。以下是這些工具自家文件所預示的模式：

• 各工具對於什麼算是元件看法不一。每個產生工具都自行決定要信任哪些檔案、如何命名找到的內容，因此同一個儲存庫會讓每個工具產出不同的清單。
• 沒有鎖定檔，就沒有相依套件。Express 5.2.1 沒有提交任何鎖定檔，因此從鎖定檔解析相依套件的產生工具不會回報任何 npm 相依套件，只會回傳它辨識出的其他內容。
• 完全沒有 manifest。claude-code 儲存庫沒有 manifest 或鎖定檔，因此每個工具回傳的內容都是從其他檔案類型拼湊而來，反映的是工具本身，而不是專案。
• 中繼資料單薄。供應商欄位經常是空白的，因為多數產生工具都沒有這項資訊的來源。

這些工具沒有一個是壞掉的。每個工具都依設計讀取眼前的檔案。由此可知，掃描產生的 SBOM 取決於工具、其設定，以及是否有人先安裝了相依套件。Syft、Trivy 與 cdxgen 各自讀取哪些內容，請參閱開源 SBOM 產生工具遺漏了什麼。

SBOM 管理工具

Anchore Enterprise

Anchore Enterprise 以 Syft 與 Grype 為基礎，加上大型組織所需的功能：容器、原始碼與檔案系統 SBOM、經結構描述正確性驗證的匯入 SBOM、無需原始建置產物即可持續重新掃描，以及適用於 FedRAMP、NIST、CIS、PCI DSS 與 CMMC 的政策套件。它可部署在 Kubernetes、Docker Compose 或實體隔離環境中。最適合橫跨多套 CI 系統的容器機群與政府相關工作。注意：其 SBOM 描述的仍是掃描工具找到的內容，且價格採報價制。 CRACI vs Anchore

FOSSA

FOSSA 從授權合規起家：授權全文偵測、政策與歸屬聲明。它可產生與匯入 SPDX 與 CycloneDX SBOM，能加入 VDR 或 VEX 聲明，依 NTIA 與 FDA 最低要素檢查匯入的檔案，並在 Enterprise 方案中透過入口網站分享 SBOM。Free 方案涵蓋 5 個專案。最適合最關心授權風險的團隊。注意：其 CLI 在可取得可運作的建置時會查詢您的建置工具，否則從原始碼推斷，而二進位與程式碼片段掃描為附加元件。 CRACI vs FOSSA

Cybeats SBOM Studio

SBOM Studio 自稱為「SBOM 記錄系統」。它可匯入與匯出 SPDX 2.2 至 3.0.1 及 CycloneDX 1.2 至 1.7，在匯入前為 SBOM 品質評分，持續比對每一個元件，並與客戶分享 SBOM 與 VEX 資料，包括透過 Transparency Exchange API。最適合在 ICS、醫療器材、電信與汽車產業推動 SBOM 計畫的產品資安團隊。注意：它管理 SBOM，而不是產生 SBOM，而品質評分確認的是格式，而不是產生工具遺漏了什麼。 CRACI vs Cybeats與 Cybeats 替代方案

Manifest

Manifest 會收集、充實並分享您的產品、廠商與 AI 模型的 SBOM。廠商透過安全的入口網站上傳，若廠商未提供，Manifest 可以分析二進位檔並產生 SBOM。它支援 SPDX、CycloneDX 與 VEX，並對應至 FDA 指引、NIST 800-218 與 UNECE R155。最適合主要風險來自外購軟體的組織。注意：其 GitHub Action 預設使用 Syft 產生自有軟體的 SBOM。 CRACI vs Manifest

OWASP Dependency-Track

Dependency-Track 是採用 Apache 2.0 授權的平台，可追蹤每個應用程式每個版本中的元件，從 NVD 與 GitHub Advisories 等來源取得漏洞資料，套用資安、授權與營運政策，並能使用與產生 CycloneDX VEX。管線透過其 API 上傳 SBOM。最適合希望使用透明、自架分析平台的團隊。注意：它不產生 SBOM，而且需要您自行運作（API 伺服器至少需要 2 GB RAM 與 2 個 CPU 核心）。 給 Dependency-Track 使用者的 CRACI

CycloneDX 還是 SPDX

兩種格式都是開放標準，本頁大多數工具至少能產生其中一種。CycloneDX 是 OWASP 專案，已由 Ecma International 標準化為 ECMA-424，除了元件清單之外，還能承載漏洞與 VEX 資料。SPDX 是 Linux Foundation 專案，也是國際標準 ISO/IEC 5962:2021。Cyber Resilience Act 要求「常用且機器可讀的格式」，但並未指定任何一種，因此請選擇您的客戶與下游工具能讀取的格式。兩者的並列範例請參閱 SBOM 範例，運用方式請參閱 SBOM 最佳實務。大規模儲存與監控 SBOM，請參閱 SBOM 管理。

CRACI 的定位

CRACI 既不是掃描工具，也不是管理工具，而是記錄工具。您的 GitHub Actions 作業在 CRACI 執行器上執行（將 runs-on 改為 craci），具備套件感知能力的代理伺服器會記錄每個作業從 npm、PyPI、RubyGems、Composer、Cargo、Go、Nix、OCI、apt、apk 與 Git 來源，以及下載預設組態取用的內容。從 CI 快取還原的套件會延續其佐證資料。CycloneDX 或 SPDX 格式的 SBOM 包含建置使用的遞移相依套件，並標示每個作業與每個快取的完整性：Complete、Complete with connections、Incomplete、Unavailable 或 Not recorded。 CRACI 的資產清冊檢視會在全球範圍內，精確顯示哪些軟體版本部署到哪些產品。

建置完成後，CRACI 會持續重新評估受監控的 SBOM、跨建置與儲存庫彙整漏洞、支援 VEX、透過其 API 回傳 SBOM、網路追蹤記錄與來源證明，並將 SBOM 匯出為 CycloneDX 或 SPDX 檔案。您也可以加入廠商 SBOM，讓外購的元件與您自己的建置一併監控。它可自動化企業在更廣泛的 CRA 法規遵循流程中所需之軟體供應鏈可視性與佐證資料中相當大的一部分。完整功能請參閱 CRACI 的 SBOM 產生。

因此，就您所建置的軟體而言，CRACI 同時扮演產生工具與管理工具的角色。在以下情況，它並不是合適的選擇：

• 您需要為並非您建置的映像檔或軟體產生 SBOM（請使用 Syft 或 Trivy 等產生工具），
• 您需要一套成熟的政策引擎，能在產品與供應商組合中套用多種規則類型（請使用管理工具），
• 您的管線在 GitHub Actions 以外、在 Windows 或 macOS 上執行，或必須自架（皆已列入 CRACI 的產品藍圖）。

最快的判斷方式是並列比較：預約示範，在 CRACI 上執行您的一個工作流程，並將它的 SBOM 與您目前工具產生的 SBOM 並列。

另請參閱 SCA 工具比較、 AI 產生的 SBOM 與建置時 SBOM，以及 為什麼建置時 SBOM 與掃描產生的 SBOM 不同。

SBOM 工具：常見問題

什麼是 SBOM 工具？

SBOM 工具用於產生或管理軟體物料清單（SBOM）：一份機器可讀的清單，列出軟體中的元件、函式庫與相依套件。Syft、Trivy 與 cdxgen 等產生工具透過讀取檔案來撰寫 SBOM。Dependency-Track、FOSSA 與 Anchore Enterprise 等管理工具則負責儲存 SBOM、將其與漏洞資料比對並加以分享。CRACI 則在建置本身進行期間記錄 SBOM，並在之後持續監控。

最好的免費 SBOM 工具是哪一個？

取決於您要用它分析什麼。Syft 與 Trivy 是免費、採用 Apache-2.0 授權的產生工具，適用於容器映像檔與檔案系統。cdxgen 可從原始碼與映像檔產生 CycloneDX。Microsoft SBOM Tool 會為建置產出資料夾產生 SPDX。OWASP Dependency-Track 則是免費的自架管理工具，用於管理上述工具產生的 SBOM。

應該使用 Syft 還是 Trivy？

Syft 專注於 SBOM 產生，並搭配 Grype 進行漏洞比對。Trivy 是範圍更廣的掃描工具，還能找出 IaC 錯誤組態、機密與授權，並順帶產生 CycloneDX 或 SPDX。兩者都讀取眼前的檔案，因此都取決於鎖定檔或已安裝的套件是否存在。

CycloneDX 還是 SPDX：應該使用哪種 SBOM 格式？

兩者都是開放且受到廣泛支援的標準。CycloneDX 是 OWASP 專案，已由 Ecma International 標準化為 ECMA-424，也能承載漏洞與 VEX 資料。SPDX 是 Linux Foundation 專案，也是國際標準 ISO/IEC 5962:2021。請使用您的客戶與下游工具所要求的格式；多數產生工具兩種格式都能產生。

為什麼不同 SBOM 工具對同一個專案會產生不同結果？

每個產生工具都自行決定要信任哪些檔案、什麼算是元件。有些讀取鎖定檔，有些讀取已安裝的套件，有些讀取二進位檔；而沒有鎖定檔的儲存庫，會讓讀取鎖定檔的工具無從下手。掃描產生的 SBOM 取決於工具、其設定，以及掃描前是否已安裝相依套件。建置時 SBOM 則透過記錄建置實際取用的內容，避免了這個問題。

Cyber Resilience Act 是否要求特定的 SBOM 工具或格式？

否。CRA 附件 I 第 II 部分要求製造商以常用且機器可讀的格式製作軟體物料清單，至少涵蓋產品的最上層相依套件。CycloneDX 與 SPDX 皆符合要求。法規並未指定任何工具。

CRACI 能為並非我建置的軟體產生 SBOM 嗎？

不能。CRACI 記錄的是在其執行器上執行的建置，因此其 SBOM 描述的是您建置的軟體。對於您購買的軟體，您可以將廠商的 SBOM 加入 CRACI，與您自己的建置一併監控。對於並非您建置的第三方容器映像檔，Syft 或 Trivy 等掃描工具是實際可行的選擇。

CRACI 支援哪些 CI 系統？

目前支援 GitHub Actions，執行器為 Linux x86-64 與 ARM64。您將 runs-on 改為 craci，執行紀錄仍會顯示在 GitHub 中。其他 CI 系統已列入產品藍圖，首先是 GitLab CI 與 Jenkins。