SBOM規制一覧表あり｜SBOMとは？注目の背景、導入メリット、SBOM管理ツールの選び方について解説
SBOM（エスボム）とは「Software Bill of Materials」の略で、製品に含まれるソフトウェアを構成するオープンソースソフトウェア（OSS）やサードパーティ製のアプリライブラリなどの依存関係、バージョン、ライセンス情報をリスト化したものです。日本語では「ソフトウェア部品表」と訳されます。
近年、ソフトウェアサプライチェーンを狙った攻撃が増加したり、各国がSBOM対応に関する法規制やレギュレーションを進めていることから、全ての企業でSBOM対応が必要となってきています。
この記事では、「SBOMとは」「SBOMが注目される背景」「SBOM導入のメリット」「SBOM作成・管理ツールの選び方」について解説します。
SBOM関連の規制・ガイダンス動向をまとめた一覧表も記載しているので、ぜひ最後までご覧ください。
- この記事の要約
-
SBOM（ソフトウェア部品表）とは、ソフトウェアを構成するOSSやライブラリの依存関係をリスト化したデータのこと。サプライチェーン攻撃の急増や、米国大統領令・EUのCRA（サイバーレジリエンス法）といった世界的な法規制強化を背景に、導入が推進されています。
-
SBOMには「SPDX」や「CycloneDX」といった標準フォーマットがあり、SBOM管理ツールを導入することで、「脆弱性対応の迅速化」「サプライチェーンリスクの可視化」「ライセンス違反の防止」といったメリットが得られます。
-
経済産業省の手引書に唯一の国産有償ツールとして紹介されている、脆弱性管理クラウド「yamory（ヤモリー）」は、特許取得のオートトリアージ機能や手厚いサポートなどを備えた、世界基準に対応できる国産のSBOM管理ツールです。
目次[非表示]
SBOMとは？
冒頭で説明した通り、SBOMとは、製品に含まれるソフトウェアを構成するコンポーネント、サードパーティ製のライブラリ、およびそれらの依存関係をリスト化したものです。各コンポーネントのバージョンやライセンス情報も詳細に記録されており、主にソフトウェアの脆弱性管理やライセンスコンプライアンスの確保に使用されます。
ソフトウェアの部品表って？
ソフトウェア部品表（SBOM）の説明は、身近な食品の「原材料表示」に例えると非常に分かりやすくなります。
例えば、「マカロニサラダ」を作るには、マカロニ、マヨネーズ、きゅうりなどの「材料」が必要です。さらに遡れば、マカロニは小麦から、マヨネーズは卵から作られています。どのメーカーの、どの材料を使っているかを正確に管理するリスト（原材料表示）がなければ、万が一、材料の「小麦」に異物混入などの問題が見つかった際、どの商品を回収すべきか判断できず、食の安全を守れません。
食品サプライチェーンと食品表示の関係
（出展：ソフトウェア管理に向けたSBOM（Software Bill of Materials）の導入に関する手引Ver. 1.0）
ソフトウェアもこれと全く同じです。 現代のソフトウェア開発では、ゼロからすべてを作るのではなく、世界中で公開されているOSS（オープンソースソフトウェア）や、サードパーティ製のライブラリといった「既存の部品（材料）」を組み合わせて構築するのが一般的です。
これらの部品情報をSBOMとしてリスト化しておくことで、万が一特定の部品に脆弱性が見つかった際に、即座に「自社製品にそれが含まれているか」を特定し、対処することが可能になります。
ソフトウェアサプライチェーンとSBOMの関係
SBOMが注目されている背景
SBOMが注目されている背景として、
- サプライチェーン攻撃の急増
- 米国大統領令によるSBOMの義務化
- 経済産業省が「ソフトウェア管理に向けたSBOMの導入に関する手引」を発行
の3つがあります。
ソフトウェアサプライチェーン攻撃の急増
かつてのサイバー攻撃は、企業のネットワーク境界など「入り口」を狙うものが主流でした。しかし、ファイアウォールなどの防御技術が強固になるにつれ、近年はソフトウェアの構成部品である「OSS（オープンソースソフトウェア）」の脆弱性を狙ったサプライチェーン攻撃（※）が急増しています。
そういった中、対策の鍵としてSBOMが注目されています。なぜなら、攻撃被害が拡大する根本的な原因が、多くの企業が「自社で利用するソフトウェアに、どのようなOSSが含まれているか」を把握できていない、ブラックボックス状態にあるためです。利用しているOSSが不明であれば、脆弱性が見つかっても修正パッチを当てることすらできません。
SBOMは、このブラックボックスを解消し、ソフトウェアの「構成要素」を可視化します。これを整備することで、サプライチェーン上で新たな脆弱性が発覚した際、「自社は影響を受けるか」を即座に特定し、迅速なリスク対応を取ることが可能になります。
(※)ターゲット企業が利用するソフトウェア製品やOSSの脆弱性を悪用したり、 開発プロセスに侵入して正規のアップデートプログラムにマルウェアを仕込むなど、供給網（サプライチェーン）を介して行われる攻撃のこと。
米国大統領令によるSBOM対応の義務化
SBOM対応の世界的な流れを決定づけたのが、2021年5月に発効された「米国大統領令 14028号（国家のサイバーセキュリティ強化に関する大統領令）」です。
これは、SolarWinds事件（2020年）のような大規模なソフトウェア・サプライチェーン攻撃が国家安全保障上の重大な脅威と認識されたことを受けて発令されました。
この大統領令によって、米国連邦政府（国防総省、各省庁など）にソフトウェアを納入するときは、ソフトウェアの透明性を確保するために「SBOM」を提出することが、政府調達の要件として事実上義務付けられました。
また、その他にも、国内外問わずに様々な業界で、SBOM対応の義務化や推進が進められています。
規制／ガイダンス | 概要 | 動向 |
|---|---|---|
米国大統領令 14028（EO 14028） | サイバーセキュリティ強化を目的に発行された米国大統領令。 | 2021年5月の署名。米国連邦政府にソフトウェアを納入するベンダーに対し、SBOMの提出を事実上義務化。 |
UN-R155 / 156 | 車両のサイバーセキュリティ（UN-R155）とソフトウェアアップデート（UN-R156）に関する国連法規。 | 2022年7月以降の新型車に順次適用。SBOMは、法規が要求するライフサイクル全体の脆弱性管理を効率化する手段として不可欠とみなされている。 |
PCI-DSS v4.0 | クレジットカード業界のグローバルセキュリティ基準。 | v4.0ではソフトウェアコンポーネントの管理が重視され、2025年3月までにSBOMへの対応が求められている。 |
EUサイバーレジリエンス法（CRA） | EU市場で販売される「デジタル製品」のセキュリティを強化するための法律。 | 2024年12月11日に法律が成立。2027年12月11日までに、SBOMの作成・提供を含むCRAの全ての要件を満たしていない製品は、CEマーキングを貼付できず、EU市場での販売が禁止となる。 |
IMDRFサイバーセキュリティガイダンス 薬機法 | 医療機器のサイバーセキュリティに関する国際的なガイダンス。 | 2023年の改訂でSBOMの作成と提供を明確に推奨。医療機関への透明性確保とライフサイクル管理に不可欠とされている。 |
SBOM関連の主要な規制・ガイダンス動向一覧
SBOM・脆弱性の一元管理なら
「yamory」におまかせ
脆弱性・EOL・OSSライセンスを一元管理
SBOM・法規制に対応
国産の脆弱性管理ツール
経済産業省が「ソフトウェア管理に向けたSBOMの導入に関する手引」を発行
日本でも、世界のSBOM対応の流れを受けて、2023年7月に経済産業省による「ソフトウェア管理に向けたSBOM（Software Bill of Materials）の導入に関する手引 Ver.1.0」が策定されました。また、その後アップデートが加えられて、2024年8月に「ソフトウェア管理に向けたSBOM（Software Bill of Materials）の導入に関する手引 ver 2.0」（※）が策定されました。
この手引書には、SBOMを導入するメリットをはじめ、導入する際に認識・実施すべきポイントがまとめられています。
※参照元：経済産業省「ソフトウェア管理に向けたSBOM（Software Bill of Materials）の導入に関する手引 ver 2.0」
「ソフトウェア管理に向けたSBOM（Software Bill of Materials）の導入に関する手引 ver 2.0」にて、弊社が提供する脆弱性管理クラウド「yamory」が、「SBOMの作成や運用・管理に資する代表的なツール」の有償サービス内、唯一の国産ツールとして紹介されています。
SBOMの代表的なフォーマット
世界的に最も広く採用されており、業界標準として認められているSBOMの代表的なフォーマットを2つ紹介します。
SPDX（Software Package Data Exchange）
Linux Foundationのプロジェクトとして始まったSPDX（Software Package Data Exchange）は、ソフトウェア部品表（SBOM）を記述・交換するためのオープンな標準規格です。ISO/IEC 5962:2021として国際標準にも認定されており、ソフトウェアに含まれるコンポーネント、ライセンス、著作権、セキュリティ情報などを網羅的に記述するために設計されています。
特徴
- 詳細なライセンス記述ができる
- パッケージ全体の「宣言されたライセンス（Declared）」と、実際のコード解析等から「結論付けられたライセンス（Concluded）」を区別して記述できるため、実態に即した管理が可能。
- 法務・資産管理に強い
- 著作権者（Copyright）やファイルの出所を明確にするフィールドが充実しており、知財保護やソフトウェア資産の長期的な管理に最適。
- 厳密な関係が定義できる
- コンポーネント間の「依存（Depends On）」だけでなく、「ビルドに使用（Build Tool Of）」や「テストに使用（Test Case Of）」など、多様な関係性を厳密に定義可能。
対応領域
- 厳格なライセンスコンプライアンスが求められる業界（自動車、医療、金融など）
- 政府調達やグローバルな企業間取引
- ソフトウェア資産の長期的な法的管理・構成管理
CycloneDX
CycloneDXはOWASP（Open Web Application Security Project）コミュニティで推進されている、軽量なSBOM標準規格です。法務的なコンプライアンス遵守を重視して発展したSPDXとは対照的に、CycloneDXは現代の開発における技術的・セキュリティ的な課題解決を起点とし、開発現場でのリスク管理と迅速な利用を最優先に設計されています。
特徴
- 高い脆弱性管理能力
- VEX（Vulnerability Exploitability eXchange）などの仕組みと連携し、「脆弱性の有無」だけでなく「その脆弱性が自社製品で実際に悪用可能か（影響があるか）」を効率的に管理。
- 軽量性とツールとの親和性
- JSON、XML、Protocol Buffersといったモダンなデータ形式をサポートし、CI/CDパイプラインへの組み込みやツールによる自動生成・解析が容易。
- 広範なコンポーネント定義
- 従来のソフトウェアライブラリに加え、ハードウェア（HSBOM）、SaaS、機械学習モデル（ML-BOM）など、現代のシステム全体を構成する要素を幅広くサポート。
対応領域
- DevSecOpsパイプラインにおける継続的な脆弱性スキャン
- セキュリティインシデントへの迅速な対応
- SaaSやIoTデバイスを含む、モダンなITインフラの構成・リスク管理
SBOM管理ツール導入のメリット
次に、SBOM管理ツール導入によるメリットについて解説します。
安定で効率的な脆弱性管理が可能になる
SBOM管理ツールを導入すれば、新たにLog4shellのような広範囲に影響するような脆弱性が発見された際に、脆弱性データベースと照合し、自社システムがその影響を受けるかどうかを特定することができます。
また、古くなったコンポーネントや、サポートが終了したライブラリ（EOL）も特定できるようになります。これにより、技術的な負債を減らし、安定性を維持した効率的な脆弱性管理が可能になります。
ソフトウェアサプライチェーンのセキュリティ強化ができる
ソフトウェアの開発やデプロイ、保守など、開発ライフサイクルに関わる構成要素の全体をソフトウェアサプライチェーンといいます。
近年のソフトウェアは、サードパーティ製のコンポーネントを組み合わせて開発されるのが一般的です。これにより開発は効率化しましたが、同時にサプライチェーンが複雑化し、依存関係のブラックボックス化や、そこを狙ったサプライチェーン攻撃が問題になっています。
SBOM管理ツールを活用して複雑な依存関係を可視化することで、「自社ソフトウェアに直接・間接を問わず、脆弱な依存関係が含まれているか」を特定できるようになります。これにより、ブラックボックス化していたリスクを解消し、サプライチェーン全体のセキュリティを強化できます。
ライセンス情報の可視化と管理ができる
ソフトウェア開発で利用されるOSSには様々なライセンス形態があり、意図せずライセンス違反をしてしまうリスクがあります。
SBOM管理ツールでは、各コンポーネントのライセンス情報を収集しリスト化できるため、使用しているコンポーネントが自社のポリシーや製品の要件に準拠しているかを簡単に確認することができます。また、禁止されたライセンスが含まれていた場合にアラートを出すなどの運用も可能になり、法的なリスクを回避することができます。
SBOM管理ツールを選ぶポイント
SBOM管理ツールはどれでも良いというわけではありません。今後、SBOMの導入・管理は、脆弱性への対策とセットで考えることが不可欠となっており、それらを見据えたツール選びが極めて重要になります。
この章では、SBOM管理ツールを選ぶ上で押さえておくべきポイントを解説します。
世界基準のコンプライアンスに対応できているか
ツールの機能が「SBOMを作って保存する」だけでは不十分です。すでに、欧州のCRA（サイバーレジリエンス法）のような世界的な規制は、SBOMを開発・運用のプロセスに統合し、継続的に脆弱性管理を行うことを求めています。そのため、SPDXやCycloneDXといった国際標準フォーマットでの出力・管理に対応し、グローバルな規制要件を満たせるかが重要な選定基準となります。
SBOMをエクスポート・インポートできるか
SBOMは、自社システムのみで管理するだけでなく、サプライチェーン全体で情報を連携・共有するために使われます。エクスポート機能は、顧客や規制当局から提出を求められた際に必須となり、逆にインポート機能は、サプライヤーから受け取ったSBOMを自社の管理システムに取り込むために不可欠です。 この「双方向の連携」ができなければ、サプライチェーンの透明性を確保するというSBOM本来の目的を達成できません。標準フォーマットでのスムーズな入出力が可能かを必ずチェックしましょう。
検出だけでなく「自動優先順位付け（オートトリアージ）」機能が備わっているか
高性能なツールは多くの脆弱性を検出できますが、単に検出するだけでは、「検出した脆弱性情報の数が膨大になり、どれから対応するべきかの判断に工数がかかる」という問題に直面します。
そこで重要になるのが、「対応の自動優先順位付け（オートトリアージ）」機能です。検出した脆弱性情報と、自社のシステム環境を自動で分析し、実質的なリスクを検出・評価してくれる機能があるかどうかが、運用工数を削減する鍵となります。
誰でも使いやすいツールか
SBOM管理はセキュリティ担当者だけでなく、開発者や法務担当など多くの人が関わります。ツールが複雑で特定の人しか使えないと「属人化」を招き、組織全体を通した継続的な運用が困難になります。ダッシュボードの見やすさや直感的な操作感、アラート内容の分かりやすさなど、現場の誰もが使いこなせるUI/UXであることが重要です。
柔軟なサポート体制が整っているか
SBOMと脆弱性管理は、導入して終わりではなく、安定的な運用が求められます。特に緊急性の高い問題が起こった時、「すぐ対応してもらえるか」は極めて重要です。
海外製ツールの場合、サポートが英語対応のみで意思疎通に工数がかかったり、時差で対応が遅れたりする懸念があります。
日本人エンジニアによる日本語のサポートが受けられるか、また国内の法規制や日本に準拠した対応が期待できるかは、安定運用のための大きな選定ポイントとなります。
国産SBOM管理ツールなら「yamory」
ここまで解説した「SBOM管理ツールを選ぶポイント」をすべて網羅し、セキュリティ対策を強力にサポートするのが、脆弱性管理クラウド「yamory（ヤモリー）」です。
世界基準のSBOM作成・管理に対応可能
yamoryは、SPDXやCycloneDXといったフォーマットで、SBOMのインポート・エクスポートに対応。これにより、自社でのSBOM作成・管理はもちろん、サプライヤーとの連携もスムーズに行えます。 また、PCI-DSSやサイバーレジリエンス法（CRA）など、世界的に厳格化する法規制やレギュレーションに準拠した脆弱性管理体制の構築も支援します。
特許の「オートトリアージ機能」で運用を効率化
yamoryが特許を取得している「オートトリアージ機能」は、攻撃コードの有無や実行可能性などを多角的に分析し、本当に対応が必要な脆弱性だけを自動で判定します。これにより、担当者はノイズに惑わされることなく、重大なリスクに集中して対応できます。
属人化を防ぐわかりやすいダッシュボード
SBOM管理は、多くの部門が関わります。yamoryは、専門家でなくてもリスクの状況をひと目で把握できる、直感的でわかりやすいダッシュボードを提供しています。誰でも簡単に使いこなせるUI/UXだから、属人化を防ぎ、組織全体での継続的なセキュリティ運用を実現します。
信頼の国産SBOM管理ツール
yamoryは、経済産業省が策定した「ソフトウェア管理に向けたSBOMの導入に関する手引」にて、唯一の国産ツールとして紹介されるなど、世界基準に対応できるSBOM管理ツールです。管理画面はもちろん、サポートも全て日本語対応。緊急時の対応や日々の小さな疑問にも、迅速にお応えします。
SBOM・脆弱性の一元管理なら
「yamory」におまかせ
脆弱性・EOL・OSSライセンスを一元管理
SBOM・法規制に対応
国産の脆弱性管理ツール
