SBOM

読み：えすぼむ　／　英語表記：Software Bill of Materials

• セキュリティ
• 性能・監視・運用

ソフトウェアを構成する部品の名前や版、提供元と依存関係などを記録した一覧である。機械で扱える形式を用い、脆弱性の影響調査やライセンスの確認などに利用する。

イマシルちゃんの解説

一つのアプリにも、ライブラリと呼ばれる再利用できるプログラムの部品がたくさん組み込まれていることがあるよ。
その部品に弱点が見つかっても、アプリの名前だけでは使われているか分からないんだ。
そこで役立つのが、ソフトウェアの部品表であるSBOMだよ。
どんな部品のどの版を使い、部品同士がどうつながるかを一覧にしておくんだね。
部品を使う別の部品まで調べられれば、直接は選んでいないものの影響も追いやすくなるよ。
機械で読み取れる形で管理すると、新しい弱点の情報が届いたときに調べるべき製品を素早く探せるんだ。

より深い解説

アプリケーションの名前だけでは分からない中身を示す

SBOMはSoftware Bill of Materialsの略で、ソフトウェア部品表とも呼ばれる。対象には自組織が作った部品と、外部から取り込んだ部品の両方があり得る。オープンソースだけの一覧ではなく、対象ソフトウェアが何によって構成されるかを説明する情報である。

例えば、あるライブラリの脆弱性が公表されたとき、利用者が知っているのは完成品の商品名だけかもしれない。そこで、製品に含まれる部品とその版をあらかじめ記録しておけば、調査すべき製品を絞り込める。CycloneDXの説明も、部品、版、部品間のつながりを機械で扱える形にすることを、影響調査やライセンス確認へつなげている。

SBOMを入手しただけで弱点が修正されるわけではない。記録を脆弱性情報や稼働資産の情報と結び付けて初めて、どこを調べ、誰が何を直すかという作業に利用できる。

直接選んだ部品の、その先までたどる

部品Aを使うために部品Bも必要となり、そのBがさらに部品Cを必要とする場合がある。このように間接的につながる関係を推移的依存関係という。開発者が自分で選んだ部品だけを列挙しても、完成品に含まれるすべての部品を把握できるとは限らない。

次は架空のアプリケーションと部品を使った例である。

Cの弱点が公表された場合、Aの担当者が「Cを直接導入した記憶がない」と判断しても、調査を終える根拠にはならない。どのBがCを取り込み、どの完成品にそのBが含まれるかを逆向きにたどる必要がある。

部品の階層が深いからといって、その先を安全とみなすこともできない。2026年の国際的な最小要素ガイダンスでは、間接的な部品も含めた記録範囲と、分からない情報を明示する考え方が示されている。部品の一覧が不完全な場合は、調査できた範囲を読めるようにすることが重要である。

同じ部品を正しく照合するための情報

名前だけが同じ別製品や、同じ部品の異なる版を取り違えると、影響する製品を正しく探せない。そのため、名称、版、作成元などを組み合わせて対象を識別する。部品単位の情報と、SBOM全体を誰がいつどのように作ったかという情報も区別して扱う。

パッケージの種類や名前空間などを含めて識別する表現にpurlがあり、ECMA-427で構文が定められている。製品名などを共通の形式で表す識別体系のCPE（Common Platform Enumeration）も、脆弱性情報との照合で使われる。ただし、どちらも付ければあらゆる情報源と自動的に正しく対応するわけではない。同じ版番号でも配布元の修正が異なる場合があるため、提供元のアドバイザリとの照合が必要になる。

ファイル内容から計算するハッシュ値は、対象の実物を照合する材料になる。値だけでなく使用したアルゴリズムと、どのファイルの値かを対応付ける。未知の項目を空欄のまま意味不明にするより、「未調査」「取得できない」など、採用する形式で表せる区別を残した方が調査の限界を判断しやすい。

共通形式を使って交換できるようにする

代表的な表現形式にはSPDXとCycloneDXがある。共通のデータ構造を使うことで、開発者、ソフトウェア提供元、利用者が別のツールを使っていても、部品情報を交換しやすくする。前者の仕様一覧と後者の公式説明が、それぞれのデータ表現を確認する入口になる。

