技術解説·2026年6月11日

SBOM ツール比較 — 脆弱性とライセンス遵守を 1 枚の部品表で管理する

取引先から「SBOM を出して」と言われたら何をどう出すか。SPDX / CycloneDX の現在地、Syft・Trivy・Grype など主要 10 ツールの役割地図と価格の型、規模別(個人 → 中小 → 中堅)の現実解、コピペできる CI 構成と導入チェックリストまで、無料 OSS 中心で整理する実務ガイド。

SBOMOSSライセンス脆弱性管理CI/CDSPDX

この記事の要点

核心: (ソフトウェア部品表)を巡るツール選びは、「ライセンス遵守」と「脆弱性検知」の二本柱に分解し、生成 / 検知 / 精密ライセンス / という役割の地図で考えると迷いません。単機能の紹介を並べるのではなく、自動化したいことから逆算します。
対象読者: 取引先や調達から「SBOM を出してほしい」と言われた企業の実務担当(製造業 IT 部門など)が主役です。公開や受託で先回りしたい個人開発・副業の方にも、無料ツールだけで組める最小構成として使えます。
得られる成果: SBOM の 2 大フォーマット( / CycloneDX)の現在地 / 主要 10 ツールの役割地図と価格の型 / 規模別(個人 → 中小 → 中堅)の現実解 / コピペできる CI 構成イメージと導入チェックリスト。
扱わないこと(専門家・公式情報、または別記事へ): ライセンス条文の法的な読み方(OSS ライセンスの見極め)/ 個別ツールの導入手順書 / 価格の確定額の網羅(改定が速いため「型」中心)/ 社内規程テンプレ(OSS ライセンス社内ポリシーの作り方)。

Key Points (for international readers)

Core — Choosing SBOM (Software Bill of Materials) tooling gets simple once you split the job into two pillars — license compliance and vulnerability detection — and read tools by role: generators, scanners, license-precision tools, and SaaS platforms. Work backward from what you want to automate, not from feature lists.
Who this is for — corporate practitioners asked by customers or procurement to "provide an SBOM," and indie developers who want to get ahead with free tooling.
Portable takeaway — the two-pillar frame, the role map of ten tools, and the CI recipe are jurisdiction-neutral. Drivers differ: this Japanese edition covers Japan's context; the English edition covers the US (EO 14028) and the EU (CRA).
What's out of scope — the legal reading of license texts (OSS licenses) / step-by-step install guides / exhaustive current pricing (it changes quarterly) / internal policy templates (building an OSS license policy).

執筆時点: 2026-06 / 対象: ツールと規格は法域に中立・制度の駆動力のみ日本国内向け / last_updated: 2026-06-11 更新履歴: 2026-06-11 初版公開

本記事は教材であり、特定組織の導入助言ではない

本記事は SBOM とその周辺ツールを整理するための一般的な解説であり、特定のシステム・組織に対する導入助言や監査・法務判断の代替ではありません。内容の正確性・完全性・最新性を保証するものではなく、ツールの機能・対応フォーマット・価格・プラン名は改定で変わります(SaaS の価格は特に変動が速く、本文は確定額でなく課金の型を中心に記述しています)。実際の選定・契約・運用の判断は、必ず社内の法務 / セキュリティ部門・専門家・各ツールの公式ドキュメントと最新の価格ページにご確認ください。本記事の情報は「現状有姿(AS IS)」で提供され、これを利用または信頼した結果生じたいかなる損害・損失についても、執筆者および YATA-NODE は一切の責任を負いません。ご利用は自己責任でお願いします。

本記事の位置づけ: 本記事は OSS を使う前のライセンス見極めの「運用編」です。ライセンス記事が「条文をどう読むか(知識)」を扱ったのに対し、本記事は「その遵守と脆弱性管理をツールでどう自動化するか(運用)」を扱います。また仮想化とサンドボックス入門で予告したコンテナイメージの供給網(SBOM・スキャン)の各論でもあります。

用語ミニ解説(はじめての方へ): 本記事で繰り返し出る言葉の最小限の説明です。

