SBOMとは？ソフトウェア部品表の基本と、脆弱性管理における重要性を解説
ソフトウェア部品表を意味するSBOMは、ソフトウェアサプライチェーン攻撃が増加する昨今、注目を集めています。ただし、SBOMは作成することが目的ではなく、真の価値は「脆弱性管理」に活用することにあります。本記事では、SBOMの基本から脆弱性管理への活用メリットまでを解説します。
SBOMとは
SBOM（Software Bill of Materials）の定義
SBOMは「Software Bill Of Materials」の略で、「ソフトウェア部品表」を意味します。
食品における成分表示のように、ソフトウェアの中にどのような部品（コンポーネント）が使われているのかを一覧で示すものです。
近年のソフトウェア開発では、オープンソースソフトウェア（OSS）や外部ライブラリ、他社モジュールなどを組み合わせて構築するのが一般的で、フルスクラッチでゼロから開発をするケースはほとんどないでしょう。
そのため、「どの製品にどのようなコンポーネントが含まれているのか」を正確に把握するのは容易ではありません。こうした複雑化した構成を整理し、一覧化するために必要となるのがSBOMです。
「アプリケーション領域」と「組み込みシステム領域」のSBOM
一口に「SBOM」と言っても、その文脈は大きく2つに分かれます。
アプリケーション領域
クラウドやサーバ上で稼働するアプリケーションを対象とし、OSSやライブラリの構成を可視化
組み込みシステム領域
主に製造業で扱われるハードウェア製品内部で動作するソフトウェアを対象とし、ファームウェアやドライバ、外部ライブラリなどの構成情報を管理
本記事では、前者のアプリケーション領域のSBOMに焦点を当て、脆弱性管理を中心とした活用方法を解説します。
SBOMに含まれる主な情報
ソフトウェア部品表であるSBOMには、以下のような情報が含まれます。これらの情報は、SPDXやCycloneDXなどのフォーマットで記述されます。
コンポーネント名称
バージョン情報
開発者・配布元などの識別情報
ライセンス情報
サプライヤー名
他のコンポーネントとの依存関係
引用：経済産業省「ソフトウェア管理に向けたSBOM（Software Bill of Materials）の導入に関する手引 ver 2.0」
なぜSBOMが必要か？
ソフトウェアサプライチェーン攻撃の増加
SBOMが注目されている最大の理由は、ソフトウェアサプライチェーン攻撃の急増です。近年、OSSライブラリや外部依存パッケージを経由して、脆弱性が広がる事例が相次いでいます。
2024年には、悪意のある攻撃者が開発組織の内部に長年潜り込み、圧縮ライブラリ「XZ Utils」にバックドアを挿入する事件が発生しました。幸いにも正式配布される前に発見されたため、影響は限定的にとどまりましたが、もし公開が進んでいれば、多くのLinux環境にバックドアが伝播する歴史的な大規模インシデントとなっていた可能性があります。
さらに、2025年9月には「NPM」の人気パッケージのメンテナーアカウントが乗っ取られ、不正なコードを含むバージョンが公開される事件も発生しました。該当パッケージ群は毎週約20-26億ダウンロードされており、依存関係を通じて広範囲に影響が及んでいます。
このように、ソフトウェアの中身（XZ Utils）の改ざんから、配布基盤（npm）の乗っ取りまで、攻撃の手口は多様化しています。
現代のソフトウェア開発において、サプライチェーンへの依存を完全に排除することは不可能です。しかし、サプライチェーンは影響範囲が極めて広いため、攻撃者にとって効率的に攻撃を拡散できる格好の標的となっています。
世界的な規制・ガイドラインの整備
ソフトウェアサプライチェーン攻撃が発生した際、自社のサービスや製品に問題のあるコンポーネントが含まれているかを把握できなければ、迅速な脆弱性対応は不可能です。どこにどんなソフトウェアが使われているかを把握できていないこと自体が、セキュリティリスクとなります。
こうした背景から、世界各国でSBOMの作成・提供を義務化する動きが加速しています。SBOMは任意のセキュリティ対策ではなく、国際的な標準要件として位置付けられつつあります。
＜海外＞
米国：大統領令 EO 14028（Improving the Nation’s Cybersecurity）[2021]
連邦政府がソフトウェアを調達する際、サプライヤーに対してSBOM提供を要求
欧州: Cyber Resilience Act（CRA）[2024]
EU内の製造業者がSBOMかSBOM相当の作成を義務化
＜国内＞
経済産業省「ソフトウェア管理に向けた SBOM の導入に関する手引（ver1.0／ver2.0）」
SBOM導入のベストプラクティスを提示し、官民での活用を推進
金融庁「金融分野におけるサイバーセキュリティに関するガイドライン」
「望ましい対応事項」としてSBOMを提示し、金融機関への導入を促進
SBOMの主な活用目的は「脆弱性管理」
とはいえ、SBOM単体ではソフトウェア部品の一覧表でしかなく、作成しても活用できなければ意味がありません。SBOM作成は目的ではなく手段に過ぎないのです。
SBOMは、EOL管理やライセンス管理などにも活用できますが、サプライチェーン攻撃の増加や各国の規制整備の流れを踏まえると、最も重要な目的は「脆弱性管理」であると言えます。
脆弱性が新たに公開されたとき、SBOMがないと、影響を受ける可能性のある部品（コンポーネント）を即座に把握できません。どのサービスがどのライブラリに依存しているのかを特定するのに時間がかかり、その間に被害が拡大する恐れがあります。
一方で、事前にSBOMを生成してソフトウェアの構成情報を保持していれば、対応すべき製品や部品を迅速に特定できます。その結果、修復までのリードタイムを短縮できることが、SBOMの最大の利点です。
さらに、脆弱性は日々新たに発見され、ライブラリも頻繁に更新されます。SBOMは一度作成して終わりではなく、継続的に更新・運用していくことが求められます。こうした継続管理を通じて初めて、SBOMは実効的な脆弱性対策の土台として機能します。
Cloudbaseでは、クラウド環境におけるエージェントレスSBOMスキャンを実施でき、セットアップ工数は一切不要です。オンプレミス環境にも負担の少ないスキャンで対応できます。また、脆弱性のトリアージにはSSVCを採用しており、重要度に応じた効率的な対応を支援します。
CloudbaseによるSBOM管理に関心のある方は、ぜひお問い合わせください。
