SBOMとは？ソフトウェア部品表を脆弱性管理に使う方法

今注目を集めるSBOM

Log4jの脆弱性が世界を震撼させた日から数年、ソフトウェアサプライチェーン攻撃はもはや対岸の火事ではありません。攻撃者は、防御の薄いサードパーティのソフトウェアコンポーネントを狙い、標的企業の心臓部へと侵入します。従来のファイアウォールやアンチウイルスといった「境界線」を守るだけのセキュリティ対策は、その限界を露呈しています。

こうした中、ソフトウェアに潜むリスクを把握する手段として注目されているのがSBOM（Software Bill of Materials / ソフトウェア部品表）です。
SBOMは、例えるなら「ソフトウェアの食品成分表」。どのような部品が使われているかを記録しておくことで、脆弱性のある部品やサポート期限が切れた部品が含まれていないかを確認しやすくなります。これにより、ソフトウェアの透明性が向上し、脆弱性への対応に着手するまでの時間を短縮しやすくなります。

EUのサイバーレジリエンス法（CRA）のように、製品の製造者にSBOMの作成を求める法規制も登場しています。SBOMへの対応は、「やれば有利」なベストプラクティスにとどまらず、ソフトウェアや製品を提供し続けるための要件になりつつあります。
本稿では、SBOMの基本、制度の動向、導入を成功させるためのポイントと、多くの企業が陥りやすい「失敗の罠」を解説します。

SBOMとは？ソフトウェア部品表の基本

まずはSBOMの基本について理解しましょう。

SBOMとは、特定のソフトウェアを構成するコンポーネント（部品）と、それらの依存関係を記録したリストです。標準化された形式としてCycloneDXやSPDXがあり、CycloneDXのSBOM解説やSPDXの概要で、その表現方法を確認できます。

具体的には、以下のような情報を含みます。

オープンソースソフトウェア（OSS）の名称とバージョン
サードパーティ製の商用ライブラリ
コンポーネントの提供元
ライセンス情報

アプリケーションが直接使うライブラリに加え、そのライブラリが依存する別の部品も調査対象になります。部品の識別子、バージョン、依存関係、生成対象の製品・ビルド、作成日時を残しておくと、後から照合しやすくなります。

ただし、SBOMに含まれる情報は、生成するツールやタイミングによって変わります。ソースリポジトリから作った一覧と、実際に配布するコンテナイメージの構成が同じとは限りません。何を対象に生成したのかを明確にしておく必要があります。

経済産業省も「ソフトウェア管理に向けたSBOM（Software Bill of Materials）の導入に関する手引」でSBOMの概要や導入の考え方を解説しています。SBOMは、スーパーなどで販売されている食品の裏面に記載されている「原材料名」のようなものと例えられることがあります。

引用：経済産業省 ソフトウェア管理に向けたSBOM（Software Bill of Materials）の導入に関する手引

例えば、あなたがアレルギーを持っている場合、食品の原材料表示を確認することで「小麦」や「乳製品」といったアレルゲンが含まれているかどうかをすぐに判断できます。同様に、SBOMを脆弱性情報と照合すれば、脆弱性が見つかった「Log4j」などのコンポーネントが自社ソフトウェアに含まれているかどうかを素早く調べられます。ただし、部品を含むことと、直ちに悪用可能であることは同じではありません。該当する部品が見つかったら、ベンダー情報や利用条件を確認し、自社の構成が実際に影響を受けるかを調べます。

また、食品の原材料には「産地」や「添加物」の情報も含まれていますが、SBOMにも同様に「提供元（ベンダー）情報」や「ライセンス種別」などの付加情報を記録できます。これにより、ソフトウェアを構成する「材料（コンポーネント）」の詳細を把握しやすくなり、安全性と品質を確保するための基盤となります。

なぜ今、SBOMが必要なのか？

SBOMが重要とされる理由は、主に4つです。

サプライチェーン攻撃への対策
自社が利用するソフトウェアにどの部品が使われているかを把握しておくことで、新たな脆弱性が発見された際に「自社は影響を受けるのか？」を調べる起点になります。
法規制・業界標準への対応
後述するEUのCRAのほか、米国ではNTIAがSBOMの最小要素（Minimum Elements）をまとめるなど、SBOMの作成や提供を求める動きが広がっています。
ライセンス管理
OSSのライセンス違反は、法的リスクやブランドイメージの毀損に繋がります。SBOMに記録したライセンス情報は管理に役立ちますが、名前が記録されていることだけで利用条件への適合を判断できるわけではありません。実際の利用方法とライセンス本文を合わせて確認します。
迅速な脆弱性対応
脆弱性情報を得てから構成を一から「調査」するのではなく、最新の部品表を元に影響範囲の確認に着手できます。

