トレンドマイクロのSBOM導入の取り組みを解説

SBOM導入のポイント

SBOM（Software Bill of Materials）とは、ソフトウェアに使用されている部品をとりまとめた構成表のことで、ソフトウェアを構築する際のコンポーネントの詳細とそれぞれの依存関係などを記した正式な記録です。
主にソフトウェアの脆弱性の管理やソフトウェアをとりまくサプライチェーンのリスクマネジメントに使用されます。
トレンドマイクロでは、すでにSBOMを構築、運用しており、業務上必要な場合には当社製品のSBOM情報をお客様に提供するなどの対応を行っています^※。SBOM導入のポイントは、下記の4つです。
※すべての製品で提供しているわけではありません。

1.SBOMの適用範囲を明確化し、可視化する
2.SBOMツールに期待する要件を定義し、長期的なコストパフォーマンスを加味して選定する
3.ツールから出力されたSBOMを解析し、正確性を把握した上で運用判断を行う
4.脆弱性が見つかった場合を想定したSBOM運用検証を行い、効果を測定する

本記事では『SBOMの手引』の内容を引用しつつ、トレンドマイクロが過去に行ったSBOM導入を振り返る中で、上記のポイントについて詳しくお伝えします。

参考記事：
・ソフトウェア・サプライチェーンの脆弱性管理に求められるSBOMの必要性
・トレンドマイクロ製品の安全性・透明性向上のための5つの取り組み　第3回～ソフトウェアの脆弱性のリスクを可視化するSBOM～

経済産業省が発行する手引の概要とポイント

昨今SBOM導入が求められる中、どのように進めていくべきか悩んでいる担当者の方は多いのではないでしょうか？
SBOM導入を検討する方へ向けて、経済産業省より『ソフトウェア管理に向けたSBOM（Software Bill of Materials）の導入に関する手引』（以下、『SBOMの手引』）が公開されています。
この手引きでは、SBOM導入の課題や解決策など、SBOM導入を進めるにあたって必要となる情報が端的にまとめられています。
『SBOMの手引』によると、目的と対象者は以下の通りです。

●手引の目的
本手引では、SBOMに関する基本的な情報を提供するとともに、企業の効率的・効果的なSBOM導入を支援するために、SBOM導入に向けた主な実施事項及び導入に際して認識しておくべきポイントを示す。

●手引の対象者
ソフトウェアサプライヤーにおける開発・設計部門や製品セキュリティ担当部門（PSIRT等）などのソフトウェアセキュリティに関わる部門と、経営層（特にSBOM初級者^※を対象）
※経済産業省の資料では、SBOM初級者は「ソフトウェアにおける脆弱性管理に課題を抱えている組織」、「SBOMという用語は聞いたことがあるが具体的な内容やメリットは把握できていない組織」、「SBOMの必要性は理解しているが、導入に向けた取組内容が認識できていない組織」など、と定義されています。

SBOM導入の３つのフェーズ

『SBOMの手引』では、以下の画像の通り、時系列に沿って導入プロセスを３つのフェーズに分けています。ステップを１つずつ進めていくことができるので、このフェーズを１から見ていくことで、ステップバイステップで導入に着手できるでしょう。

出典：「ソフトウェア管理に向けたSBOMの導入に関する手引」概要資料（経済産業省）

なお、上記の作業にかかる所用期間ですが、フェーズの1～2の部分についてトレンドマイクロが検証した際にかかった所用期間は約7か月間でした。なお、図のピンク色部分がフェーズ1、緑色部分がフェーズ2となります。

以降の章では、過去にトレンドマイクロが行った実証検証の内容を、さらに具体的に紹介します。

トレンドマイクロのSBOM導入　実践編

ある１つの製品（以下、製品A）に対してSBOM導入を検証しました。この章では、『SBOMの手引』のフェーズを引用しながら、トレンドマイクロが実際に行った検証を比較・評価していきたいと思います。

フェーズ１：環境構築・体制整備フェーズの実践！

フェーズ１では、下図で示す通り、1-1（青色）と1-2（黄緑色）のステップに関して検証した内容を紹介します。

なお当検証は『SBOMの手引』のフェーズに沿って行われたわけではなく、トレンドマイクロが過去に独自でSBOM導入したプロセスを振り返って記載しているため、すべてのステップを網羅しているわけではない点はご了承ください。

出典：「ソフトウェア管理に向けたSBOMの導入に関する手引」概要資料（経済産業省）

1-1.SBOM適用範囲の明確化

ここでは、対象のソフトウェアの開発言語、コンポーネント形態などソフトウェアに関する情報を明確化し、構成図を作成します。整理した情報に基づきSBOMの適用範囲を明確化します。
トレンドマイクロでは、以下のような観点から情報を整理しました。

