SBOMとは？セキュリティ・脆弱性対策としての義務化の動きと管理運用フォーマットの具体例

現在のエンジニアリング分野、さらに広義でいうならあらゆる企業活動には、無数のソフトウェアが関与しています。生成AIなどメガトレンドともいえるイノベーションも目覚ましい近年では、ソフトウェア開発における、構成の「見える化」が厳格に問われるようになりました。

そこで不可欠な存在となっているのが、いわば「ソフトウェア部品表」であるSBOM（Software Bill of Materials）です。重要性が増しているセキュリティリスク、脆弱性への対応として、SBOMの準備はすでに「あって当然」の施策となりつつあります。

本記事では、SBOMの基本から、義務化の動き・作成方法・管理ツール・最新トレンドまでを、エンジニアの実務に即した形式で、国内の最新動向も合わせて考察します。

 

 

SBOMとは

SBOM（読み方：エスボム）とは「Software Bill of Materials」の略称で、日本語では「ソフトウェア部品表」と訳されます。わかりやすく説明すると、ソフトウェアを構成するすべてのコンポーネント（オープンソース含む要素）を一覧化したドキュメント・リストのことです。製造業の部品表であるBOM（Bill Of Materials）のソフトウェア版ともいえます。

企業が活用する大規模なソフトウェアはさまざまな要素から構成されています。独自開発のソースコードだけでなく、外部のコンポーネントやライブラリ、モジュールなども組み合わせてつくられているため、一部に脆弱性があればサイバー攻撃の標的となってしまうリスクは否定できません。

このようなセキュリティリスク対策として、開発元やバージョン、ライセンス、依存関係をすぐに確認できるSBOMが求められているのです。開発者・セキュリティ担当者・監査担当者が、ソフトウェアの透明性を担保し、リスクを管理できる状態を作るために欠かせない存在といえるでしょう。

特にコネクテッドカーや自動運転などの実現に向けてオープンソースソフトウェア（以下OSS）の活用が進んでいる現在、「どこからどんなコードが持ち込まれたのか」を把握することは、セキュリティやライセンスリスクの観点でも非常に重要です。

 

SBOM義務化の流れと大統領令

近年、SBOMの重要性は増しており、米国政府のセキュリティ対策強化策に端を発する形で、いわば「義務化」ともいえる流れが進行しています。

2021年5月12日、ジョー・バイデン米国大統領は、サイバーセキュリティ強化（Improving the Nation’s Cybersecurity：国家のサイバーセキュリティの向上）のための大統領令に署名しました。これは、政府、公的機関、民間企業等のネットワークを保護するとともに、政府と企業間の情報共有を改善するための施策であり、政府機関に提供されるソフトウェアにはSBOMの提出が必須となったのです。

この大統領令では、政府と契約する企業に対して情報共有とサイバー攻撃の情報を開示することを義務づけています。さらにこの動きを受け、NTIA（米国国家電気通信情報管理庁）はSBOMの最小構成要素を定義。続いてNIST（米国標準技術研究所）が、SBOMの活用を含むセキュリティフレームワークを具体化しました。

結果として、アメリカ国内では政府調達を含む大規模案件において、SBOM対応は「あって当然」の水準にまで高まっています。

 

日本におけるSBOMの位置づけと今後の見通し

日本でも、SBOMに関する注目度は急速に高まっています。IPA（独立行政法人 情報処理推進機構）やNISC（内閣サイバーセキュリティセンター）などがガイドラインを整備し、今後のサプライチェーン対策の中核技術として位置付け始めています。

現時点では法的な義務化までは踏み込んでいませんが、上述したIPAやNISC、さらに経済産業省もソフトウェア管理ガイドラインにSBOMの導入を推奨する内容を盛り込むなど、すでに「努力義務」から「標準対応」へのステージに移行しつつある状況です。

特に、エンタープライズ領域やインフラに関わる業界では、今後の契約条件にSBOM提出が含まれるケースが大半となると見られます。すでに義務化に近い、いわば実質的な標準化が始まっているといえるでしょう。

（参照）

• SBOM導入・運用の手引き｜IPA
• サイバーセキュリティ2024の概要｜NISC
• 「ソフトウェア管理に向けたSBOMの導入に関する手引」を策定しました｜経済産業省

 

SBOMとソフトウェアのリスク

最近のソフトウェア開発では、さまざまなOSSを使用しています。これは、OSSを用いることでソフトウェアをゼロから開発する必要がなくなり、開発効率の向上や生産コストの削減を実現できるためです。

このようなメリットがある一方で、OSSライセンス違反や脆弱性をはじめとするセキュリティリスクなどの問題は続々と発生しています。SBOMによる管理は、これらOSS運用上の課題に有効な手法になりえるものです。

