はじめに
本日は、Linux Foundation Japan Community Daysの一つ：OSSガバナンス トラックの2つ目のセッション：「Are you ready for CRA ? – SBOM –」での「SBOM Basics」の内容を紹介したいと思います。
SBOMとは
まず、はじめに、すでにご承知と思いますが、SBOM = Software Bill of Materialsです。
「対象ソフトウェアの構成要素(component)とそのサプライチェーン内での関係性を記録したもの」がSBOMになります。
「ソフトウェアの成分表」＋「ソフトウェアの系統図」であり、OSSだけではなく、Proprietaryなソフトウェアも含めたすべてのソフトウェアの構成要素が対象となります。
食品の原材料表示になぞらえて説明されることがよくあり、料理の材料表とレシピのようなものとイメージしていただくと良いと思います。
当初は、対象ソフトウェアの構成要素を列挙した単純なリストでしたが、現在は、階層的な包含関係や生成関係を示す構造化データに変わってきています。
SBOMはなぜ注目されることになったか
当初は、OSSライセンス条件である、著作権表示とライセンスの通知の手段としてSBOMが始まったと思います。SBOMだけで完全にOSSライセンスを遵守できるわけではありませんが、「提供物（製品）に含まれているOSSのリスト」を提供することは、受け取り手がOSSライセンスを守ることに役立ちます。この段階では、SBOMはOSSを扱う限られた人々の間で使われる言葉でした。
数年前から、サイバー攻撃が国家・社会に与える影響が甚大であることから、2021年の米国大統領令：EO14028や、2022年に草案が出され2024年12月10日発効の EU Cyber Resilience Act (CRA)において、SBOMが求められたことからSBOMについての議論が活発化し、ソフトウェアを直接扱わない人々にもSBOMが知られるようになりました。
SBOMはなぜ必要か
SBOMはソフトウェアの安全・信頼を保つための重要な手段となっています。
対象ソフトウェアの素性を明らかにして安全・信頼を確認したり、そのソフトウェアを利用してよいかどうかの判断（ライセンスコンプライアンス、懸念サプライヤー・開発者の回避など）に使われます。
さらに、広く知られている既知の脆弱性のあるソフトウェアが含まれないことの確認や、新たに発見されるセキュリティ脆弱性のある構成要素を含むかどうかを、短時間に確認し、必要な対応に着手することができます。
短時間での確認を可能とするために、機械処理可能なデータであることもSBOMの重要な要件です。多くの組織からなるサプライチェーンによって構築された大規模なソフトウェアの中に該当の構成要素が含まれるかどうかを速やかに確認するためには、機械支援が必須です。
SBOMがなければ、サプライチェーンの上流の組織で開発されたソフトウェアに新たな脆弱性が発見された場合に、その組織からの連絡がサプライチェーンの順に伝えられて手元に届くまで、脆弱性対応に着手できません。
手元にSBOMがあれば、脆弱性が発見された上流のソフトウェアを含んでいることがすぐにわかり、早期に対応着手できます。システムが重要であればあるほど、少しでも早く対処を始めることが被害を拡大させないことにつながります。
誰がSBOMを利用するか
SBOMは開発者だけではなく、調達担当者、システム運用者・サポート担当者、そして、政府のサイバーセキュリティ機関など、ソフトウェアを直接・間接に扱う人、部門が、それぞれの立場でソフトウェアの安全・信頼を保つために利用します。
SBOMの作成
SBOMは誰がどうやって作るのでしょうか？
ソフトウェアの規模が大きくなり、ツールによる支援なしではSBOMを扱えなくなってきていますが、ツールだけでは正確な情報が得られないというのが現状だと思います。
ソースコードがあれば、何が含まれているかを調べることは可能です。しかし、それがどこで作られたのか、改変されているか、ライセンス選択が可能な場合の選択結果など、ソースコードだけでは判別できない場合があります。
自身が作成した部分や自身が関与した部分については、SBOMに必要な情報は自分が正しい情報を持っています。自分しか知らない情報である場合もあります。そのため、ソフトウェア作成中にSBOMの基礎情報を記録し、ソフトウェアの完成時にSBOMをまとめ、ソフトウェアと共にSBOMを提供することが求められると思います。
同じように、他者から入手したソフトウェアについては、他者が正しい情報を持っているわけですから、入手元からSBOMを入手することがベストです。
現状では、入手元からSBOMが得られないケースもありますが、ソフトウェアがサプライチェーンでやり取りされて最終のシステムが作られるように、SBOMもサプライチェーンを通して共同で完成させるようになると良いと思います。
SBOMの共同作成のために
サプライチェーン内の組織が共同でSBOMを作るためには、SBOMのフォーマットや、基本ルールの基準が必要です。
しかし、現在、これらが確定しているとは言い切れず、コミュニティや行政機関にて、情報発信や議論が続けられている状態です。
この状況については、12/7の記事で紹介がある予定ですが、ほとんどが、OSSと同じくオープンコラボレーションで議論が進められています。
OSSが単に利用するだけでなく貢献することによってよりよく活用することができるように、これらの議論の状況を見ているだけでなく、議論に参加し貢献してゆくことで、SBOMを適切に扱えるようになるのではないかと思います。
おわりに
以上、SBOMについての基本的な説明をしましたが、お読みいただいた方の何らかのお役に立っていれば幸いです。