SBOM(Software Bill of Materials): ソフトウェアに含まれる全部品(ライブラリ・パッケージ)とそのバージョン・ライセンスを列挙した「部品表」。製造業の部品表(BOM)のソフトウェア版です。
SCA(Software Composition Analysis): 依存ライブラリを解析して脆弱性やライセンスを検査する手法・ツールの総称。
コピーレフト: 派生物を配布するときに、ソース提供や同一ライセンス適用の義務が生じうる性質(GPL / AGPL など。AGPL はネットワーク経由の利用にも条件が及びます)。詳しくはライセンス記事へ。
OSV: Google が運営する OSS 脆弱性データベース。複数の脆弱性情報源を統合しています。
CI(継続的インテグレーション / Continuous Integration): コードの変更を頻繁に統合し、ビルド・テスト・検査を自動で回す仕組み・工程。SBOM 生成やスキャンもここに組み込みます。
デューデリジェンス: 取引や買収(M&A)の前に、対象の資産・リスク(ここでは使用 OSS とそのライセンス・脆弱性)を精査する調査。

「取引先から SBOM の提出を求められたが、何をどう出せばいいのか分からない」。こうした SBOM の提出要求は、後述する制度(米国 EO 14028・EU CRA など)の広がりとともに増えています。結論から言うと、SBOM 対応は ①部品表を生成する ②それをライセンスと脆弱性の 2 つのレンズで点検するという 2 段に分解でき、どちらも無料の OSS ツールで始められます。本記事は、①まず SBOM とは何で、なぜ急に要求されるようになったかを押さえ ②自動化したいことを「ライセンス遵守」と「脆弱性検知」の二本柱に整理し ③主要 10 ツールを役割の地図に並べ ④規模別の現実解と CI 構成に落とし ⑤最後に要求の出どころ(制度)を置きます。ツール名の暗記ではなく「何を自動化したいか」から、自分の構成を選べるようになりましょう。

SBOM とは — ソフトウェアにも「部品表」が要求される時代

SBOM は、ソフトウェアに含まれる全コンポーネント(OSS ライブラリ、パッケージ、そのバージョンとライセンス)を列挙した部品表です。製造業で部品表(BOM)が品質管理・リコール対応の基盤であるのと同じように、ソフトウェアでも「中に何が入っているか」を機械可読な形で示すことが、調達や取引の場面で求められることが増えています。きっかけとして大きいのは米国の大統領令 EO 14028(2021 年)で、連邦政府調達を中心とした指示ですが、実務では民間の取引や M&A のデューデリジェンスでも要求に出会います(制度の詳細は最終章で触れます)。

フォーマットは事実上 2 つに集約されています。

SPDX(Linux Foundation): 広く実装されているのは SPDX 2.3。最新の SPDX 3.0 では AI Profile / Dataset Profile(AI モデルやデータセットの部品表化)が加わっています。
CycloneDX(OWASP): ECMA-424 として国際標準化されており、仕様の最新版は 1.7(ECMA-424 第 2 版)。ML-BOM(機械学習 BOM)や VEX(脆弱性の悪用可能性情報)などの拡張が先行しています。ただしツール側の実装は 1.6 までの対応が中心で、仕様の最新版への追従には遅れがあります。

実務の結論はシンプルです: 迷ったら SPDX 2.3 と CycloneDX 1.6 の両方を出せるツールを選ぶ。提出先がどちらを指定してきても対応でき、フォーマット論争に巻き込まれずに済みます。

何を自動化したいのか — 「ライセンス遵守」と「脆弱性検知」の二本柱

SBOM ツールの比較記事は機能の羅列になりがちですが、実務で自動化したいことは突き詰めると 2 つです。

柱 1: ライセンス遵守。OSS を製品に組み込んで配布するとき、ライセンスごとの義務(表示・通知・ソース開示)を果たす必要があります。自動化したいのは主に:

NOTICE / 帰属表示の集約: Apache 2.0 などが求める通知文を、依存全体から漏れなく集めて配布物に同梱する
コピーレフトの早期検知: / のライブラリが依存に紛れ込んだ時点でアラートを出す(リリース直前に発覚すると手戻りが大きい)

なぜこれが要るのかという法的な背景(結合形態と公開義務の関係)は OSS ライセンス記事で整理しています。本記事はその「検知と集約を機械にやらせる」側です。

