ソフトウェア開発の現場では、ゼロから全部のコードを書くことは殆ど無い。

多くの場合、世界中の開発者が公開しているオープンソースソフトウェア（OSS）や、既存のライブラリを組み合わせて作られている。

ただ、この“部品の寄せ集め”には落とし穴がある。

もし使っている部品のひとつにセキュリティの欠陥が見つかったら？

もしあるOSSのライセンス条件を満たしていなかったら？

そんな時に頼りになるのが、ソフトウェアの「部品表」、つまりSBOM（Software Bill of Materials）となる。

この記事では、このSBOMが何なのか、そしてOSSライセンスとどんな関係があるのかをまとめておきたい。

特に知財部員（法務部員）としては、OSSライセンス管理を行う場合もあるかと思うので、SBOMについて理解を深めておくに越したことは無いと思う。

そもそもSBOMとは？

SBOM（Software Bill of Materials）とは、製品に含むソフトウェアを構成するコンポーネントや互いの依存関係、ライセンスデータなどをリスト化した一覧表のことである。

ソフトウェアは、殆どが自分でゼロから全部作っているわけではなく、オープンソースソフトウェア（OSS）や既製のライブラリを組み合わせて作られている。

SBOMは、その「中に何が入っているか」を一覧にしたドキュメントとなる。

例えば、

  • このアプリは「ライブラリA（バージョン1.2.3）」を使っています
  • さらに「OSSライブラリB（MITライセンス）」も含まれています

といった情報がSBOMに含まれる。

なぜSBOMが必要なのか？

SBOMが注目される理由は、大きく３つある。

  • セキュリティ

もし部品のひとつに脆弱性（セキュリティの穴）が見つかった場合、SBOMがあれば「どの製品にその部品が使われているか」がすぐ分かる。

  • 法的リスクの回避

OSSにはさまざまなライセンス条件（MIT、Apache、GPLなど）があり、それぞれに遵守すべきルールがある。

SBOMがあれば、どのOSSを使っているかが明確になり、ライセンス違反のリスクを減らせる。

  • 顧客や取引先への透明性

ソフトウェアの品質や安全性を証明する材料として、SBOMは信頼性を高める手段になり得る。

SBOMとOSSライセンスの関係

OSSライセンスは言うなれば「そのソフトウェアやコードをどう使っていいか・配布していいか」を決めたルールブックである。

例えば、以下のようなものである。

  • MITライセンス → ほぼ自由に使えるが著作権表示は必要
  • GPLライセンス → 改変・再配布時にソースコードの公開義務あり
  • Apacheライセンス → 特許権の扱いも含む詳細な条件あり

これらの情報を整理する上で、SBOMが役立つ。

SBOMにソフトウェア部品（パッケージやライブラリ）毎のOSSの名前とライセンス情報が載っていれば、開発チームや法務部門は「このOSSはGPLだから配布方法に注意しよう」などの判断がしやすくなる。

SBOMでリスト化される単位

リスト化される単位だが、基本的には「外部から取得したソフトウェア部品（パッケージやライブラリ）」単位となる。

ただし、用途や生成ツール、利用するSBOM標準によって粒度は変わってくる。

一般的な単位

SBOMでは、次のような単位が多い（下に行くほど小さい単位）。

  • パッケージ単位：依存関係管理ツールが管理する「1つの外部依存パッケージ」ごとに記載
  • ライブラリ単位：OSパッケージやシステムライブラリを含む「外部で提供されたライブラリ」ごとに記載
  • コンポーネント単位：ソフトウェア構成管理ツールが定義する論理的な部品ごとに記載
  • ファイル単位（詳細）：ソースコードやバイナリの特定ファイルごとに記載

標準仕様ごとの傾向

SBOMの主要な仕様には次のようなものがある。

  • SPDX（Software Package Data Exchange）→ パッケージ単位からファイル単位まで細かく書ける。ライセンス情報も詳細に記録可能。
  • CycloneDX → アプリの依存関係やサプライチェーン全体を表すのが得意。パッケージ単位が多い。
  • SWID（Software Identification Tags） → インストールされたソフトウェア単位（製品やパッケージ）を識別。

実務では、最小はファイル単位、最大は製品単位まで幅があるものの、現実的には「依存パッケージごと」の粒度が多い。

目的による単位の違い

目的がセキュリティ管理なら、パッケージ単位で十分なことが多い（脆弱性DBと突き合わせやすい）。

一方、目的がライセンス管理なら、１つのパッケージ内で複数ライセンスが混在する場合もあるので、場合によってはファイル単位まで必要となる。

まとめ

SBOMはソフトウェアの「中身のリスト」であり、OSSライセンスは「その中身をどう使っていいかのルール」である。

両者は密接に関係していて、SBOMがあればOSSライセンス違反やセキュリティリスクを減らせるので、実務上はOSSライセンス管理をする上でSBOMをうまく活用することが重要である。

関連記事