トレンドマイクロ製品の安全性・透明性向上のための5つの取り組み　第3回～ソフトウェアの脆弱性のリスクを可視化するSBOM～

「製品がどんな要素からできているのか？」に注目が集まる昨今のソフトウェア開発事情

「サプライチェーンリスク」という言葉を、近頃頻繁に耳にするようになりました。「サプライチェーン」とは物品が供給されるプロセスのことを指しますが、このプロセスを経由する中で発生するリスクについて様々な懸念が生じています。このリスクは物流などに限らず、ソフトウェア開発においても生じており、こちらの記事では、ソフトウェアのサプライチェーンリスクを考えるうえで重要な要素となっている「SBOM（Software Bill of Materials）」と当社の取り組みついて紹介したいと思います。
参考記事：ソフトウェア・サプライチェーンの脆弱性管理に求められるSBOMの必要性

「SBOM」とは何？

SBOMはSoftware Bill of Materialsの頭文字をとったもので、「エスボム」と読みます。SBOMは、該当のソフトウェアが「どのような要素から構成されているのか？」をリストにしたものです。
何らかの食品に対してアレルギーのある方に分かりやすいように、食品表示というものがありますが、これはその食材がどんな材料から作られているのかを表示したものです。食品表示を確認することで、アレルギーを引き起こさないか？（アレルゲンがないか）を確認することができます。
ソフトウェアにおいて、この食品表示にあたるものが「SBOM」です。ソフトウェア開発において、イチからすべてを自社内で開発するケースは非常に珍しく、一般的には様々なオープンソースソフトウェア（Open Source Software、以下OSS）を活用しながらソフトウェア開発が行われます。OSSを利用することで、品質が高く、スピーディな開発が可能になる一方で、完成した製品だけを見ると「どのようなOSSを使用しているのか分かりにくくなってしまう」というデメリットがあります。
このような状況から、2021年5月にはアメリカでSBOM作成を指示する旨の大統領令が出されました^※1。またヨーロッパにおいても欧州委員会が、2022年9月にデジタル製品のサイバーセキュリティー対応を義務付けるサイバーレジリエンス法案（草案）を発表し、デジタル製品のメーカーに対して、SBOM作成を含めたセキュリティ要件への適合を求める内容になっています^※2。
※1 米ホワイトハウス『Executive Order on Improving the Nation’s Cybersecurity』
※2 経済産業省『EUサイバーレジリエンス法（草案概要）』

また、日本でも同様にSBOMの普及の必要性が認識されており、経済産業省のサイバー・フィジカル・セキュリティ確保に向けたソフトウェア管理手法等検討タスクフォース等の有識者によってSBOMの普及へ向けた議論が定期的に行われ^※3、2023年7月には『ソフトウェア管理に向けたSBOM（Software Bill of Materials）の導入に関する手引』（Ver.1.0）が公開されました^※4。本手引書作成にあたり、トレンドマイクロはソフトウェア分野のSBOM実証に協力しました^※5。
※3 経済産業省サイバー・フィジカル・セキュリティ確保に向けたソフトウェア管理手法等検討タスクフォース
※4 経済産業省『ソフトウェア管理に向けたSBOM（Software Bill of Materials）の導入に関する手引Ver. 1.0』
※5 経済産業省『サイバー・フィジカル・セキュリティ確保に向けたソフトウェア管理⼿法等検討タスクフォースの検討の⽅向性』（※6ページ参照）

SBOMがあることのメリットとは？

SBOMがあることで、どのようなメリットが享受できるのでしょうか？考えられるケースとして、インパクトの大きな脆弱性が公開された際の対応速度の向上が１つ挙げられます。インパクトの大きい脆弱性が公開されたとき、SBOMがあれば、企業内で利用しているソフトウェアに該当の脆弱性があるかどうかをすぐに確認することができ、脆弱性を突かれる前に迅速にパッチ適用することで、攻撃を防ぐことができます。

