SBOM（ソフトウェア部品表）とは？― 製造業の「部品表」と同じ発想が、ソフトにも求められる理由

ある広く使われているソフトウェア部品に重大な脆弱性が見つかった——というニュースが流れたとき、製造業の現場では同じ問いが発生します。「うちの製品に、それは入っているのか」。この問いに数時間で答えられる企業と、数週間かかる企業がいます。差を生むのが SBOM（Software Bill of Materials：ソフトウェア部品表）です。この記事では、製造業の視点からSBOMを整理します。

01SBOMとは何か ― 部品表のソフト版

発想は単純で、製造業のBOM（部品表）とまったく同じです。製品にどの部品が、どのメーカーの、どのバージョンで入っているかを一覧にする。それをソフトウェアに対して行うのがSBOMです。

とくに入れ子構造の行が重要です。製造業でも「買った部品の中身までは把握していない」という問題がありますが、ソフトウェアではこれが顕著です。1つのライブラリを使うと、そのライブラリが依存する別のライブラリが自動的に付いてきます。それがさらに別のものを呼び——という連鎖が、数十から数百の階層になることも珍しくありません。

SBOMに書かれている内容

実物のイメージを持っておくと理解が早くなります。形式によって項目名は異なりますが、おおよそ次のような情報が並びます。

ライセンスの行は、セキュリティとは別の理由で重要です。OSSには利用条件があり、条件によっては自社のソースコードの公開を求められる場合もあります。「知らずに使っていた」が後で問題になるのは、脆弱性だけではありません。

「直接使っているもの」は氷山の一角

製造業に置き換えるなら、「購入した完成ユニットの中に、どのメーカーのどのグレードの部品が入っているか」を全階層にわたって把握している状態にあたります。モノの世界では現実的に難しいことが多いのですが、ソフトウェアはツールで機械的に抽出できるため、実現が求められる水準が高くなっています。

02なぜ必要になったのか

直接のきっかけは、広く使われているOSSに深刻な脆弱性が見つかる事案が繰り返されたことです。世界中の製品に組み込まれていたため、影響範囲の特定に膨大な時間がかかりました。

「調べれば分かる」と「一覧を見れば分かる」の差です。これは製造業で、リコール時に「材料ロットがどの製品に入ったか」を追えるかどうかの差と、構造的にまったく同じです（「トレーサビリティとは」）。

03形式 ― SPDXとCycloneDX

SBOMは自由な様式では意味が薄れます。受け取る側が機械的に処理できる必要があるため、標準の形式が使われます。代表的なものが2つあります。

経済産業省も「ソフトウェア管理に向けたSBOMの導入に関する手引」を公開しており、この2つの形式の採用を前提とした整理をしています。国内で検討を始めるなら、まずこの手引が実務的な出発点になります。

04どこで求められるのか

05実務上の難所

• 外注ソフトの中身が分からない：委託先が何を使っているか、契約に含めていないと開示されません。新規の委託契約から順に条項を入れるのが現実的な進め方です
• 組み込み機器の古いソフト：10年前に作られたファームウェアの構成が、資料としても人の記憶としても残っていない
• バージョンの粒度：「Xを使っている」では足りず、どの版かまで必要
• 更新の追随：SBOMは一度作って終わりではなく、ソフトを更新するたびに作り直すもの
• 受け取ったSBOMの検証：内容が正しいかを確認する手段が限られる

2番目は、製造業の現場感覚に近い問題です。長く売り続けている製品ほど、中身の記録が残っていない。設備の図面が行方不明になるのと同じ現象が、ソフトウェアでも起きています。

06製造業のBOM管理との共通点

ここまで読んで、既視感を覚えた方も多いはずです。SBOMが解こうとしている問題は、製造業がずっと向き合ってきた問題と同じ形をしています。

共通するのは、「入っているものを一覧にしておかないと、問題が起きたときに範囲を絞れない」という一点です。含有化学物質調査（「chemSHERPAとは」）も、デジタル製品パスポート（「DPPとは」）も、根っこは同じ発想です。

07よくある誤解

• 「SBOMを作れば安全になる」：SBOMは一覧であって対策ではありません。脆弱性が見つかったときに素早く動けるようになる、という道具です
• 「一度作れば終わり」：ソフトを更新するたびに作り直すものです
• 「ソフト会社の話」：製品にソフトが組み込まれていれば、製造業でも対象になりえます
• 「外注しているから自社には関係ない」：外注先から受け取る責任が生じます。契約に含める必要があります
• 「形式はどれでもよい」：受け取る側が処理できる形式である必要があります。取引先の指定に従うのが基本です

08まとめ

• SBOMはソフトウェアに含まれる部品の一覧。製造業のBOMとまったく同じ発想
• 脆弱性公表時に「自社製品に影響があるか」を即座に判断するために使われる
• 形式はSPDXとCycloneDXが主流。経済産業省も導入の手引を公開している
• EUのCRAや医療機器の分野で要求が具体化しており、ソフトが組み込まれた製品を作る製造業にも及ぶ
• 難所は外注ソフトの中身の把握と、古い製品の構成記録。長寿命製品ほど厳しい

09この記事とQUALIKEEPの関係について

率直にお伝えします。このテーマに関して、QUALIKEEP にできることはありません。SBOMの生成、ソフトウェア構成の解析、脆弱性の照合——いずれも対象外で、QUALIKEEP は原材料や副資材といった物理的なモノの受入・期限・ロットを記録するサービスです。ソフトウェア資産の管理機能は持っていません。

この記事を書いたのは、発想が共通しているからです。「入っているものを一覧にし、問題が起きたときに範囲を絞れるようにする」という考え方は、モノでもソフトでも変わりません。もし読者の会社で、モノの側でも同じ問題——「どの製品にどの材料ロットが入ったか、すぐには分からない」——が起きているのであれば、そちらは QUALIKEEP が扱える領域です。