柱 2: 脆弱性検知。依存ライブラリの既知脆弱性(CVE)を、CI で継続的に検出します。自動化したいのは:

依存全体のスキャン: ロックファイル・コンテナイメージ・ファイルシステムを横断して既知脆弱性を照合する
優先度付け: 検出された脆弱性のうち「実際に危ないもの」から直す(EPSS スコアや CISA KEV カタログでの絞り込み)

2 つの柱は同じ SBOM(部品表)を入力にできるため、「生成は 1 回、点検は 2 つのレンズで」が効率的な構図になります。そして重要なのは、1 つのツールで両方を完璧にこなせるものは(無料の範囲には)ないことです。だから次章の「役割の地図」が要ります。

ツールの地図 — 役割で並べる主要 10 種

主要ツールを「何の役割を担うか」で 4 グループに分けます。価格は改定が速いため、確定額ではなく課金の型で示します(導入時に各公式の価格ページで最新を確認してください)。

役割	ツール	型	ひとことで
生成(部品表を作る)	Syft	無料 OSS	広く使われる SBOM 生成 OSS。SPDX 2.3 / CycloneDX 1.6 を両方出せる
	CycloneDX 純正ジェネレータ群	無料 OSS	仕様策定団体の純正実装。検証・署名・マージの後処理にも
検知(部品表を点検する)	Trivy	無料 OSS	脆弱性 + ライセンス分類 + IaC + シークレットのオールインワン。GPL / AGPL を自動で高リスク分類
	Grype	無料 OSS	Syft とペアの脆弱性スキャナ。EPSS / KEV での優先度付け内蔵
	OSV-Scanner	無料 OSS	Google の OSV 一次データに直結。ロックファイルのカバレッジが広い
精密ライセンス	ScanCode-toolkit	無料 OSS	全文照合による詳細なライセンス検出に強い。NOTICE / 帰属レポート作成に使える
SaaS(統合管理)	GitHub(Dependency Graph / Dependabot)	無料〜per-committer 課金	GitHub 上なら追加設定ほぼゼロ。SBOM エクスポートも標準
	Snyk	無料枠〜per-dev 課金	UI が洗練。到達可能性解析で誤検知を抑制。SBOM 生成は上位プラン
	FOSSA	無料枠〜per-project 課金	ライセンス義務追跡(NOTICE 自動収集)に特化した SaaS。機能とプランの対応は最新の価格ページで確認
	Black Duck	個別見積	エンタープライズ / M&A デューデリ向けの選択肢

この地図の読み方を 3 点だけ補足します。

生成と検知は分業が基本。Syft(生成)+ Grype(検知)は同じ提供元のペアで、生成済み SBOM への再スキャンが速い構成です。Trivy は単体で生成も検知もこなすオールインワンですが、CycloneDX 出力は 1.5 まで(JSON 限定、執筆時点)という制約があります。
NOTICE の自動集約は無料 OSS の弱点。Apache 2.0 の NOTICE を自動で集めて帰属レポートにする機能は、FOSSA / Black Duck(SaaS)が標準提供しており、無料側では ScanCode-toolkit のテンプレート出力で近いことができます。Syft / Trivy は SBOM にライセンス情報を記録はしますが、NOTICE ファイルの自動生成までは持ちません。
コピーレフトの自動アラートは Trivy が無料側の代表。GPL-2.0 / 3.0 / AGPL を Restricted / Forbidden に自動分類して HIGH / CRITICAL 扱いにします。OSV-Scanner は SPDX ID の許可リスト方式で違反を検知します。

規模別の現実解 — どこまで無料で、どこから課金か

役割の地図を、規模別の「まずこれ」に落とします。

規模	構成	ねらい
個人 / フリーランス	Dependabot(GitHub 無料)+ Trivy(CLI)	脆弱性アラートと自動修正 PR を無料で常時化。Trivy でライセンス分類も
中小(〜50 名)	+ Syft + OSV-Scanner(CI 組込み)+ ScanCode-toolkit(リリース前バッチ)	SBOM の正式生成と二段スキャン、NOTICE 集約をリリース工程に
中堅(50〜500 名)	+ GitHub Code Security(対象リポジトリを絞って導入)+ FOSSA(法務向けにプロジェクト単位)	修正自動化の強化と、法務サインオフに耐える義務追跡
エンタープライズ(500 名超)	Black Duck / Snyk Enterprise を主軸に切替検討	M&A・規制業界の網羅性要件

