ソフトウェアは、多数の外部の部品を組み合わせて作られる。開発を速くするこの仕組みは、一つの部品の問題を多くの製品へ広げる経路にもなる。自分で書いたコードだけを確認しても、全体の安全性は分からない。
直接使う部品の、その先にも部品がある
画像を読むライブラリが、圧縮を扱う別のライブラリへ依存することがある。開発者が直接選んでいない部品も、依存関係を通じて入ってくる。どの版が実際の製品に含まれるかを把握する必要がある。
不具合は偶然に生じる場合も、配布経路や開発者のアカウントが侵害されて混入する場合もある。ソースコード、ビルド、配布、更新の各段階が、ソフトウェアの供給網を構成する。
部品表があると、影響を探しやすい
SBOMは、ソフトウェアに含まれる部品と依存関係を記録するための情報である。あるライブラリの脆弱性が判明した際、どの製品が該当するかを調べる手掛かりになる。
部品名だけでは、脆弱な機能を実際に使っているかまでは分からない。版、構築方法、利用条件と照合して、影響と対応の優先順位を判断する。
更新できることも、品質の一部である
依存関係を固定すれば再現しやすくなる。固定したまま更新できなければ、修正が取り込めなくなる。更新候補を検証し、問題があれば戻せる仕組みを作ることが重要になる。
署名やハッシュは、配布されたものが想定したファイルかを調べるのに役立つ。正規の配布元が侵害された場合まで、それだけで無害だと証明できるわけではない。利用する権限を絞り、影響が広がる範囲も抑える必要がある。
SBOMは安全性の認証ではなく、構成を把握するための資料である。作成時点と実際に稼働している版がずれていないかを確認する必要がある。
参考資料
参考資料確認日：2026年10月13日。