SBOMについて
最近、SBOM（えすぼむ）という言葉をよく見る。
Software Bill of Materialsの頭文字をとっている。
BOM＝Bill of Materialsは、製造現場で部品表とか呼ばれて、製造物はどんな部品から構成されているかを示すもの。
それをソフトウェアの世界でやる場合、ソフトウェアがどのようなモジュールで構成されているのかを明らかにするものになる。
log4jで脆弱性が見つかった際、自分自身が明示的にlog4jを利用していれば利用の有無は分かる。しかし、他のオープンソースがlog4jを組み込んでいる場合、それを見つけ出すのは大変になる。これを推移的依存、と呼ぶらしい。
推移的依存では、脆弱性への対応に時間が掛かったり、対応が不十分になりやすい。
ソフトウェアで、どんなライブリの、どのバージョンを使用しているか一目で分かるようにするのがSBOMの役割。
最近の動向
アメリカでは、大統領令で政府機関と取引する企業にSBOMの提出を義務付けている。
日本では、経済産業省で検討されているようです。
マイクロソフトからも、SBOMを出力するツールが無償提供されています。
Dockerも、docker sbom コマンドでコンテナのSBOMを出力できるようになったようです。
SBOMの詳細
一口にSBOMと言っても、4パターン程あるようです。
・CycloneDX・・・OWASP
・SPDX・・・Linux fundation
・GitHub SBOM・・・GitHub
・SWID
出力されたSBOMを使用して、脆弱性の検知をする流れのようです。
OWASPにDependency Trackというプロジェクトがあり、これにSBOMを食わせると脆弱性などを表示してくれます。
今後、SBOMによるソフトウェアの構成の透明化は促進されると思われます。
ただ、べてのコンポーネントをもれなく抽出してSBOMに出力するには、課題もあるようで、開発者の制約にならないのか、気になるところです。