SBOMをめぐる規制・ガイドラインの動向

迫りくる規制の波

SBOMの導入が進む背景として、世界中でSBOMの作成や提供を求める法規制・ガイドラインの整備が進んでいます。

EUサイバーレジリエンス法（CRA）

欧州で製品を提供する多くの企業にとって、CRAは避けて通れない規制です。

施行時期　規則（EU）2024/2847として成立し、2024年12月10日に発効しました。義務は段階的に適用され、悪用が確認された脆弱性や重大なインシデントの報告義務は2026年9月11日から適用されています。SBOMの作成を含む主要な義務は2027年12月11日から適用されるため、製品の開発サイクルを踏まえて早めに準備を進めることが重要です。
対象範囲　スマートフォン、IoT機器、ソフトウェアなど「デジタル要素を持つ幅広い製品」が対象です。
要求事項　製造者には、製品に含まれる脆弱性やコンポーネントを特定・文書化することが求められ、その一環としてSBOMの作成が必要です。SBOMは技術文書の一部として扱われ、一般への公開までは求められていませんが、市場監視当局から理由を付した要請があった場合には提供する必要があります。違反した企業には、全世界の売上高に応じた高額の制裁金が科される可能性があります。

参考： Regulation (EU) 2024/2847（EUR-Lex）、https://www.hitachi-solutions.co.jp/sbom/learn/sbom-for-cra/

日本国内の動向と金融業界への波及

日本も例外ではありません。経済産業省は「ソフトウェア管理に向けたSBOM（Software Bill of Materials）の導入に関する手引」を公開し、企業にSBOMの導入を推奨しています。2024年8月には手引のVer2.0が公表され（関連リリース）、2025年9月には経済産業省と内閣官房国家サイバー統括室が、SBOMの共有ビジョンに関する国際ガイダンスへの共同署名を発表しています。

さらに、金融業界ではEUのDORA（Digital Operational Resilience Act）が、金融機関にICTサードパーティのリスク管理を求めており、その影響はサービスを提供するICTベンダーにも及び始めています。利用しているソフトウェアの構成を把握する手段として、SBOMを活用する動きもあります。

SBOM導入を成功に導く4つの重要ポイント

ソフトウェアサプライチェーンのリスク管理に欠かせないSBOM（Software Bill of Materials）。その導入を成功させ、継続的に運用していくためには、以下の4つのポイントが重要です。

1. 推進体制の構築：責任の所在を明確に

SBOMの導入と運用を推進する責任部署を明確に定めます。これにより、全社的な取り組みとして円滑に進行させやすくなります。

2. 自社に合ったツール選定：導入失敗を避ける重要なステップ

SBOM導入の成否を分ける重要なステップがツール選定です。市場には数多くのツールが存在します。将来の運用を見据え、特に以下の連携機能や対応範囲を確認しておきましょう。

GitHub/CI/CD連携　手動でのSBOM作成は形骸化しがちです。開発プロセスに組み込み、SBOMの生成を自動化できるかが重要です。
クラウド連携 (AWS/Azure/Google Cloud)　本番環境で稼働するソフトウェアの構成を取得・更新できるかを確認します。特に、コンテナやサーバーレスといった環境への対応範囲は重要な確認ポイントです。
脆弱性データベース連携　SBOMが持つコンポーネント情報を、NVDなどの脆弱性データベースと継続的に照合し、リスクを検知・評価できることが求められます。
出力・取り込み形式　代表的な形式にはSPDXとCycloneDXがあります。形式名だけでなく、バージョン、必須項目、取り込み側で使える情報を照合します。詳しくはSBOMフォーマットの比較をご覧ください。

3. CI/CDへの統合：開発プロセスとの一体化

SBOMの生成をCI/CDパイプラインに組み込むことで、開発プロセスの一部として自然に定着させます。これにより、開発の流れを止めずに、リリースごとの構成を記録できます。

4. 継続的な運用：SBOMは「作成して終わり」ではない

SBOMは一度作成して終わりではありません。新たな脆弱性情報を継続的に確認し、SBOMを最新の状態に保つことで、継続的なリスク管理を実現します。

影響する脆弱性が見つかった場合は、更新候補と互換性を確認して修正します。更新後のビルドからSBOMを再生成し、配布先や稼働環境が新しい構成に切り替わったことも確かめます。ファイルを作り直すだけでは、古い環境が残っている問題は解消しません。継続運用にあたっては、次の点を決めておきます。

