経産省のSBOM導入手引き第2版の内容と現実的な対応

本記事は2024年11月14日にZDNet Japan（https://japan.zdnet.com/article/35225803/）にて掲載されたものです。

2024年8月29日に、経済産業省より「ソフトウェア部品表」（Software Bill of Materials、以下SBOM）導入のポイントをまとめた「ソフトウェア管理に向けたSBOMの導入に関する手引ver 2.0」が正式に公表されました。Ver 1.0が2023年7月に公開されており、SBOMに関する基本的な情報や誤解と事実、企業のSBOM導入を支援するために、SBOM導入に向けた主な実施事項および認識しておくべきポイントが示されています。

今回公開されたVer 2.0では、上記に加え、ソフトウェアの脆弱（ぜいじゃく）性を管理する一連プロセスにおいて、SBOMを効果的に活用するための具体的な手順と考え方、SBOM導入の効果およびコストを勘案してSBOMを導入することが妥当な範囲を検討するためのフレームワーク、ソフトウェアの受発注において、調達者と供給者の間でSBOMに関して契約に規定すべき事項（要求事項、責任、コスト負担、権利など）についての参考例などが示されています。SBOMの基本的な知識のみならず、SBOM対応の課題や具体例など、“応用編”ともいえるものになっています。

今回は、Ver 1.0から引き続き掲載されている1～6章の概要を簡単におさらいしつつ、Ver 2.0で追加されたポイントや現実的な対応について解説します。

1～2章：背景と目的／SBOMの概要

1章と2章では、オープンソースソフトウェア（OSS）の利用が一般化する中で、ソフトウェアにおける脆弱性管理やライセンス管理の重要性が非常に高まっていること、ソフトウェアサプライチェーンが複雑化する中でソフトウェア管理の課題としてSBOM活用に注目が集まっていることを挙げ、その概要について詳しく紹介しています。

また、SBOM導入のメリットとして、脆弱性対応期間の短縮や管理にかかるコストの低減などの「脆弱性管理のメリット」「ライセンス管理のメリット」「開発生産性向上のメリット」を挙げており、特に脆弱性が発覚してから対応完了までの時間を大きく短縮できる点が最も大きなメリットであることが挙げられています。

なお、SBOMの「最小要素」に関しても解説しており、データフィールドのカテゴリーでは、SBOMの対象となるコンポーネントを一意に特定するための情報を含めることが「最小要素」として位置付けられています。

3～6章：SBOMの導入プロセス

3章以降では、SBOMの導入プロセスの全体像を3つのフェーズ（環境構築・体制整備フェーズ、SBOM作成・共有フェーズ、SBOM運用・管理フェーズ）に分け、各フェーズの解説や実施事項・認識しておくべきポイントを紹介しています。

SBOM導入プロセス（出典：経済産業省資料、以下同）

環境構築・体制整備フェーズでは、対象ソフトウェアの開発言語や環境などに関する情報の整理や、対象ソフトウェアの利用者およびサプライヤーとの契約形態・取引慣行の整理を求めています。

また、ツール選定の観点も紹介しているため、今後ツールの選定をする場合は、改めて内容を確認した方が良いでしょう。有償・無償、領域別の得意・不得意など、それぞれに特徴があるため、組織の実態に応じたツール選定が必要です。選定が難しい場合には、複数のSBOMツールを扱う販売代理店などに相談し、各ツールの特徴や長所・短所を比較しながら選定することも重要になります。

SBOM作成・共有フェーズでは、SBOMツールの出力結果をそのまま用いるのではなく、誤検出や検出漏れに関して出力結果を確認することの重要性、ソフトウェアサプライチェーンの透明性を高める観点から適切な対象者に対して適切な方法で SBOMを共有することを求めています。しかし現状では、他のツールで生成したSBOMをインポートして脆弱性管理などに活用することができるツールが限られているため、利用者および納入先との協議の際には注意が必要です。

SBOM運用・管理フェーズでは、SBOMがソフトウェア管理の一手法であるため、作成することが目的ではなく、SBOMを用いて適切なソフトウェア管理を行うことが重要であり、第三者から提供されたSBOMデータに対しても、同様の対応を実施することを求めています。

脆弱性管理に当たっては、SBOMツールの出力結果を踏まえ、ソフトウェアに含まれるコンポーネントの脆弱性有無を確認するとともに、脆弱性が確認された場合には、当該脆弱性への対応を行う必要があります。

手動でSBOMを管理する場合、脆弱性の有無を一つ一つ手作業で特定するほか、個別に脆弱性を評価し、対応方針を個々に検討する必要があり、膨大な工数がかかります。脆弱性情報は日々更新されるため、手動でのSBOM運用・管理は非現実的でしょう。そのため、SBOMツールを用いた管理を検討することが一般的です。

ただし、SBOMツールが出力した脆弱性情報の出力結果においても誤りが生じる可能性もあり、出力結果を確認することが必要です。また、ソフトウェアに含まれるコンポーネントのライセンスのコンプライアンスの状況やサポートなどライフサイクルの終了（EOL）の特定もできると良いでしょう。

SBOMの管理体制については、組織内のプロダクトサート（PSIRT）または、それに類する部門が主導して行うのが望ましいですが、全社横断で品質管理を担うチームが存在するようであれば、品質管理の一貫として、成果物としてのSBOMの定義や管理、SBOM活用による脆弱性の対応を行うことにより、一定のポリシーのもとでの運用が可能になると考えられます。

こうした部門が存在しない場合、まずは特定の製品開発チームでSBOMツールを導入し、SBOMの作成・運用・管理に至るノウハウを蓄積することから始め、その後に得られたノウハウを横展開して、チームごとでSBOM導入を進めると良いでしょう。

