SBOMとは? 導入のメリットや課題、主なフォーマットをわかりやすく解説

近年、“ソフトウェアサプライチェーン”を狙ったサイバー攻撃が増加しており、ソフトウェアにおけるセキュリティ対策はもはやどの企業においても必要不可欠です。そのようななか、世界各国で注目されているセキュリティ対策が、ソフトウェアの部品表とも呼ばれる「SBOM」です。すでにアメリカやEUではSBOMの活用に関する法整備が進んでおり、日本においても今後SBOMの作成や取引先への提出が求められる場面が増えると予想されます。今回はSBOMについて、その概要や導入するメリット、主なフォーマットなどを詳しくご紹介します。
SBOM(エスボム)とは
SBOM(エスボム)とは、「Software Bill of Materials」の頭文字をとった略語であり、ソフトウェアを構成するコンポーネント(部品)の情報やコンポーネント間の依存関係、ライセンスデータなどをリスト化した一覧表のことです。日本語では「ソフトウェア部品表」とも呼ばれます。
近年のソフトウェア開発では、開発の効率化や生産コストの削減のため、OSS(オープンソースソフトウェア)や事前に作られたサードパーティーコンポーネントを活用するのが主流となっています。しかし、それらの活用にはメリットがある反面、OSSやコンポーネントに潜む脆弱性を利用したサイバー攻撃を受けたり、ライセンス違反といったコンプライアンス問題が発生したりするリスクもあります。
そのような課題を解決する手段として注目されているのがSBOMです。SBOMを作成することで、ソフトウェアの構成要素に関する情報を可視化し、コンポーネントの脆弱性管理やライセンス管理を強化できます。加えて、新たな脆弱性が発見された場合でも、SBOMに記載されたコンポーネントの依存関係から影響範囲を特定し、早期対応につなげることもできます。
現代では、さまざまな企業によって開発される複数のコンポーネントを組み合わせて、一つの製品を作り上げるのが一般的です。コンポーネントごとにもSBOMを作成し、組織を超えて共有することで、製品全体の透明性を向上させることができます。