生成するタイミングと、その対象となるビルド・イメージ
保管する場所と、製品・リリース番号との対応
新しい脆弱性情報を照合する担当と頻度
影響調査や対応状況を残す場所
社外提供する情報と、アクセスできる人の範囲

これらのポイントを押さえ、自動化を前提とした継続的な運用体制を構築することが、SBOM導入を成功させるための鍵となります。

SBOM運用における課題

多くの企業がSBOMの導入で直面する主な課題は以下のとおりです：

情報の断片化　SBOMデータと他のセキュリティ情報（脆弱性データベース、資産管理情報など）が連携されず、分断されることでリスク評価が困難になります。
継続的な更新の難しさ　ソフトウェアの更新のたびにSBOMを作り直し、稼働環境との対応を保ち続ける必要があります。
膨大なアラート処理　照合結果の優先順位付けができないと、「情報の洪水に溺れる」状況に陥りがちです。
リソースの浪費　断片化したツールからのアラートに対応するため、貴重なエンジニアリングリソースが消費されます。

SBOMだけではない統合的なセキュリティ運用の重要性

なかでも「情報の断片化」は大きな課題になります。

セキュリティリスクの情報が、製品や担当ごとにサイロ化（分断）されていることは珍しくありません。

ASM　インターネットに公開されている資産（ドメイン、IP）のリスク
CSPM　クラウド（AWS/Google Cloud/Azure）の設定不備リスク
脆弱性診断　稼働中のWebアプリケーションの脆弱性リスク
SBOM　ソフトウェアを構成する「部品」のリスク

これらを別々の単機能ツールで管理していると、情報の洪水に溺れやすくなります。各ツールの「点」の情報だけでは、ビジネスインパクトに基づいたリスクの優先順位付けが難しいためです。

単機能ツールの限界と「統合」がもたらす価値

Securify SBOMは、リポジトリやコンテナイメージからコンポーネントとバージョンを抽出してソフトウェア部品表を作成し、脆弱性情報と照合して問題のあるコンポーネントを特定します。ソースコードやクラウドとの連携で構成情報を管理でき、ASM・CSPMで把握している資産とも関連づけられます。SBOMを単なる部品表として扱うのではなく、資産の情報と合わせて確認することで、脆弱なコンポーネントがどの資産に関係するかを調べやすくなります。利用する言語や収集先、必要な入出力形式に応じて対応範囲をご案内します。

結論：SBOM対応を、ビジネスを守る「戦略的投資」へ

本記事では、SBOMの基本から、制度の動向、そして導入と運用の成否を分ける要因について解説してきました。

要点をまとめます。

SBOMの作成・提供は、EUのCRAなどの制度や取引先の要請により、ソフトウェアを提供するうえでの要件になりつつある。
失敗の本質は、SBOMで得た情報と、他のセキュリティ情報が「断片化」することにある。
成功の鍵は、SBOMを継続的に更新し、ASM・CSPM・脆弱性診断などの情報と関連づけて扱える体制とツールを選ぶこと。

一方でSBOM単体では防げない脅威も当然ながら存在します。安全を確保するためには、SBOMはもちろんのこと、ASM、脆弱性診断、CSPMといったソリューションを組み合わせた、多層的なセキュリティアプローチが必要です。

弊社が提供する Securify では、SBOMに加えてASM・CSPM・脆弱性診断を提供しています。
ぜひお気軽にお問い合わせください。

SecurifyのSBOM機能についてはこちらでご紹介しております。併せてご覧ください。

参考文献

Regulation (EU) 2024/2847 Cyber Resilience Act（EUR‑Lex）[1]
EU CRAにおけるSBOM要件まとめ（Anchore）[2]
SBOM and the EU CRA（SafeDep）[3]
経済産業省「ソフトウェア管理に向けたSBOM導入に関する手引（Ver2.0）関連リリース」（英語版案内）[4]
経済産業省・内閣官房国家サイバー統括室：SBOM共有ビジョンに関する国際ガイダンス共同署名[5]
NTIA：The Minimum Elements for a Software Bill of Materials (SBOM)[7]
What is a Software Bill of Materials?（Harness）[8]
Microsoft SBOM Toolの概要と実装（解説記事）[9]
The Complete Guide to SBOMs（FOSSA）[10]
What is a Software Bill of Materials?（Balbix）[11]
DORAがICTサードパーティに与える影響（PwC）[12]
国内報道：SBOM共有ビジョンに関する国際ガイダンス共同署名（EnterpriseZine）[13]
CycloneDX: Software Bill of Materials (SBOM)[14]
SPDX: Overview[15]