ソフトウェア開発にOSSを使用する際には、脆弱性の有無やライセンス準拠について確認するなどのリスク管理が欠かせません。そこで、ソフトウェアに使用されているOSSやコンポーネント、開発元などが一覧化されているSBOMがあれば、セキュリティ上の問題が発生した際にも適切かつ迅速な対応を行えます。

また、一覧化することにより事前対策も容易になります。ソフトウェアの脆弱性やライセンスに関する調査をおこなう際にも、SBOMがあれば何をどのように調査すればよいのかがわかりやすく、迅速に対応できるようになるのです。

 

SBOMの構成要素と主要フォーマット

SBOMは、単なる「部品一覧リスト」ではありません。ソフトウェアの構成を把握・管理するための情報がクラスタリングされたドキュメントといえます。そのため、何を記載するか、どこまで情報を含めるかは非常に重要になってきます。

米国NTIAが定義した「SBOMの最小構成要素（Minimum Elements）」に基づくと、SBOMは以下のような情報を含みます。

• ソフトウェア部品の名称
• バージョン情報
• コンポーネント識別子
• ライセンス情報
• 依存関係（親子関係）
• 発行日、作成者、サプライヤー名　など

これらを明示することで、脆弱性対応やライセンス管理、コンプライアンス対応が可能となり、ソフトウェアの信頼性と透明性は飛躍的に向上します。

 

代表的なSBOMフォーマットの比較と特徴

SBOMには複数の記述フォーマットが存在し、それぞれに特徴と適用範囲があります。

現在、広く利用されている主要なフォーマットは次の3つです。

• SPDX：Linux Foundation主導。ライセンス管理に強く、ISO規格化済み（ISO/IEC 5962:2021）
• SWIDタグ：ISO標準（ISO/IEC 19770）。企業のIT資産管理・インベントリとの親和性が高い
• CycloneDX：OWASP発祥。セキュリティ情報の表現が得意。SBOMに加えVEXとの連携も進む

これら共通のフォーマットを用いてソフトウェアに関する情報を管理することで、情報の可視性が高まり管理も効率化されます。SPDX 、Cyclone DXは国際標準として認定された、もっとも一般的なSBOMフォーマットです。SWIDタグには4つのポイントがあり、それぞれソフトウェア開発の中の異なるフェーズで使用されます。

選定のポイントは、「誰が使うのか」「何の目的で使うのか」に尽きるでしょう。たとえばセキュリティ重視ならCycloneDX、ライセンス監査目的ならSPDX、エンタープライズIT環境に溶け込ませたいならSWIDといった選び方になります。

また、近年では各種フォーマットの相互変換ツールも充実してきているため、最初から1つに固定する必要はありません。

 

SPDX

SPDXとは、SBOMに記載されている情報の共有と利用方法の標準化を目的として生まれたものです。SPDXには、コンポーネントやライセンス、セキュリティに関するデータが含まれています。

SWIDタグ

SWIDタグとは、ソフトウェアの構成要素を識別するために標準化されたフォーマットです。SWIDタグにはCorpus Tags、Primary Tags、Patch Tags、Supplemental Tagsの4つがあり、それぞれはソフトウェア開発ライフサイクルの異なるポイントで使用されます。

• Corpus Tags：プレインストールソフトウェアを識別・説明するためのタグ
• Primary Tags：インストール後のソフトウェア製品を識別・説明するためのタグ
• Patch Tags：パッチを識別・説明するためのタグ
• Supplemental Tags：ライセンスキーや関係者の連絡先などの関連情報を提供するためのタグ

Cyclone DX

Cyclone DXは、比較的軽量のSBOMフォーマットです。アプリケーションのセキュリティの背景やサプライチェーンのコンポーネント分析に使用するために設計されており、SPDXやSWIDタグと同様の目的を果たせるよう構成されています。

また、Cyclone DXでは次の4つカテゴリでソフトウェアの関連情報をサポートします。

• Bill of Materials：SBOMの作成ツールやサプライヤー、メーカーなど、アプリケーションや製品に関する情報
• コンポーネント：ライセンス情報、オープンソースコンポーネントなどの一覧
• サービス：外部APIに関する情報
• 依存関係：ソフトウェアにおける依存関係を表示

 

SBOMの作成方法と管理運用

SBOMは理論上、手作業でも作成できますが、現実的には自動生成ツールの活用が不可欠です。開発現場では依存関係が多く、ライブラリの更新頻度も高いため、手動管理では情報の正確性・鮮度が追いつきません。

現在、SBOM生成に対応したツールは多数存在しますが、特に注目されているのが以下のOSS系ツールです。

• Syft：静的解析ベースでSBOMを生成。CycloneDX・SPDX両対応
• GUAC：生成されたSBOMをグラフで可視化し、依存関係・リスクを直感的に分析可能
• Trivy：脆弱性スキャン＋SBOM生成を兼ね備えたオールインワン系

