セキュリティの
学び場

SBOMとは

最近話題のSBOM、皆さんもどこかで言葉を耳にしたことがあるかと思います。

SBOMとはSoftware Bill of Materialsの略で、「ソフトウェア部品表」と訳すことができます。
「部品表」とは製造業の用語で、ある製造物に必要な部品や材料の情報を一覧化した表のことです。もちろん、ある部品はさらに別の部品や材料を用いて作成されるため、部品表は入れ子の形をとります。

SBOMも同様の考えです。現代の開発では、ソフトウェアを誰からの成果物もなしでゼロから作ることは考えられず、例えばオープンソースや商用のライブラリやフレームワークなどのコンポーネントを用いることがほとんどでしょう。これらを部品とみなしてまとめたものがSBOMなのです。

なぜSBOMが注目されているのか

SBOMが注目されている理由、それはソフトウェアサプライチェーンリスクと関連します。ソフトウェアサプライチェーンリスクについては過去のブログで取り上げたのでそちらも参照してください。

ここでは、主にソフトウェア開発における問題に着目します。ソフトウェアプロダクトを開発したり、運用したりするにはさまざまなコンポーネントが使われるのは説明した通りです。もし、そういったコンポーネントに脆弱性が含まれていたらどうでしょう。使い方によっては、コンポーネントの脆弱性がプロダクトの脆弱性として顕現することが考えられます。また脅威は脆弱性だけではありません。悪意ある攻撃者が特定のコンポーネントを乗っ取ったり偽装したりして、バックドアなどの有害な機能を入れ込むことも考えられます。

したがって、コンポーネントの危険性を把握し、必要なときにすぐに対応をとれるようにすることが大事です。

しかし物事はそう簡単ではありません。先にも述べたとおり、あるコンポーネントがまた別のコンポーネントを利用しているという入れ子の関係になっていますので、そういった「依存関係」の末端のコンポーネントに脆弱性が存在した場合も、それを確実に把握しなければならないのです。

そこでSBOMです。SBOMによってプロダクトが「依存する」コンポーネントを確実に把握することで、そういった「間接的な依存関係」を持つコンポーネントに脆弱性があった場合、確実にそれを把握し、対応できるようになります。

いわばSBOMは、ソフトウェア開発におけるサプライチェーンの可視化であり、サプライチェーンの中に脆弱性が存在する、あるいは悪意のあるコンポーネントが混入する可能性を可視化でき、早期の対応を可能にするというわけです。

SBOMの主要なフォーマット

SBOMには広く知られたフォーマットとして、The Linux Foundationが仕様策定してISO標準になっているSPDX（The Software Package Data Exchange）と、OWASPが作成しているCycloneDXがあります。いずれも一長一短ありますし、生成・管理できるツールのエコシステムが異なっているのでどちらを選べばよいかと一概にいうことはできませんが、この二つの名前を覚えておくとよいでしょう。

SBOMを作るには

さてこのように利点が多くあるSBOMですが、どうやって作成すればよいでしょうか。

ソフトウェアプロダクトの「依存関係」を自動的に解釈してSBOMを生成するツールとして、いわゆるソフトウェア構成分析ツール（SCAツール）があります。商用のツールもありますし、先に述べたSPDX/CycloneDXでも周辺ツールとして、プログラミング言語の依存関係管理ツールからSBOMを出力するオープンソースを提供しています。「言語名 SBOMフォーマット名」で検索すると出てきますので、ぜひチェックしてみてください。

ソフトウェアをDockerなどのコンテナに入れて運用する場合、そのコンテナの内部に不正なソフトウェアがないかを知るためにSBOMを作りたいと思うでしょう。そういったツールも存在します。

また、社内でのみ流通しているライブラリやフレームワークなど、自動生成には乗ってこないソフトウェアコンポーネントを管理したいという場合もあるでしょう。そのような場合はGUIによるSBOM管理ツールも複数あるので、それらを用いて手動でデータを補うこともできます。

参考資料

以上SBOMについてまとめてきましたが、SBOMについては経済産業省 商務情報政策局による「ソフトウェア管理に向けたSBOM（Software Bill of Materials）の導入に関する手引」が非常によくまとまっているので、本記事で関心を持った方が次に読むのにおすすめです。