CI への組み込みは、次の 3 段が出発点になります(GitHub Actions の構成イメージ。バージョンや引数は各公式 doc の最新で確認してください)。

yaml

# 構成イメージ: SBOM 生成 → 脆弱性 + ライセンス点検(三段)
jobs:
  sbom-and-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      # 1. Syft で SBOM 生成(SPDX 2.3)
      - uses: anchore/sbom-action@v0
        with: { format: spdx-json, output-file: sbom.spdx.json }
      # 2. Trivy で脆弱性 + ライセンス + シークレット
      - uses: aquasecurity/trivy-action@master
        with: { scan-type: fs, scanners: "vuln,secret,license", severity: "HIGH,CRITICAL" }
      # 3. OSV-Scanner でロックファイル + ライセンス許可リスト
      - uses: google/osv-scanner-action@v2
        with:
          scan-args: |-
            --recursive
            --licenses=Apache-2.0,MIT,BSD-3-Clause,ISC
            ./

導入の点検には、以下を貼り付けて使えます。

text

【SBOM 導入チェック】
□ 提出先のフォーマット指定を確認したか(SPDX / CycloneDX / 指定なし)
□ SBOM 生成を CI に入れたか(ビルドごとに自動生成 = 手作業で作らない)
□ コピーレフト(GPL / AGPL)検知をアラート化したか
□ NOTICE / 帰属表示の集約手段を決めたか(ScanCode バッチ or SaaS)
□ 脆弱性の優先度付け基準を決めたか(HIGH/CRITICAL のみゲート、EPSS / KEV で絞る等)
□ SBOM の保管場所と提出フローを決めたか(リリースごとに保存 = 後から「どの版が影響を受けるか」を調査可能に)
□ SaaS を使う場合、価格・プラン条件を契約前に最新の公式ページで確認したか

要求の出どころ — なぜ SBOM を求められるのか

最後に、SBOM 要求がどこから来ているかを短く整理します(ツール選定には直接効きませんが、「なぜ急に」の答えとして)。

米国: 大統領令 EO 14028(2021 年)が連邦政府調達でのソフトウェア供給網セキュリティ強化を指示し、SBOM が政府調達の文脈で標準語彙になりました。米国に納める製品・サービスがなくても、実務では大手取引先の調達基準を通じて要求が届くことがあります(法的義務というより取引慣行としての波及です)。
EU: Cyber Resilience Act(CRA、Regulation (EU) 2024/2847)が「デジタル要素を持つ製品」の製造者に供給網の注意義務(組み込むコンポーネントの管理)を課します(報告義務は 2026-09-11、主要義務は 2027-12-11 から段階適用)。CRA が SBOM を一律に義務化するという単純な話ではありませんが、部品の把握 = SBOM 的な管理が事実上の前提になっていきます(米国・EU の制度詳細は本記事の英語版で扱います)。
日本: 政府調達や大手企業のサプライチェーン管理を通じて、取引条件としての SBOM 提出要求が広がりつつあります。経済産業省も SBOM 導入に関する手引を公開しており、国内でも「提出を求める側」の共通言語が整い始めています。

個人開発の範囲では義務になる場面はまずありませんが、受託や法人取引で「SBOM を出せますか」と聞かれたとき、無料 OSS の範囲で即答できることが本記事の構成の価値です。

まとめ

SBOM 対応は「①部品表を生成する ②ライセンスと脆弱性の 2 つのレンズで点検する」に分解でき、生成 = Syft、検知 = Trivy / Grype / OSV-Scanner、精密ライセンス = ScanCode という無料 OSS の役割分担で始められる、というのが本記事の地図でした。規模が大きくなったら、NOTICE 義務追跡(FOSSA)や修正自動化(GitHub Code Security)を必要な範囲だけ課金で重ねます。導入チェックリスト(前章)をコピーして、自分の構成の点検にお使いください。