実はこのSBOM、もともとのBOMが製造業での言葉ということもあり、実はTechFactoryの読者の方が、ITの人よりもより簡単に理解できるキーワードになっているかと思います。製造業の文脈では、完成品に至るまでに必要な部品の表を作り、情報を一元管理することで工程管理や原価管理、そして不良品が発生した時の原因究明などに使える仕組みです。これがあることにより、品質が一定になるということも重要かもしれません。その意味では、製造業になくてはならない考え方だと思います。

　では、なぜこれが「ソフトウェア」でも注目されているのでしょうか。まず、ソフトウェアの作り方を考えてみます。最近のソフトウェアはいちから全てを作るということはほとんどしておらず、オープンソースソフトウェアやライブラリといった、既に完成しているプログラムのパーツを組み入れて製作するのが一般的です。これにより、高度な機能を持つソフトウェアを、短時間で組み上げることができます。皆さんもPCを使うときに、OSであるWindowsやLinuxから作る人はいないでしょう。それと同じことが、ソフトウェア単体でも行われているのです。

　そして、その仕組みはいくつかの“弱い”ところがあります。例えばそのパーツとして組み入れた小さなプログラムに不具合があったとき、当然ながら完成されたソフトウェアにも不具合が埋め込まれた形になります。こうならないよう、製品（プログラム）のテストがしっかりと行われていれば良いのですが、テストが漏れていたり、そもそもテストしにくいような「脆弱性」が含まれていた場合、非常に大きな問題となります。特にIoTや自動車のように、製品の中に組み込まれたプログラムはそう簡単にアップデートができません。アップデートができたとしても、不具合を持つパーツを組み込んだプログラムがどの製品に含まれているのか、すぐに把握することが難しいのです。

　2021年12月に大きな話題になった「Apache Log4j」の脆弱性「Log4Shell」は、その影響範囲が非常に大きいだけでなく、そもそもどの製品にこの脆弱性が含まれるのかが分かりにくいことが問題となりました。Apache Log4jと名付けられたプログラムだけでなく、該当のコンポーネントを含む製品が多数あったのです。例えば米マイクロソフト社が提供する子どもたちに人気のゲーム「Minecraft」も、このコンポーネントを含むことから脆弱性対応の修正が出ました。おそらく、いまでも未対応のプログラムは多数存在するはずです。

　そこで、オープンソースソフトウェアを始め、このプログラムがどのような「部品」で構成されているのかを、あらかじめ定義したフォーマットで一覧する仕組みを作り、何らかの問題のある部品が見つかったとき、その部品を含むプログラムはどこにあるのかを把握できるように考えたのが、ソフトウェアのBOM「SBOM」なのです。これがあれば、脆弱性がどうプログラム内に残っているのか、影響はどの程度あるのかが分かるはずです。

　2021年5月12日に発行された米国大統領令「Improving the Nation's Cybersecurity」では、サイバー攻撃に対して「デジタルインフラの透明性を高める」ための対策の一つとして、SBOMの導入が明記され大きな注目を集めました。そして日本でも2023年7月、経済産業省はこのSBOMに関する手引き書を公開しました。SBOMをさらに知りたいかたは、ぜひこちらも目を通してみてください。

図1　「ソフトウェア管理に向けたSBOM（Software Bill of Materials）の導入に関する手引」の全体概要