●開発言語
→例：C、C++、Objective-C、Go、C＃、PHP、Java、JavaScript、Pythonなど

●部品形態
→例：OS、OSライブラリ、Webアプリケーションフレームワーク、データベースなど

●開発環境ツール
→例：Visual Studioシリーズ、Eclipse、Android Studioなど

●ビルドツール
→例：Jenkins、Circle CI、Gitlab、Bambooなど

●構成管理ツール
→例：Github（Github.com、GithubEE）、Gitlab、Team Foundation Serverなど

そのうえで、SBOMの対象範囲を可視化するために、以下のような構成図を作成しました。本検証においては対象範囲を製品Aの開発チームだけが単独で関わっている要素のみに絞り、挙動監視エンジンなど他製品でも共通で使われているものについては対象外としました。

1-2.SBOM初期導入・ツール選定

SBOMの対象範囲が整理できた後は、SBOMツールの選定に移ります。
ツールの選定に関しては、機能・性能・データ形式・コスト等、様々な観点を整理したうえで、複数のSBOMツールを比較評価し、選定する必要があります。
選定の観点が漏れていた場合、SBOM作成および運用・管理において想定外の工数が発生する可能性もあり、そのため選定観点の整理はとても重要なステップであると考えています。

無償のツールを利用することで初期導入のコストを大幅に抑えることが可能です。一方で、無償のツールは手動を伴う作業の割合が高くなるため、運用工数を加味すると高コストとなる可能性もあります。その為ツールの選定に際しては複数の角度から長期的な目線で検討する必要があると考えます。

なお、ツールの選定にあたっては、『SBOMの手引』の「7.3.参考情報」内の「7.3.2.SBOMに関するツール」節において、ツールの一例が紹介されています。挙げられているツールはあくまで一例のため、必ずしもここから選定する必要はありませんが、ツール選定の観点の勘所を得るために参照することをおすすめします。

出典：ソフトウェア管理に向けたSBOMの導入に関する手引Ver1.0（経済産業省）

SBOMツールの選定を行う前にトレンドマイクロの社内環境を確認したところ、すでに導入済のソフトウェア構成分析（SCA：Software Composition Analysis）ツールでSBOM生成の機能を有していることがわかりました。
※補足：SCAツールは、SBOM作成などの機能を含むソフトウェア解析ツールです。SBOMの作成、共有、活用、管理の機能に加えて、ソフトウェアライセンスの管理やコードのバージョン管理などを行えます。

そこで、社内導入済のSCAツール（以下SCAツール）にて、「作成したいSBOMの期待値を満たせるか？」という観点で検討を行いました。
その際、以下のような項目を考慮して検討を行いました。

●開発言語のサポート範囲
→現存のすべての開発プロジェクトで使用されている開発言語をサポートしているか？

●SBOMのフォーマット（SPDX/CycloneDX等）

●OSSの検出精度
→OSSは十分に検出可能か？
※Apache Log4jで発見された脆弱性「Log4Shell」（CVE-2021-44228）のように、メジャーなOSSが起点となる脆弱性が近年多く発見されていることから。

●脆弱性検出能力
→脆弱性は十分に検出可能か？

●開発ツールとの連携
→自社で使用している開発ツール（ビルドツール等）との連携が可能かどうか？

●システム形態
→オンプレミス版製品か？SaaS版か？

●コスト
→有償版か？無償版か？

OSSの検出率や脆弱性の検出能力については、ベンダの参考数値も参照しつつ、実際に自社ソフトウェアにおいてSCAツールを使用した実測値も重視しました。
検証の結果、SCAツールによって生成されたSBOMは、SBOM作成の期待値を満たしていました。そのため、改めてSBOM作成専用のツールを選定することは行いませんでした。全ての開発環境でSCAツールが導入されているとは限りませんが、ソースコードのバージョン管理ツールを導入済みの場合は、以下の検証で行ったことと同様のことが実現できる可能性があります。お手元の開発環境を確認されることをお勧めします。

SCAツールで不足していた点について
SCAツールでは生成したSBOMファイルの保存は可能でしたが、内容の検索や詳細な管理を行う機能はありませんでした。
また、製品パッケージングツールの情報やビルド番号の情報など、ツール上で管理できない情報についても何らかの形で別途管理する必要が生じてきました。
そのため、トレンドマイクロでは別途社内でSBOM管理システムを開発し、利用しています。
既存のSCAツールを再利用することで新規の導入コストを削減することができた一方で、機能の不足を補完するためにこのSBOM管理システムの開発工数が追加で必要となりましたが、トータルコストを考慮した結果、運用でカバーする方針を選択しました。
なお、社内で開発されたSBOM管理システムについては、下記のような機能が含まれるものを開発しました。