もしSBOMがなかった場合、自社環境に該当の脆弱性があるかどうか判断が難しく、該当のソフトウェアメーカーに問い合わせを行うなど、確認に時間がかかってしまうことが想定されます。これにより、パッチ適用が間に合わなくなり、セキュリティ被害に遭う可能性が高まります。2021年12月にJava向けのログ出力ライブラリとして広く利用されている「Apache Log4j」の脆弱性（通称Log4Shell）が公開されました^※6。
※6 トレンドマイクロ『Apache Log4jの脆弱性「Log4Shell」(CVE-2021-44228)』

Log4Shellのようにインパクトが大きいにもかかわらず、攻撃難易度が低い脆弱性は攻撃者にとって使い勝手もよいと考えられます。さらにApache Log4jは多くの製品で利用されており、かつOSS内のライブラリの1つであるため、各種プログラム内に埋め込まれているケースも多く、影響範囲の特定に時間がかかってしまったという声も発覚当時には聞かれました。Log4Shellは2022年に入っても米CISA（サイバーセキュリティー・インフラストラクチャー・セキュリティー庁）が「2021年に日常的に悪用された脆弱性のTop15の1つ」に挙げるなど、最も攻撃を受けやすい脆弱性の1つとなっています^※7。
※7 関連記事：『サイバー犯罪者はどの脆弱性を悪用しようとしているのか？』

トレンドマイクロのSBOMへの取り組み

現在トレンドマイクロでは、製品のSBOMを必要に応じて提供できるように、社内での検証を実施しています。完璧なように聞こえるSBOMですが、まだ課題があり十分な検証を経る必要があるためです。
例えば、SBOMを手作業で作成することは非常に工数がかかり、抜け漏れが発生するリスクも高いと考えられているため、基本的にはSBOMはツールなどで自動生成されることが望ましいとされています。しかし、ソフトウェアの構成は非常に複雑で、ソースコードを辿って分析した場合でも、100%すべての依存関係を洗い出すことは難しいのです。そのほかにも、標準フォーマットの検討など以下のような課題があります。

●SBOMについて現状可能なこと・課題＜現状で可能なこと＞
・SCA（Software Composition Analysis（ソフトウェア構成分析ツール^※8）や、開発者プラットフォームで公開されている無償ツールなどを用いればSBOM作成自体は容易
※8 ソフトウェアを構成するコンポーネントの管理ツール。OSSなどのライセンス管理、脆弱性に関する情報提供と管理などに用いられ、SBOM生成機能があるものもある。

＜課題＞
・現状、SBOMを効率よく管理するツールが存在しない（複数ツールから生成されたSBOMの情報集約が困難）
・ツールによる自動検出は検出の正確性が担保できない場合も考えられる。誤りがあった場合を考慮した、契約上の扱いなどの整理が必要

トレンドマイクロでは、当社法人向け製品をご利用中のお客様には、当社内の承認後に該当製品のSBOM提供を行う体制を整えています。ただし、現在の取り組みが上記の課題を全て解決できているとは考えていません。ソフトウェア提供企業の１社として、当社にとってもお客様にとってもSBOMがより意味のあるものとしていくため、当社では上記のような課題について引き続き検討し、より活用しやすいSBOMの在り方や活用手法について研究に取り組んでまいります。

次回は、「トレンドマイクロ製品の脆弱性に関する品質向上の取り組み」をご紹介します。

本シリーズの記事を読む：

第1回：製品開発の迅速性と安全性を両立するDevSecOps
第2回：サービスの信頼性を確保するSRE (Site Reliability Engineering)の実践
第3回：ソフトウェアの脆弱性のリスクを可視化するSBOM
第4回：トレンドマイクロ製品の脆弱性に関する品質向上の取り組み
第5回：地政学リスクを考慮したサービスの設計とは

サイバーセキュリティ・イノベーション研究所
トランスペアレンシー・センター

トレンドマイクロのサイバーセキュリティ・イノベーション研究所の中核センターの一つ。トレンドマイクロの製品・サービスの品質、安全性、透明性の向上に取り組む。また、その取り組みを顧客や一般に広く発信するほか、「ソフトウェア管理に向けたSBOMの導入に関する手引」を策定した経済産業省のタスクフォースにて、ソフトウェア分野のSBOM実証に協力するなど、国内におけるソフトウェアのセキュリティ向上に向けた社外活動も推進している。