これらを使えば、Dockerイメージ・コンテナ・コードリポジトリなどさまざまな対象からSBOMを自動で抽出でき、開発者の負担を大きく軽減できます。

 

CI/CDと連携したSBOMの継続的運用

SBOMの本当の価値は、作成ではなく「運用」にあります。特に現代のアジャイル開発・DevSecOpsの環境下では、ソフトウェアが日々更新されるため、SBOMも更新され続けなければ実効性を保てません。

そのため、GitHub ActionsやJenkinsなどのCI/CDパイプラインにSBOM生成タスクを組み込み、「ビルドのたびに自動生成」という運用フローを確立するのが理想的です。

このようにSBOMは、開発→リリース→運用の全工程を貫く「ドキュメント」としての性格を色濃く有します。作って終わりではなく、作り続けられる仕組みが、現場におけるSBOM運用の成否を分けるポイントです。

 

SBOM導入時の注意点と解決策

SBOMを導入する際には、いくつかのボトルネックも存在します。特に懸念されるのは、「作成ツールの選定ミス」「運用フローの未整備」「フォーマットの混在」です。

たとえば用途に合わないツールを選ぶと、不要な情報が含まれていたり、逆に必要なライセンス情報が抜けていたりと、実用に足りないSBOMが生成されてしまいます。また、CI/CDとの連携や更新体制を構築しないと、SBOMはたちまち形骸化してしまうでしょう。

さらに、複数の部門やサプライヤーで異なるSBOM形式を使っていると、統合管理ができず、かえって可視性が低下するという本末転倒な状況にもなり得ます。

SBOMはメリットが多い反面、導入の設計ミスや「形だけ整える」運用には要注意です。目的に沿ったツール選定と、運用設計まで含めた導入がカギとなります。

 

SBOMと今後の開発トレンド

SBOMの価値の高まりは、近年のイノベーションやセキュリティ基準の広範囲化とも密接に関連しています。ここでは「生成AI」「トレーサビリティ」とSBOMの関係性を掘り下げていきます。

 

生成AI時代のSBOMに求められる視点

生成AIの台頭により、SBOMの重要性はさらに増しています。従来のSBOMは「ソフトウェア部品表」という性質が色濃いものでしたが、これからはAIを含む構成要素の全体像まで管理対象が広がることになります。

たとえば、生成AIを活用したソフトウェアでは、次のような項目の可視化が求められるようになっています：

• 生成AIモデルの種類（GPT、Stable Diffusionなど）
• モデルのバージョン・学習データの出自
• プロンプト設計・フィルタリングルール
• 推論時のセキュリティ設定・API連携範囲

これらを管理せずにAIを組み込んだソフトウェアを納品・出荷することは、著作権侵害や倫理的リスク、法的トラブルを招くリスクを排除できません。SBOMの対象範囲を生成AIまで拡張する、新しい視点が求められます。

つまり、SBOMは「AIを使っていない証明」ではなく、AI TRiSMとして問われるようになった共存戦略、つまり「AIをどう使っているかの透明性」が問われるようになるということです。

 

SBOMによるソフトウェア透明性の向上とトレーサビリティ

近年、ソフトウェアサプライチェーン全体の透明性と信頼性が重視されるなか、SBOMは安心して使えるソフトウェアの証明手段としての価値を高めています。

たとえば、ソフトウェアを納入する際に、SBOMを同梱することで以下のような効果が期待されます。

• 「どんな部品で構成されているのか」が説明できる
• 「誰が作ったか」「どこから持ってきたか」が追跡できる
• 「脆弱性やライセンス問題があるか」が事前に確認できる

つまり、SBOMは単なる内部管理のツールではなく、顧客やパートナーへの開発体制の見える化にもつながる資産です。SBOMは「作ればよい」から「見せられるようにしておくべき」ドキュメントへと進化していくでしょう。

 

日本でも急速に高まるSBOMへの関心

前述した通り、SBOMは国際的に必要と判断されたソフトウェアの管理ツールです。国内においても今後はさまざまな企業に欠かせないものとなっていくでしょう。

ADAS（自動運転支援システム）の組み込みソフトウェアはその最たる例です。そのほか、生活のいたるところにIT技術が活用されるようになった昨今、それらのサービス・製品を開発・製造する企業、またそうした企業のサプライヤーにとって、OSSを用いたソフトウェア開発は必要不可欠なものになっています。

しかし、完全なセキュリティ性を有するソフトウェアは存在しません。複雑化するソフトウェアのどこに脆弱性があるのか、どのサプライヤーが何のソフトウェアをどのように使用しているかを明確化できるSBOMが、企業の情報を守るベースとなることが期待されています。