●製品情報登録・管理
→SBOMを提供する製品・バージョン情報の登録および管理を行う。以下の情報からなる。

●SBOM管理
→製品のリリースパッケージと対応して作成されたSBOMを保管する。

●SBOM検索
→各種情報から該当するSBOMファイルを検索する。

●API連携機能
→SBOMの登録等を自動化するためのAPIを提供する。

フェーズ２：SBOM作成・共有フェーズの実践！

フェーズ１でSBOMツールを選定した後、フェーズ２では実際にSBOMを作成するフェーズに移ります。
コンポーネントの解析結果を確認すると、誤検出や検出漏れなどが含まれる可能性があるため、検出精度の確認はとても重要だと考えられます。
フェーズ２では、下図で示す通り、2-1（青色）と2-3（黄緑色）のステップに関して検証した内容を紹介します。

出典：「ソフトウェア管理に向けたSBOMの導入に関する手引」概要資料（経済産業省）より

2-1.コンポーネントの解析

SCAツールを用いたSBOMの生成は、コンソールのUIから簡単に実施ができることがわかりました。生成されたSBOMのコンポーネントについて、以下のような観点から解析を行いました。

●米大統領令の最小要素がすべて含まれているか？

●OSSのライセンス情報は確認できるか？
→SCAツール上およびSBOM上で同じライセンス情報が記載されることを確認。

●後述するOSSの過検知率はどの程度か？

●トップレベルコンポーネントは適切に検出されているか？

●サブコンポーネントは適切に検出されているか？
→OSSのdepth（深さ）情報の正確性を推測するための情報として利用。
→調査ターゲットとするOSSを定めて、検出有無を調査。
→一方で、OSS自動検出による過検知ならびに検出漏れ※も存在していた。

●バージョン情報は適切に検出されているか？
→脆弱性管理においては、使用されているコンポーネントだけではなくバージョン情報も重要であるため。
※検出漏れ：実際に使用しているコンポーネントを検知できなかった状態のこと。

困難だった点①正確性を担保するための負荷が高い

なお、「適切に検出されているか？」の評価にあたっては、正確性の検証のため、手動でコンポーネントを比較する必要がありました。

SBOMの生成そのものの工数は非常に少ないものとなりましたが、手動との比較、特にサブレベルコンポーネントの正確性を担保する際のコストは非常に大きくなることが判明しました。

所要時間の目安ですが、トレンドマイクロでサンプルとして選択したコンポーネントに関する情報の正確性の確認にかかった時間と、実際の対象製品に使用されているコンポーネント数から、約170時間はかかると推定しました。

困難だった点②未検出・誤検出のコンポーネントの対応解析の結果、すべてのコンポーネントが100%正確に検出されることは難しいことがわかりました。

具体的には、バージョン情報が誤っているOSSや、階層の深いサブコンポーネントの検出漏れなどが見られました。これらについては、SCAツール上でコンポーネントの手動追加やバージョン情報の修正をすることで対応しました。

SCAツールで作成されたSBOMについて、実測値をもとに正確性のデータを計測しました。

その結果、以下のようなデータが得られました。

・自動検出におけるOSSの過検知^※率：約30%
・バージョン情報の正答率^※：約87%
・トップレベルコンポ―ネントの補足率：約88

※補足：それぞれの定義は以下の通りです。
過検知率：実際には利用していないコンポーネントを検出していないか
正答率：該当のコンポーネントバージョンが実際のものと合致しているか
補足率：出力されたサブコンポーネントが３つのサンプルのサブコンポーネントとどの程度合致していたか

なお、サブレベルコンポーネントについては数が膨大であり、手動であってもすべてのコンポーネントをリストにすることが困難でした。

そのため今回の検証においては、トップレベルコンポーネント３つをサンプルとして選定し、この３つに含まれるサブレベルコンポーネントの捕捉率を調査しました。

調査前は、サブレベルコンポーネントの階層が深くなるにつれて捕捉率が段階的に下がると推測していましたが、実際は「2階層でみられなかったものが3階層で見られる」など階層関係なく補足されるなどばらつきがあることがわかりました。

2-2.SBOMの共有

上記で述べたように、100%正確にコンポーネントを検出することは難しいのが現状です。
しかし、生成されたSBOM正確性の担保には非常に時間がかかるため、すべてのSBOMに対して手動比較を行うことは現実的ではありません。

正確性の度合いと、開発コストおよびリリース時間の増加はトレードオフになります。例えば、脆弱性を含む重大な問題の修正リリースを計画する場合に、そのパッケージに対応する「正確なSBOM」が準備できるまでリリースを遅らせるべきか否か、という議論も起こりうると想定されます。

