SBOMとは、ソフトウェアを構成するOSSやライブラリ、モジュールなどの名称、バージョン、ライセンス情報、依存関係などを一覧化したものだ。いわば「ソフトウェアの材料表」であり、どの部品を使っているかを可視化する仕組みである。

　NTTデータが公開した「グローバルセキュリティ動向四半期レポート 2025年度 第2四半期」によると、米国では政府調達におけるSBOMの提出が実質的に求められ始めている。日本でも、経済産業省や国家サイバー統括室（NCO）が国際的なSBOM普及の枠組みに参加している。

　背景にあるのは、ソフトウェアサプライチェーンの複雑化だ。近年は「Log4j」や「xz backdoor」のように、広く利用されているOSSの脆弱性が世界規模のセキュリティ問題へ発展するケースが相次いでいる。米国立標準技術研究所（NIST）の脆弱性情報データベース「National Vulnerability Database」（NVD）に登録された脆弱性件数は、この10年間で約7倍に増加したという。

　こうした中、米国では2021年の大統領令「Executive Order 14028」を契機に、政府調達におけるSBOM活用が進展した。さらに2025年には、米サイバーセキュリティ・インフラ安全庁（CISA）が、SBOMに含めるべき項目や自動化運用を強化した新ガイドライン案を公表している。

　日本でも、経済産業省が「SBOM導入手引」を公表し、米国や欧州を含む15カ国と共同でSBOM普及に関する共同文書へ署名した。SBOMは既に“海外だけの話”ではなくなりつつある。

SBOM導入で企業が直面する「4つの壁」

　NTTデータは、SBOM普及を阻む課題を、「生成と収集」「活用」「維持と管理」「推進体制」の4点から整理している。

1．ベンダーからSBOMを入手できない

　NTTデータは問題の1つとして、サプライヤーからSBOMを取得できないケースがあることを指摘している。

　特に組み込み機器やバイナリ配布型ソフトウェアでは、内部構成がブラックボックス化しやすい。SBOMが提供されなければ、脆弱性の影響範囲を正確に把握できず、インシデント発生時の原因究明や影響調査が困難になる。

　さらに、利用者側がバイナリ形式のソフトウェアを解析し、内部コンポーネントや脆弱性を正確に把握することは極めて難しい。その結果、脆弱性情報の提供をサプライヤー任せにせざるを得ず、重要な脆弱性への対応遅延を招く可能性がある。

　また、SBOMが提供されても、「コンポーネント名しか書かれていない」「バージョン情報や識別子が不足している」といった品質問題もある。これでは脆弱性情報との正確な照合ができず、結局は従来通り手作業での調査が必要になる。NTTデータは、こうした状況が「SBOMの効果を十分に発揮できない要因になる」と指摘している。

2．“脆弱性を見つけるだけ”で終わっている

　NTTデータによると、SBOMを導入しても、その後の脆弱性対応プロセスが整備されていないことで、SBOMを効果的に活用できず、本来の価値を十分に引き出せないという課題が生じているという。

　レポートでは、SBOMの価値は「脆弱性を検知すること」ではなく、その後の対応プロセスと連動して初めて発揮されると説明している。具体的には、「脆弱性情報の収集」「影響有無の評価」「優先度付け」「暫定対処／恒久対処」「関係者への通知」「記録管理」までを含めた一連の運用プロセスを標準化する必要があるという。

　例えば、脆弱性を検知しても、「どの業務へ影響するのか」「本当に攻撃可能なのか」を判断できなければ、対応の優先順位を付けられない。その結果、場当たり的な対応になり、脆弱性対応完了まで長期間を要するケースが発生する。

　特に注目されるのが、「VEX」（Vulnerability Exploitability eXchange）だ。これは、「その脆弱性が実際に悪用可能なのか」を機械可読で示す仕組みである。例えば「該当機能は無効化されているため到達不能」といった情報を共有できるため、影響のない脆弱性への過剰対応を減らし、本当に対応すべき脆弱性へ集中できる可能性がある。

　さらにNTTデータは、こうした脆弱性対応を組織的に運用するには、「PSIRT」（Product Security Incident Response Team）のような専門体制の整備が理想だとしている。

3．SBOMが“古い情報”になる

　アジャイル開発やCI/CD（継続的インテグレーション／継続的デリバリー）が一般化した結果、ソフトウェア構成は頻繁に変化するようになった。その結果、SBOMの内容と実際のソフトウェア構成に差分が生まれる「SBOM Drift」が発生しやすくなっている。

　NTTデータによると、SBOM Driftが進行すると、SBOMの信頼性そのものが低下する。存在しない脆弱性へ過剰対応したり、本当に存在する脆弱性を見逃したりする恐れがあるという。

　これを防ぐため、NTTデータはSCA（Software Composition Analysis）ツールをCI/CDパイプラインへ統合し、SBOMを自動生成、更新する仕組みの利用を推奨している。これにより、開発スピードを落とさず、実際のソフトウェア構成と一致したSBOMを維持しやすくなる。

　また、「Software Package Data Exchange」（SPDX）や「CycloneDX」など複数フォーマットが存在し、互換性の問題が発生している。そのため実務では、項目のマッピングやフォーマット変換、検証の追加作業が必要になり、運用負荷増大につながっている。

　さらに、フォーマット間の互換性問題は、サプライチェーン全体における情報共有を阻害するとNTTデータは指摘している。サプライヤーから受領したSBOMを自社ツールで扱えない場合、脆弱性管理の一貫性が損なわれ、サプライチェーン全体で非効率かつ不正確な脆弱性管理が発生する恐れがある。

4．経営層がSBOM運用を「コスト」としか見ていない

　SBOM普及で最も根深い問題としてNTTデータが挙げているのが、「経営層の理解不足」だ。

　SBOM導入は直接売上を生む施策ではないため、ROI（投資対効果）を示しにくい。その結果、経営層から「導入コストが高い」「優先度が低い」と判断されやすい。

　特にSBOMは、高度な技術的概念に基づく取り組みであり、開発、運用、調達、セキュリティなど組織横断的なプロセス整備が必要になる。そのため、経営層にとっては「コストがかかる割に効果が見えにくい施策」と認識されやすいという。

　だがNTTデータは、SBOMを「事業継続性を守るための戦略投資」として説明すべきだと提言する。サプライチェーン攻撃による事業停止、ブランド価値毀損、障害対応コスト、復旧コストなどを含めたTCO（総保有コスト）の観点から説明することで、経営層の理解を得やすくなるとしている。

　さらに、SBOM整備は規制対応や顧客要求への対応だけでなく、「製品やサービスの信頼性向上」「市場競争力の維持」にもつながるとNTTデータは指摘する。単なるセキュリティ対策ではなく、将来的な事業継続能力を支える基盤投資として位置付ける必要があるという。

「SBOM提出」が調達条件になる日

　NTTデータは、SBOMの普及に向けた現実的なアプローチとして、「契約へのSBOM要件組み込み」を提案している。具体的には、標準フォーマットの指定や、更新頻度、責任分担を契約で定義する考え方だ。

　つまり今後は、「セキュリティ対策をしていますか？」だけでなく、「SBOMを提出できますか？」が調達条件になる可能性がある。

　特に製造業、インフラ、公共分野などでは、海外顧客やグローバルサプライチェーンからSBOM提出を求められるケースが増える可能性が高い。情シスや開発部門にとってSBOMは、“将来の新業務”になる可能性もある。