用語辞典

SBOM(ソフトウェア部品表)とは?脆弱性に素早く対応する仕組み

公開日:2026-10-07更新日:2026-10-30

結論:まずここだけ読めばOK

1.SBOMは、ソフトウェアに含まれる部品とそのバージョンを一覧にした「ソフトウェア部品表」
2.脆弱性が見つかった時に、「自分たちが影響を受けるか」を素早く判断するために使う
3.形式には、SPDXやCycloneDXなどがあり、ビルド時にツールで自動生成するのが一般的
4.SBOMを作るだけでは安全にならない。最新の状態に保ち、脆弱性情報と突き合わせて初めて役に立つ

詳しい手順・原因は、この下で解説しています。

用語辞典のイラスト

一言でいうと

**SBOM(Software Bill of Materials)とは、ソフトウェアに含まれる部品を一覧にした「ソフトウェア部品表」**のことです。どんな部品(ライブラリやモジュール)が、どのバージョンで、どんな関係で組み込まれているかを、記録します。

たとえ話:食品の原材料表示

スーパーで食品を買う時、パッケージの原材料表示を見ます。アレルギーのある人は、そこで、「自分が食べてはいけない原料が入っていないか」を確認できます。

SBOMは、ソフトウェアの原材料表示のようなものです。「このソフトには、どんな部品が入っているのか」が分かるので、問題のある部品が見つかった時に、「自分たちのソフトに入っているか」を、すぐに確認できます。

なぜ必要とされているのか

現在のソフトウェアの多くは、オープンソースなどの既存の部品を、組み合わせて作られています(オープンソースとは、ライブラリとは)。部品の中に、さらに別の部品が使われていることも多く、全体として何が入っているのかを、開発者自身も、把握しきれなくなっています。

この状況で、ある部品に重大な脆弱性が見つかると、**「自分たちのシステムで、その部品を使っているか」**を確認するだけで、大きな手間がかかります。2021年末に、広く使われていたログ出力の部品で重大な脆弱性が公表された際には、影響範囲の特定に苦労した組織が多かったと言われています。こうした経験から、部品を一覧で把握しておく仕組みとして、SBOMが注目されるようになりました。日本でも、経済産業省が、導入に向けた手引きを公開しています。

脆弱性が公表された時に、SBOMと照らし合わせて対応する流れの図解

SBOMに記録される主な情報

項目	内容
部品の名前	どのライブラリ・モジュールか
バージョン	どの版を使っているか
提供元	誰が作ったものか
依存関係	どの部品が、どの部品の中で使われているか
ライセンス	どんな利用条件か

バージョンの情報があるからこそ、「この版には脆弱性がある」という公表と、照らし合わせられます。

主な形式

SBOMには、いくつかの標準的な形式があります。

形式	特徴
SPDX	もともとライセンスの管理を目的に作られた形式。国際規格としても整理されている
CycloneDX	セキュリティ用途を意識して作られた形式。脆弱性の管理に使いやすい

実際には、ビルドのたびに、ツールで自動的に生成するのが一般的です。手作業で作ると、すぐに古くなってしまうためです。生成の流れは、CI/CDとはの仕組みに組み込むことも多くあります。

SBOMの限界

作っただけでは、安全にならない:一覧があっても、脆弱性情報と突き合わせ、対応しなければ意味がありません
古くなる:部品を更新したのに、SBOMが更新されないと、実態と合わなくなります
全体は把握できない:実行時に外部から読み込む部品などは、一覧に載らないことがあります

大事なのは、「作る」こと自体より、「更新して、使い続ける」ことです。

用語	意味
CVE	公表された脆弱性に、付けられる識別番号。SBOMの部品情報と突き合わせて、影響の有無を調べる
SCA(ソフトウェア構成解析)	使っている部品を調べ、既知の脆弱性やライセンスの問題を見つけるツールや手法
脆弱性管理	見つかった脆弱性の、影響を判断し、優先順位をつけて対応する活動全体
ライセンス管理	部品ごとの、利用条件を把握し、違反を防ぐ活動

「今、動いている」ことは、安全の証拠ではない

システムが正常に動いていると、内部で使っているライブラリや構成を、見直す優先順位が、下がりがちです。しかし、今、問題なく動いていることと、今後も安全に使い続けられることは、別です。

古いライブラリに依存していて、脆弱性が公表されても、どのシステムが、そのライブラリを使っているのかを把握できていなければ、影響を調べるだけで、時間がかかります。SBOMは、その把握を、事前にしておくための仕組みです。問題が起きてから慌てて調べるのではなく、構成を把握し、対応できる状態を作っておく。これがSBOMの価値です。

技術的負債の「所在」を、把握するための道具

「動いているから、触れない」システムの改修を依頼された時に、強く感じることがあります。担当者しか分からない処理、古いライブラリ、ドキュメントの不備、重複したコードが重なると、小さな改修にも、時間がかかってしまいます(技術的負債とは)。

技術的負債は、完全にゼロにすることよりも、どこに借金があるのかを、把握しておくことが大切だと考えています。SBOMは、そのうち「部品に関する借金」、つまり、古くなった部品や、更新されていないライブラリがどこにあるのかを、見える形にする道具です。

また、オープンソースの部品は、無料で使えても、人件費、学習コスト、保守、セキュリティ対応といったコストがかかります。「無料かどうか」ではなく、自分たちが責任を持って、使い続けられるかで、採用を判断するようにしています(オープンソースとは)。何を使っているかを把握していなければ、その判断もできません。