連載「技術者が知るべきSBOM活用法」 第6回
阪間 基秀
前回は、改訂のポイントについて記載しました。今回は、脆弱性管理プロセスの具体化について記載していきます。
SBOMを用いた脆弱性管理プロセスは以下の４つのステップから構成されます
(1)脆弱性の特定
(2)脆弱性対応優先度付け
(3)情報共有
(4)脆弱性対応
SBOMを活用した脆弱性管理の中でも、「脆弱性の特定」は実務上の中核となるプロセスです。本工程では、SBOMと脆弱性情報を突き合わせることで、自社ソフトウェアに影響するリスクを明らかにします。具体的には、以下の4つのフェーズに分けて進めることができます。
(1)マッチング手法区分の選択
(2)利用可能なSBOMデータの特定
(3)脆弱性データベースの選択
(4)マッチング手法の選択・作成
まず検討すべきは、どのような方法でSBOMと脆弱性情報を照合するかという点です。選択肢としては、手動検索、スクリプトによる自動化、専用ツールの活用が挙げられます。
手動検索は柔軟性が高いものの、自動化が難しく人的リソースに依存します。そのため、検索品質を担保するための手順整備や担当者教育が不可欠であり、結果としてコストが増大する傾向があります。
一方、スクリプトによる方法は情報源の多角化が図れるという利点がありますが、開発や検証に専門知識が必要であり、これも一定のコストを伴います。
これに対してツールの利用は、導入コストこそ発生するものの、継続的な実行やスケジューリング、自動通知などの機能により運用効率を大きく高めることが可能です。
特に、脆弱性情報の更新に応じた通知機能は、低コストでの継続的なリスク管理を実現する有効な手段と言えます。
次に、どのSBOMデータを利用できるかを整理する必要があります。OSSや市販のサードパーティ製ソフトウェアでは、提供されるSBOM形式があらかじめ決まっている場合が多く、契約によってフォーマットを指定することは難しいケースがあります。このため、事前に利用可能な形式や内容を確認しておくことが重要です。
また、開発を外部委託している場合には、従来の納品物にSBOMを含めることが求められます。SBOMの記述範囲には明確な統一ルールはありませんが、少なくとも最上位のSBOM（製品レベル）を作成し、使用しているOSSやサードパーティソフトウェアを網羅的に記載することが基本となります。
脆弱性特定の精度は、参照するデータベースの質と範囲に大きく依存します。そのため、リスク低減とコスト効率の観点から適切なデータベースを選択することが重要です。
具体的には、脆弱性情報のカバレッジの広さ、情報更新の迅速性、運用コストなどを比較し、自社の目的に合致したものを選定することが求められます。
最後に、SBOMの形式や選択した脆弱性データベース、運用上の制約条件を踏まえ、最適なマッチング手法を選択または設計します。
特に人手が関与するプロセスを採用する場合は、担当者ごとのばらつきやヒューマンエラーを防ぐことが重要です。
そのため、作業手順の標準化、チェック体制の構築、マニュアル整備などを徹底し、一定水準の品質を維持する仕組みを構築する必要があります。
SBOMを活用した脆弱性管理において、「どの脆弱性から対応すべきか」を判断する優先度付けは、限られたリソースで最大のリスク低減効果を得るための重要なプロセスです。
本工程は、次の4つのステップから構成されます。
(1)脆弱性フィルタリングによる絞り込み
(2)優先度付き情報の選択・取得
(3)優先付け判断ツリーに基づくカテゴリー判定
(4)優先度スコア評価
まず取り組むべきは、対応対象となる脆弱性の絞り込みです。特に、サプライヤーから既に対策済みの情報（パッチ適用済みや影響なしと判定されたもの）が提供されている場合は、それらを適切に反映し、対応対象から除外します。
この段階での精度が低いと、不要な対応工数が増加するため、信頼できる情報連携の仕組みを整備することが重要です。
次に、優先度判断に必要な情報を収集します。ここで重要となる視点は「費用対効果」です。すなわち、その脆弱性に対応することによって、どれだけリスクを低減できるかを評価するための情報を収集・活用します。
この考え方により、単に深刻度が高い脆弱性だけでなく、実際の影響範囲や悪用可能性を踏まえた現実的な優先付けが可能となります。
優先付けの判断には、国際的に標準化されたフレームワークの活用が有効です。代表的な例として、SSVC（Stakeholder-Specific Vulnerability Categorization）が挙げられます。
SSVCでは、以下の観点をもとに条件分岐を行い、判断ツリーを構成します。
これにより、脆弱性を以下の4つのカテゴリーに分類します。
また、この判断基準はセキュリティポリシーや組織の特性に応じて調整可能であり、「組織の役割（開発組織／ユーザー組織）」と「技術力（高い／高くない）」といった観点で分類し、それぞれに適した判断基準を設けることが推奨されます。
ただし、このプロセスには一定の専門性が求められるため、判断基準や前提条件、根拠を明確にドキュメント化し、定期的に見直す仕組みを整備することが重要です。
最後に、カテゴリー判定と並行して、定量的なスコアリングによる優先度評価を行います。これにより、判断の客観性と再現性を高めることができます。
基礎となる指標はCVSS（Common Vulnerability Scoring System）ですが、これだけでは実際のリスクを十分に表現できない場合もあります。そのため、以下のような補完的指標の活用が有効です。
KEV（Known Exploited Vulnerabilities Catalog）：実際に悪用されている脆弱性の一覧
EPSS（Exploit Prediction Scoring System）：将来的な悪用可能性の予測スコア
これらを組み合わせることで、「理論上の深刻度」と「現実の攻撃リスク」の両面から、より実効性の高い優先度付けが可能となります。
SBOMを活用した脆弱性管理において、その効果を最大化するためには「適切な情報共有」が不可欠です。単にSBOMを作成するだけでは不十分であり、脆弱性情報や関連する付加情報とともに、適切な相手に、適切な方法で共有する仕組みを構築する必要があります。
この点においては、CISAが提唱する「SBOM共有ライフサイクル」をベースに、脆弱性情報や運用情報まで拡張し、より実務的な観点で整理することが有効です。
具体的には、「共有情報」「共有相手」「共有方法」「共有の実施」という4つの観点から検討します。
(1)共有情報 ― 誰に何を伝えるべきかを明確にする
まず重要となるのは、どの情報を共有対象とするかの整理です。SBOMそのものに加え、脆弱性情報やその影響範囲、対応状況などの付加情報が対象となります。
この整理においては、「ソフトウェア開発者」と「ソフトウェア利用者」という異なる立場を意識することが重要です。それぞれが必要とする情報は異なるため、視点ごとに共有すべき情報を抽出し、体系的にまとめる必要があります。
(2)共有相手 ― 社内外のステークホルダーを整理する
次に、誰に情報を共有するかを明確にします。社内においては、開発部門だけでなく、PSIRTや品質保証部門などの管理部門も重要な共有先となります。
さらに社外に目を向けると、ユーザー、ベンダー、サプライヤーなど、多様なステークホルダーが存在します。これらの関係者ごとに、必要な情報と共有範囲を適切に切り分けることが求められます。
(3)共有方法の特定 ― 運用に適した手段を選択する
情報共有の手段についても、実務上の重要な検討ポイントです。代表的な方法としては、以下が挙げられます。
それぞれにメリット・デメリットがあり、組織規模や運用体制、セキュリティ要件に応じて最適な方法を選択する必要があります。
(4)共有の実施 ― ルールと合意に基づく運用
最後に、実際の共有運用をどのように実施するかを定義します。ここでは、単に情報を渡すだけでなく、アクセス権限や取り扱いルールを関係者間で合意した上で運用することが重要です。
こうした合意に基づき、SBOM、脆弱性情報、付加情報を適切に共有することで、サプライチェーン全体でのリスク管理が可能となります。
SBOMを活用した脆弱性管理プロセスの最終段階にあたるのが「脆弱性対応」です。この工程では、特定・優先付けされた脆弱性に対して、実際にどのような対策を講じるかを決定・実行します。
脆弱性対応は、その性質に応じて大きく2つに分類されます。すなわち、「根本対応」と「暫定対応」です。
それぞれの特性を理解し、状況に応じて適切に使い分けることが重要となります。
暫定対応は、脆弱性の根本的な修正が完了するまでの間に、リスクを低減するための応急処置的な対応です。攻撃の可能性が高く、迅速な対応が求められる場合に特に重要となります。
具体的には、アクセス制限、設定変更、機能制限などの回避策を検討・適用し、被害の発生を防ぎます。また、これらの暫定対応策については、自社内だけでなく、ユーザー組織やサプライチェーン上の関係者（供給先）にも速やかに周知することが求められます。
この段階では「スピード」が最も重要な要素となり、完全な解決ではなくても、実効性のあるリスク低減策を迅速に展開することがポイントです。
一方、根本対応は、脆弱性そのものを解消するための恒久的な対策です。自社開発のソフトウェアであれば、コード修正やパッチの適用を行い、脆弱性を取り除きます。
また、サードパーティ製コンポーネントに起因する脆弱性である場合は、サプライヤーに対して修正依頼を行い、適切なアップデートを入手・適用する必要があります。
さらに、脆弱性の修正に伴ってSBOMの内容も変化するため、更新されたSBOMを作成し、関係者へ共有することが不可欠です。これにより、サプライチェーン全体での整合性と透明性を維持することができます。
暫定対応と根本対応のバランスが鍵
実務においては、暫定対応と根本対応を適切に組み合わせることが重要です。緊急性の高い脆弱性には即時の暫定対応でリスクを抑えつつ、並行して根本対応を進めるという二段構えのアプローチが求められます。
SBOM対応モデルの策定とSBOM取引モデルの提示については、次回のコラムで記載する予定です。
組み込み／制御ビジネスユニットインダストリー事業本部
インダストリービジネス事業部
データエンジニアリング部第３技術グループ
主任
2006年、富士ソフト入社。モバイル機器の開発、ゲーム機向けのSDK開発を行う。その後、メーカーの研究開発の現場に携わり、主に低遅延伝送技術をテーマに、ルーターのNAT特性解析を自動で行うシステムの開発を経験。
研究開発の成果をPoCや、製品に移行する際、SBOMの生成が必要になり、開発の現場にて、SBOMを手動で作成し、SBOMの必要性を学ぶ。現在は、SBOM管理エンジニアとして、若手の教育とSCAツールの導入支援を中心に活動している。
保有資格：情報処理安全確保支援士
「探している組み込み製品」も「相談したい組み込み開発」も、まずはこちらから。
“こんな製品はないか”、“見積もりがほしい”、“この技術は対応できるか”、“詳しい実績が知りたい”——質問だけでも結構です。
お急ぎの場合も迅速に対応します。