SBOMの活用目的の一つである「ユーザによる脆弱性への速やかな対処」を目標とした場合に、何を優先させるべきなのか？についてこのフェーズで一度議論しておくこともおすすめします。

さて、SBOMの共有にあたって、トレンドマイクロでは以下のような観点を考慮しながら、SBOM共有のプロセスを進めました。

●提供形態
→SPDX形式のファイルを直接送付

●提供条件
→SBOMファイル自体は一般公開せず、問い合わせに応じて提供

●SBOM提供有償化の有無
→原則、製品readmeや技術情報の提供と同様、当社製品顧客や見込み客に無償で提供

●契約条項の修正（SBOM記載の内容に誤りがある場合の免責や対応）
→SBOMの記載に誤りがあった場合の修正プロセス

フェーズ３：SBOM運用・管理フェーズの実践！

SBOMを作成した後も、SBOM自体を適切に管理する必要があります。
フェーズ３では、下図で示す通り、3-1（青色）のステップに関して検証した内容を紹介します。

なお、SBOM活用・管理においては、以下２つのパターンが想定されます。

1.ソフトウェアベンダとしての自社製品のSBOM管理、運用の主体となる場合
2.ベンダから提供されたSBOM管理運用の主体となる場合

トレンドマイクロはソフトウェアベンダの立場としてSBOM運用を行うため、ここでは１つめのパターンとして検証した内容を紹介します。

出典：「ソフトウェア管理に向けたSBOMの導入に関する手引」概要資料（経済産業省）

3-1.SBOMに基づく脆弱性管理、ライセンス管理等の実施

ベンダとしての活用においては、あるCVEをもとにしてPSIRTチーム起点で脆弱性対応を行う場合を想定して検証しました。

新たに脆弱性が確認された状況を念頭に置き、過去3年の間に実際に報告された脆弱性3件を例として、自社ソフトウェアにおける脆弱性の影響度を調査したときの工数をシミュレーションしました。

具体的には、以下の３つのケースを想定してシミュレーションしました。

●手法①SBOMによる脆弱性調査
●手法②SCAツールのコンソールによる脆弱性調査
●手法③手動による脆弱性調査

①SBOMを活用した場合、および②SCAツールのコンソールから実施した場合、を比較したところ、②の手法の方が、作業工数が少なくなりました。SCAツールではコンポーネント情報だけでなく、CVE IDでの検索機能が存在しているため、CVE IDから影響のあるOSSについて調査する時間の分だけ工数が短縮されたためです。

③手動での調査の結果と比較した場合には、大幅に時間が短縮されていました。平均作業時間において、①および②の手法は手動調査の25.8%～51.6%の時間で対応を終えることができました。
手動調査においては社内で以前使用していたOSS管理システムとCVEの詳細情報において名寄せされていないコンポーネントがあったことが、時間がかかった主な原因でした。

複数製品に対して、コンポーネントの製品使用について調査したところ、SCAツールコンソールの利用では、製品数の増加によらず、同程度の時間で結果が出力された一方、自社開発のSBOM管理システムでは製品数により比例的に検索時間が増加する傾向がありました。また手動調査の場合も、製品数に比例して合計調査時間が増加しました。

SBOM導入を検討している方へ

ソフトウェア・サプライチェーンが複雑化し、オープンソースソフトウェア（OSS）の利用が一般化する中で、ソフトウェアにおける脆弱性管理やライセンス管理の重要性はますます高まっています。SBOM導入に際して難しさを感じる方も多いかと思いますが、効率的なソフトウェア管理を実施するためにとても効果的であることがわかります。

トレンドマイクロにおいては、SBOM脆弱性対応という観点を踏まえると、その業務コストの大きさや影響を踏まえると専門のPSIRTまたはそれに類するチーム主導で管理を行うのが望ましいと考えられます。
しかしながら、会社の規模や状況によってはPSIRTが存在していない場合も考えられます。その場合でも、脆弱性の対応は一定のポリシーの下に行われることが期待されます。代わりにSBOM運用の主体となりえるチームの一つは、品質管理チーム（会社横断で品質管理を担う部署を想定）が相当すると考えます。会社横断での品質管理チームがいない場合には、まずは特定の製品チームでSBOMないしはOSS管理ツールを導入し、運用・活用のノウハウを蓄積するところから始めるのがよいと考えます。その後、経験をベストプラクティスとしてまとめて横展開し、チームごとに様々な立場の方が本稿をお読みになっていると推測しますが、どのような立場の方であれ『SBOMの手引』の内容はきっと参考になることと思います。
『SBOMの手引』では、簡潔に内容をまとめた概要資料（PDF形式）、付録チェックリスト（Excel形式）も用意されています。