形式名だけで互換性を判断せず、対応する仕様の版や実際に出力・読込みできる項目を確認する。JSONで保存されていても、異なる構造を期待するツール同士がそのまま連携できるとは限らない。受け取った文書が形式に適合するかという検証と、中身が正しい対象を記述しているかという確認は、別々に必要である。

ソフトウェアに含まれる部品を分析する技術はSCA（Software Composition Analysis）と呼ばれる。OWASPの部品分析の説明では、第三者が提供する部品などのリスクを調べる活動のうち、ソフトウェアを対象にした範囲として位置付けている。対応するツールには、分析結果を部品表として出力したり、既知の脆弱性やライセンス情報と照合したりするものがある。分析の機能、交換用のデータ、データを使って対処を進める管理活動は、それぞれ役割が異なる。

いつ作った一覧が、どの実物に対応するか

開発中のソースや依存パッケージの定義を調べた情報と、ビルド後の配布物を調べた情報は、対象範囲が同じとは限らない。ビルド時に解決された部品や、配布時に同梱される部品があるためである。稼働環境で追加されたプラグインや別途導入されたライブラリも、提供元の一覧だけでは分からない場合がある。

したがって、一覧を作った工程を示す生成コンテキストと、対象の版や成果物を結び付ける必要がある。前述の国際ガイダンスは、ビルドの前後などの生成時点の違いも扱っている。作成日時だけから「本番で動いているものの一覧」と推測してはならない。

例えば、コンテナイメージを更新した場合、その中のアプリケーションが同じ版でも、基盤となるOSのパッケージは変わり得る。このため、同じ製品名の最新一覧だけを保持するのではなく、配布するリリース単位で成果物と記録を対応付ける。古い版が稼働している間は、その版に対応する情報も参照できるようにする。

新しい脆弱性情報が公開されたときは、ソフトウェアを変更していなくても手元の一覧を再照合する必要がある。一方、部品構成が変わった場合や記録の誤りが分かった場合は、一覧自体も更新する。「新しい脆弱性がない」と「部品情報が最新である」は別の確認事項である。

部品が含まれることと、攻撃が成立することを分ける

部品表から、脆弱性情報に該当する名前や版を含む製品を抽出できる。しかし、弱点のある処理が製品に組み込まれていない、問題の機能が利用されない、攻撃に必要な条件が満たされない、といった場合もある。逆に、実行される機会が少ないからといって影響がないとは限らない。

特定の製品に対する脆弱性の影響判断を伝える情報がVEXである。部品の存在を説明する情報に、影響の評価と根拠を組み合わせる役割を持つ。OASISのCSAF 2.0仕様は、製品が影響を受けるかという状態と、必要な理由や対処情報の表現を定めている。CycloneDXにもこの情報を表す仕組みがある。

表は判断の意味をまとめたものであり、項目名や細かな表現は採用する形式によって異なる。影響なしという結論も、対象の版や機能、設定に関する前提を外して流用できない。製品や環境が変わった場合は、以前の判断が引き続き成立するかを見直す。

収集して保管するだけで終わらせない

利用側では、製品の調達時に受け取る形式、対象範囲、更新の受渡し方法、問い合わせ先を定める。受領時には内容を読めるか、対象製品や版が一致するか、調査できない部品がどれほどあるかを確かめる。提供元、開発部門、運用部門の間で、誰が訂正と更新を扱うかを決めておく必要がある。

そのうえで、脆弱性の通知を受け取ったら部品情報を検索し、候補となる製品と稼働場所を抽出する。提供元の影響判断や実環境の条件を照合し、必要な対策を担当者へ渡す。修正後は成果物と一覧の両方を更新し、実際の配備状況も確認する。経済産業省の導入手引も、環境や体制の整備、作成・共有、運用・管理という一連の活動を扱っている。

文書に電子署名を付ければ、出所や改変の有無を確かめる材料になる。ただし、署名された一覧の内容が完全であることや、部品に弱点がないことまで保証されるわけではない。SBOMは安全性の証明ではなく、調査と判断に使う構成情報である。

設計や運用の問題で「部品表があれば即座に安全か危険か分かるか」と問われた場合は、一覧の完全性、実物との対応、脆弱性の適用条件、影響判断の根拠を分けて考える。間接的な部品まで素早く探せる利点と、確認すべき条件が残ることを合わせて説明するのが適切である。

この用語が出てくる記事

• 脆弱性管理