SBOMを理解するための例え
SBOMの概要を理解するには、自動車の部品表をイメージするとわかりやすいです。完成した自動車は各自動車メーカーから販売されていますが、自動車を組み立てる上で必要になる部品はそれぞれのサプライヤーで製造されています。タイヤならタイヤ専用の部品が、エンジンならエンジン専用の部品が別々の企業で製造され、それらの部品を調達して実際に自動車を組み立てているのが各自動車メーカーです。
自動車メーカーにとって自動車の部品表は、点検や修理の範囲を確認する上で、非常に重要な情報です。例えば、タイヤに関する部品に不備があった場合はタイヤを取り換えるだけで済むことがほとんどでしょう。しかし、エンジンに関する部品に不備があった場合は、車の走行性能にも直接関係するため、点検や修理などの影響範囲はタイヤよりもはるかに大きくなります。
ソフトウェア開発においてもこれと同じことがいえます。OSSやコンポーネント(部品)の情報をSBOMとしてリスト化しておくことで、万が一特定のコンポーネントに脆弱性が見つかった場合でも、即座に影響範囲を特定して対処することが可能です。
SBOMが注目されている理由
近年SBOMが注目されている理由としては、ソフトウェアの脆弱性を利用したサプライチェーン攻撃の増加や、SBOM自体の認知拡大などが挙げられます。以下で、それらについて詳しくご紹介します。
① ソフトウェアサプライチェーン攻撃の増加
サプライチェーン攻撃とは、ターゲットとなる企業を直接攻撃するのではなく、その子会社や取引先、あるいは利用しているサービス・ソフトウェアを経由して、ターゲット企業へ攻撃を仕掛ける手口のことです。大きく分けて「ビジネスサプライチェーン攻撃」「サービスサプライチェーン攻撃」「ソフトウェアサプライチェーン攻撃」の3種類があります。
中でもソフトウェアサプライチェーン攻撃は、ソフトウェア製品やOSSの脆弱性を悪用したり、ソフトウェアの製造工程や流通工程においてプログラムに不正なコードを混入させたりして、ユーザーや企業に攻撃を仕掛けるサイバー攻撃のことです。
そういったサイバー攻撃への対策の鍵として、SBOMが注目されています。ソフトウェアサプライチェーン攻撃の被害が拡大する根本的な原因は、自社で利用するソフトウェアがブラックボックス状態で、どのようなOSSやコンポーネントが含まれているかを把握できていないことです。SBOMは、このブラックボックスを解消し、ソフトウェアの構成要素を可視化します。
SBOMの導入によって、企業や組織が導入しているソフトウェアにおける脆弱性を把握できるようになれば、ソフトウェアサプライチェーン攻撃が発生するリスクを軽減することが可能です。
② アメリカ政府の大統領令をきっかけに認知が拡大
SBOMの認知が世界的に拡大するきっかけになったのは、2021年5月に発行された米国大統領令(EO 14028)です。当時のアメリカ大統領であったジョー・バイデン大統領は、SolarWinds事件などをはじめとする国家レベルのサイバー攻撃の激化を受け、「Executive Order on Improving the Nation's Cybersecurity(国家のサイバーセキュリティ向上に関する大統領令)」に署名しました。
上記の大統領令には国家のサイバーセキュリティに関するさまざまな内容が記載されており、中でも第4章「ソフトウェア・サプライチェーン・セキュリティの強化」では、米国連邦政府と取引をするソフトウェアベンダーに対してSBOMの作成・開示を義務づけることが言及されています。また、同時にソフトウェアサプライチェーンの透明化を図る必要性も記載されており、そのためにSBOMを活用することが推奨されています。
この大統領令によって、世界的にSBOMの重要性が再認識されるようになり、各国のソフトウェア開発企業においてもSBOMの導入が強く推奨されるようになりました。
③ 経済産業省がSBOM導入に関する手引を策定
上記の流れを受け、日本国内においても2023年7月に経済産業省によって、「ソフトウェア管理に向けたSBOM(Software Bill of Materials)の導入に関する手引 Ver.1.0」が策定されました。
この手引では、SBOMを導入するメリットやSBOMに関する誤解と事実など、SBOMに関する基本的な情報のほか、SBOMを実際に導入するにあたって認識・実施すべきポイントもフェーズごとにまとめられています。主に、パッケージソフトウェアや組込みソフトウェアに関するソフトウェアサプライヤーを対象とした内容です。
また、この手引は改訂が加えられ、2024年8月に「ソフトウェア管理に向けたSBOM(Software Bill of Materials)の導入に関する手引 ver 2.0」として策定されています。
SBOM義務化の流れ
前項でご紹介した通り、すでにアメリカでは米国連邦政府と取引をするソフトウェアベンダーに対して、SBOMの作成・開示が義務づけられています。また、EUにおいても2024年12月にサイバーレジリエンス法(CRA)が成立しました(全面適用は2027年12月以降)。これにより、CRAのすべての要件(SBOMの作成や提供を含む)を満たしていない製品は安全性を示すCEマークを取得できず、欧州市場での販売ができなくなります。
また、日本も2025年9月に、SBOMの活用の重要性を示す国際ガイダンスである「A Shared Vision of Software Bill of Materials (SBOM) for Cybersecurity」に共同署名しました。このように日本でもSBOMを推進する動きが活発化しており、今後あらゆる業界でSBOM導入の義務化が進んでいくことが予想されます。
SBOM導入によるメリット
世界的に認知が拡大し、導入の義務化が進んでいるSBOMですが、導入することで具体的にどのようなメリットがあるのでしょうか。ここでは、SBOM導入によるメリットを3つご紹介します。
ライセンス違反の防止
ソフトウェア開発で活用されるOSSやコンポーネントのライセンスには、MIT・GPL・MPLといったさまざまな種類があるため、正確に管理できていないと意図せずライセンス違反をしてしまう恐れがあります。
SBOMを導入することで、各コンポーネントのライセンス情報を一覧で可視化できます。これにより、開発者や管理者はライセンス状況を容易に確認できるようになり、ライセンス違反のリスクを事前に把握することが可能です。
また、専用のSBOMツールを使用すればライセンス情報を自動で管理でき、仮に使用できないライセンスが含まれていた場合にはアラートを出すなどの運用もできます。コンプライアンス問題などの法的なリスクを回避する上で、SBOMを導入するメリットは非常に大きいといえます。
脆弱性リスクの軽減
SBOMでは、コンポーネント情報やコンポーネント間の依存関係などもリスト化して管理できます。SBOMによってソフトウェアの構成情報が細部まで透明化されることで、脆弱性のあるOSSやコンポーネントを発見しやすくなり、脆弱性に関するリスクを軽減することが可能です。
OSSやコンポーネントに関する脆弱性の情報は、公的データベースなどで定期的に更新されています。SBOMを導入していない場合、新しい脆弱性が発見されるたびに、自社システムが該当のOSSやコンポーネントを使用しているかの調査を、逐一手動で行う必要があります。また、影響範囲の確認も人の目で行われるため、チェック漏れによって脆弱性を見落とす可能性も考えられます。
SBOMを導入することで、こうした非効率なフローを排除し、脆弱性やその影響範囲を迅速かつ正確に特定できるようになります。加えて、その後の対応も効率化されるため、結果としてソフトウェアの安全性と信頼性を高め、企業価値の向上にもつながります。
開発効率の向上
SBOMは、ソフトウェアのコンポーネントに関するあらゆる情報を一覧化して管理するため、ソフトウェアの開発効率の向上にも大きく寄与します。
例えば、上記2つのメリットに付随して、「ライセンス管理を自動化して管理工数を削減できること」や「脆弱性の迅速な発見によって修正作業の期間やコストを削減できること」なども、開発効率を向上させる上では重要です。また、SBOMを作成し、社内で利用されたコンポーネント情報を蓄積していけば、同じコンポーネントを再利用する際に情報を確認する手間を省くこともできます。
このようにSBOMは、各種リスクを防止するという側面だけでなく、ソフトウェアの開発プロセス全体を効率的に進行させる上でも重要な役割を担っています。
SBOM導入の課題
SBOMの導入には数多くのメリットがありますが、一方でいくつか注意しなければならない課題もあります。具体的には、以下のようなものが挙げられます。
導入・運用にコストがかかる
SBOMの導入には、システム構築や運用人員の配置など、さまざまな初期コストが発生します。加えて、正確な運用には深い知識と情報が必要であるため、それらに付随する学習コストや作業コストもかかります。
また、SBOMツールの多くが海外製であることも、SBOM導入のハードルを高めている要因の一つです。問い合わせ窓口が英語にしか対応していないことも多いため、企業によっては導入・運用における疑問点や不具合の解消が難しい場合や、追加コストが発生する可能性があります。
ツールによって出力フォーマットが異なる
SBOMは、記載方針や形式が完全に統一されていないため、ツールによって出力フォーマットが異なる点に注意が必要です。例えば、同じOSSでも、ツールごとに異なる名称で出力されるケースもあります。そのような事象を防ぐには、「一つの製品に対して使用するSBOMツールは統一する」「コンポーネントの名称やバージョン表記のルールを明確化する」などの対策をする必要があります。
記載項目が統一されていない
SBOMに記載する最小要素は、アメリカの行政機関である「NTIA(National Telecommunications and Information Administration)」によって定義されています。しかし、ライセンス情報の扱いなどはいまだ定義に含まれておらず、すべての記載項目が統一化されているわけではありません。SBOMを効果的に運用するためにも、導入時には関連企業の間で記載項目を擦り合わせることが重要です。
SBOMツールを選ぶ際のポイント
SBOMツールの導入では、各ツールの特徴を把握し、自社の適性に合わせて選定することが大切です。ここでは、SBOMツールを選ぶ際のポイントについてご紹介します。
① 搭載機能に不足がないか確認する
ひとくちにSBOMツールといっても、搭載されている機能はツールによってさまざまです。そのため、搭載機能に不足がないかを確認することは、ツールを選定する上で非常に重要なポイントといえます。
搭載機能に不足がないかを確認するためには、まず自社の導入目的を明確化する必要があります。「ソフトウェア開発に使用するため」「セキュリティ対策を強化するため」「ライセンスを管理するため」など、今一度SBOMツールを導入する目的を整理し、その目的を達成するための機能が搭載されているツールを選定することで、より効果的なSBOM運用が可能になります。
② 性能の高さを確認する
誤検知や検出漏れを極力減らすため、ツール自体の性能の高さもしっかりと確認する必要があります。ツールによってはテスト運用やトライアルなどを設けているものもあり、それらを活用するのも有効な方法です。
また、基本的に性能が高ければ高いほど、導入コストも高額になります。むやみに性能の高さだけでツールを選定してしまうとオーバースペックになってしまう可能性もあるため、導入目的や適用範囲を確認した上で、費用対効果が見合うツールを選定することが重要です。
③ 解析できる情報の種類を確認する
ほとんどのSBOMツールでは、コンポーネントの脆弱性情報やライセンス情報の解析が可能です。しかし、中には特定の情報に特化しており、ほかの情報が解析できないツールもあります。そのため、ツールを導入する際には、解析できる情報の種類をあらかじめ確認しておくことも求められます。
自社にとって必要な情報や分析範囲、またその深度などを入念に整理し、適切なSBOMツールを選定することが大切です。
④ コンポーネントの解析方法を確認する
コンポーネントの解析方法の違いは、検出されるコンポーネントの網羅性・誤検出(ノイズ)の量・運用コストなどに大きな影響を与えます。従って、SBOMツール導入時には解析方法の確認も欠かせません。コンポーネントの解析方法は、以下のように3つに大別できます。
| 解析方法 | 特徴 |
|---|---|
| コードマッチング | OSSデータベースとのマッチングによってコンポーネントを解析する方法です。 完全一致のコードマッチングのほか、スニペットマッチングと呼ばれる、部分一致のコードマッチング方法も存在します。 |
| 依存関係検出 | パッケージマネージャーの設定情報から直接的・間接的(推移的)なOSSを検出する方法です。 昨今の無料SBOMツールの多くが採用している方法であり、誤検出の可能性が低いことが特徴といえます。 |
| 文字列検出 | ソフトウェアのライセンス文字列を解析して、適用されているライセンス情報を検出する方法です。 ライセンスに関するコンプライアンス遵守の目的で使用されます。 |
⑤ 導入目的に合った運用ができるか確認する
導入目的に合わせて運用がしやすいかどうかも確認すべきポイントです。運用のしやすさを判断するには、導入を検討する段階で、実際にSBOMツールの運用を行う担当部門の声を聞くことが大切です。例えば、開発部門が運用を行うのであれば、開発中のソフトウェアと連携しながらバックグラウンドで解析を行うツールを選定した方が、業務の負担を軽減できます。
加えて、より効果的にSBOMツールを運用するためには、「すでに自社で導入しているツールとの連携が可能か」「ツールのサポート体制は十分か」などもしっかり確認しておくことが望ましいです。
SBOMの主なフォーマット
SBOMには、「SPDX」「CycloneDX」「SWIDタグ」という主に3種類のフォーマットがあります。最後にそれらについてご紹介します。
SPDX(Software Package Data Exchange)
SPDX(Software Package Data Exchange)は、Linux Foundationのプロジェクトで開発されたフォーマットです。ISO国際標準にもなっているオープンな規格であり、多くのSBOMツールで用いられています。パッケージ情報・ファイル情報・スニペット情報といった、さまざまなコンポーネントの形式をサポートしているほか、機械可読と人間可読の両方の形式をサポートしていることも特徴です。
医療や金融などの厳格なコンプライアンス管理が求められる業界、政府調達やグローバルな企業間取引に適したフォーマットといえます。
CycloneDX
CycloneDXは、OWASP(Open Web Application Security Project)によって開発されたセキュリティ特化のフォーマットです。開発現場における技術的・セキュリティ的な課題解決を目的とし、ソフトウェアの脆弱性管理やリスク評価など、セキュリティを高める上で役立つ詳細な情報も記述できます。加えて、完全自動化が可能であり、CI / CDパイプラインやDevSecOpsでの開発にも適しています。
SWIDタグ(Software Identificationタグ)
SWIDタグ(Software Identificationタグ)は、管理対象となるデバイスにインストールされたソフトウェアを追跡し、管理・解析するために開発されたフォーマットです。ソフトウェアのインストール時にSWIDタグが付与され、ソフトウェアの識別と管理を最適化します。また、アンインストール時には自動的にタグが削除される仕組みになっています。
SWIDタグはソフトウェア識別に関するフォーマットではあるものの、ライセンス情報やセキュリティ情報も記載することができます。企業のIT資産管理システム(ITAM)との親和性が非常に高いフォーマットです。
まとめ
今回はSBOMについてご紹介しました。SBOMは、ソフトウェアを構成するコンポーネント情報などをリスト化した一覧表のことであり、サイバー攻撃やコンプライアンス問題への効果的な対策として注目されています。特にソフトウェアサプライチェーン攻撃への対策として世界的に推進されている背景から、日本でも今後はSBOMの作成が求められる機会がより一層多くなると予想されます。今回の記事の内容がSBOM導入へのきっかけや参考になりましたら幸いです。