第7章以降：脆弱性管理プロセスの具体化

第7章以降は、Ver2.0で追加された項目です。SBOMをより効率的に活用できる方法が具体的に示されています。

SBOMを活用した脆弱性管理においては、1つのツールだけではカバーしきれないなど、さまざまな課題が存在しています。今回追加された第7章では、SBOMを活用した脆弱性管理の方法と手順について、プロセスに基づく具体例、運用のベストプラクティスが示されています。

SBOMを活用した脆弱性管理における課題として、下記のような課題が挙げられます。

• SBOMを受け取ったものの、部品IDの一意性がなく脆弱性データベースとのマッチングが難しい
• ツールで特定できない部品は手動で追加する必要があり、手間がかかる
• 実際にSBOMから脆弱性情報が検知された際に、対応の要否や優先順位付けをどのように行うのか。数千件の脆弱性が検知された場合に全て対応するのは現実的ではない

これらの課題に対して、脆弱性管理プロセスをフェーズ1～4に具体化して示されています。

SBOMを活用した脆弱性管理プロセス（概要）

フェーズ1：脆弱性特定

（1）SBOM既存ツール、（2）API利用スクリプト、（3）ウェブUI――3通りが示されています。

（1）のSBOM既存ツールのみで対応できることがベストですが、既存ツールのみでは対応できない領域も一部存在しているため、（2）自分たちでスクリプトを書き、APIでマッチングする、（3）ウェブブラウザーを駆使して人力でマッチングする、といった手法も紹介されているようです。しかし、（2）と（3）については非常に工数がかかるため、現実的ではありません。ツールによって領域の得意・不得意があるため、領域ごとに使い分けていくというのが現実解でしょう。

利用可能なSBOMツールを特定した後、SBOMフォーマット・部品IDを確認し、対象とする脆弱性データベースを選択します。その後マッチング手法を選択し、実施します。

フェーズ2：脆弱性対応の優先付け

まず脆弱性フィルタリングによる絞り込みで、対応する必要がないものは優先付けのステップを省略することができます。ベンダーから脆弱性の対応要否の情報を含む「Vulnerability Exploitability eXchange （VEX）情報」が提供されるようになれば、フィルタリングによりステップを省略することが可能です。

次に、優先付け情報の選択・取得を行います。一般的に「リスク＝脅威発生可能性（悪用可能性）×影響度×対応コスト」と考えます。

VEXの取得が難しい場合には、米国サイバーセキュリティ社会基盤安全保障庁（CISA）が提供する、悪用が確認された脆弱性情報のカタログ「Known Exploited Vulnerabilities Catalog」（KEVC）を活用することが想定されます。Forum of Incident Response and Security Teams（FIRST）が主導して策定された「Exploit Prediction Scoring System」（EPSS）を利用することも一つの方法です。

そして、優先付け判断ツリーに基づくカテゴリー判定を行い、優先度スコア評価を行います。初めから複雑な指標を作り、一律のルールで統制を効かせてしまうと、破綻してしまうこともあります。まずは、KEVCなどの既に攻撃実績がある脆弱性から確認するなど、少しずつリスク優先度の考え方を進化させていくことが現実的であると思います。

フェーズ3：情報共有フェーズ

情報共有フェーズのステップ

まず最終製品のメーカーは、最低限のPSIRT体制を構築し、脆弱性情報の公開や「Japan Vulnerability Notes」（JVN）、「National Vulunerability Database」（NVD）などの共有の脆弱性データベースに報告するプロセスを作っていただきたいと思います。その上で、サプライヤーはSBOMの共有プロセスの中で、最低限運用可能な脆弱性などのリスク情報をメーカーに伝えるようにしてほしいと思います。そのために、サプライヤーとメーカー間でSBOMや脆弱性情報などの共有方法についての取り決めが必要です。

フェーズ4：脆弱性対応フェーズ（暫定対応・根本対応）

脆弱性対応は、回避策などの暫定対応と、脆弱性の修正を行う根本対応があります。根本対応の場合には、脆弱性に関わるソフトウェアの開発者を特定し、開発者が脆弱性を修正します。その際、SBOMやVEX情報の更新と供給先への提供も必要です。

SBOM対応モデル（第8章付録）

SBOM対応モデル（第8章付録）

SBOMは、サプライチェーンの中で相互運用していくことが本来の目的ではありますが、実際にサプライチェーンの中で、会社をまたいで運用を行うのは非常に負荷がかかります。8章では、実証実験を通して見えた課題に対して、どのように解決していくかが示されています。

まずは、自社内でSBOMを活用し、脆弱性管理などに役立てるところから着手し、それらの土台を整えた上で、サプライチェーンの中での相互運用やプロトコルを決めていく必要があります。最初から全てしようとすると非常に大変なので、最初は「コスト小」など、やりやすい範囲から始めることが大切です。

自社内でのSBOM活用・運用が回っているところからがスタートであり、その準備ができていないまま相互運用に取り組んでもうまく運用することはできません。

SBOM取引モデル（第9章付録）

SBOM取引モデル（第9章付録）

SBOM対応モデルがある程度固まった後に、取引条件・契約条件に落とし込んでいく際に必要な事項が具体的に挙げられています。SBOMフォーマットや部品IDの標準、共有方法などの基礎レベルについては要求事項に確実に組み込み、契約書など具体的に書面に落とし込む必要があるでしょう。

今回公開されたVer 2.0は「応用編」といえるもので、最初から全てに対応する必要はありません。まずはできる範囲から、自社の実態に合わせて無理なく導入を進めることが重要です。