2021年5月に発令された米国大統領令14028号をきっかけにSBOM（Software Bill of Materials、エスボム、ソフトウェア部品表）が近年のサイバーセキュリティ業界におけるホットトピックの1つとなっています。これまでに経済産業省の「ソフトウェア管理に向けたSBOMの導入に関する手引（以下、導入の手引）」[i]や当社が翻訳した「ソフトウェア透明性」[ii]をはじめとするSBOMに関する文献が数多く公開されています。本記事では、それらの文献の補足としてSBOMの主なユースケースである脆弱性管理について深堀して解説します。
脆弱性管理とは
脆弱性（Vulnerability）とは、システムのハードウェアやソフトウェアの設計や実装のミス、設定の不備等により生じるセキュリティ上の弱点のうち、サイバー攻撃に悪用される可能性があるものを言います。本記事ではソフトウェアの脆弱性を対象とします。
脆弱性管理（Vulnerability Management）とは、ソフトウェアをつくる・つかう人や組織がソフトウェアの脆弱性を特定し、適切に対応するためのプロセスを言います。
脆弱性管理は、以下の2つに大別されます。ソフトウェアのリリース後にも新たな脆弱性が発生する可能性があるため、脆弱性管理はソフトウェア開発時だけでなく、ソフトウェアのライフサイクル全体、ソフトウェアの開発時から使用終了（EOL、End of Life）までを通じて継続的に行うことが求められます。
|
脆弱性管理 |
管理対象の脆弱性 |
主な取り組み |
|
|
1 |
ソフトウェア |
開発時点で |
SCA（脆弱性スキャン） |
|
2 |
ソフトウェア |
リリース後に |
脆弱性の監視・対応、SIRT |
SBOM（ソフトウェア部品表）とは
SBOMについては、概ね以下のように説明されています。
- ソフトウェアを構成するソフトウェア部品やその依存関係を整理したリスト
- ソフトウェアにおける食品成分表のようなもの
- ソフトウェアサプライチェーンのセキュリティを確保、向上するための手段
- ソフトウェアの透明性を確保、向上するための手段
もう少し具体的には、SBOMとは、「リリースしたソフトウェアの、使用するライブラリやパッケージ等のソフトウェア部品を記録した証明（Attestation）、可視化データ」であると言えます。そのため、SBOMはソフトウェアのリリース作業の中で生成し、ソフトウェアのリリース物とあわせて管理し、必要・求めに応じて共有することが求められます。
SBOMを活用した脆弱性管理とは
前述の通りSBOMはリリースしたソフトウェアが使用するソフトウェア部品に関するデータであることより、SBOMを活用した脆弱性管理とは、主にソフトウェアのリリース後に行う脆弱性管理を指します。
従来のソフトウェアのリリース後に行う脆弱性管理においては、リリースしたソフトウェアが使用するソフトウェア部品を記載したソフトウェア管理台帳をあらかじめ手作業で作成しておき、それに基づき脆弱性の監視・対応が行われていました。そのため、使用するソフトウェア部品の抜け漏れやソフトウェアの変更に台帳が追従できていないといった問題がありました。台帳をソフトウェアのソースコード等からツールを用いて機械的に生成するSBOMに置き換えることで前述の問題の解決が期待でき、「導入の手引」[i]で挙げられている脆弱性管理の期間短縮やコスト低減といったメリットにつながります。
本記事では、SBOMを活用した脆弱性管理のプロセスについて、2024年8月に公開された「導入の手引」[i]ver 2.0で追加された第7章「脆弱性管理プロセスの具体化」に沿って解説します。
SBOMを活用した脆弱性管理プロセスの全体図（「導入の手引」[i]より引用）
脆弱性特定フェーズの解説（「導入の手引」ver2.0の7.4.1）
製造業等の会社で用いられる部品表では部品を品番により識別しますが、SBOM（ソフトウェア部品表）ではソフトウェア部品をIDにより識別します。通常ソフトウェア部品のIDはSBOMを生成する人や組織が決めて付与するのではなく、ソースコード等に含まれるソフトウェア部品の名前やバージョン等の情報をもとにSBOMを生成するツールが付与します。
従来の脆弱性管理ではソフトウェア部品のIDとしてCPE（Common Platform Enumeration）[iii]が用いられておりましたが、2025年現在ではSBOMを活用した脆弱性管理ではpurl（package URL）[iv]が多く用いられています。現代のソフトウェア開発においてソフトウェア部品の管理を行うパッケージ管理システムごとに異なる命名規則に対応可能であることが、purlが用いられている主な理由です。
脆弱性特定フェーズ（脆弱性の監視）では、前述のソフトウェア部品のIDをもとにソフトウェアに該当する脆弱性を特定します。具体的には、NVD[v]やJVN[vi]をはじめとする脆弱性情報DB（データベース）が提供する脆弱性情報には対象のソフトウェア部品のIDが含まれており、それとリリースしたソフトウェアのSBOMに含まれるソフトウェア部品のIDを突合（マッチング）することにより特定を行います。今日においては脆弱性情報を収集すべき脆弱性情報DBが多数あり、ソフトウェアの開発言語によってはSBOMに含まれるソフトウェア部品の数が数十から数百になることも珍しくなく、手作業による突合が困難になってきているため、ツールを用いて突合を行うことが推奨されます。
脆弱性対応優先付けフェーズの解説（「導入の手引」ver2.0の7.4.2）
脆弱性特定フェーズで特定した脆弱性ですが、そのすべてがリリースしたソフトウェアの脆弱性であるとは限りません。脆弱性情報に含まれる脆弱性の内容や原因、該当するソフトウェア部品のバージョン等はあくまで脆弱性そのものの情報であって、該当するソフトウェア部品を使用するソフトウェアの仕様や実装、使用環境を考慮した上で攻撃に悪用される可能性があるか否かに基づきリリースしたソフトウェアの脆弱性か否かを判断する必要があります。例えば、ソフトウェア部品に含まれる関数の実装ミスに起因する脆弱性があったとして、ソフトウェア部品を使用するソフトウェアがその関数を実行しないならば、それはそのソフトウェアの脆弱性ではありません。
脆弱性か否かの判断には手間と時間、サイバーセキュリティに関する知見が必要であり、特定した脆弱性すべてに対して行うことは現実的ではないため、優先度づけを行って判断する対象の脆弱性の絞り込み（トリアージ）を行います。
従来の脆弱性管理ではCVSS（Common Vulnerability Scoring System）[vii]の基本値が7.0以上という指標により優先度づけが行われていましたが、今日においては報告されている脆弱性うち基本値が7.0以上の脆弱性は半数超となっており、その指標は有効であると言えなくなっています。
過去10年間のCVSSの基本値の分布（https://www.cvedetails.com/より引用）
本記事では、近年有効であると期待されている2つの優先度づけの手法を紹介します。
- 優先度づけ手法①：複数の指標を組み合せた優先度づけ
- 優先度づけ手法②：SSVCによる優先度づけ
優先度づけ手法①：複数の指標を組み合せた優先度づけ
脆弱性管理はセキュリティに関するリスクマネジメントの1つであり、脆弱性の優先度は脆弱性を悪用した攻撃のリスクの大きさに基づき判断できると考えられます。本手法では、攻撃により想定される被害の大きさ（脆弱性の深刻さ）をCVSSの基本値、攻撃が発生する可能性をEPSS（Exploit Prediction Scoring System）[viii]のスコアとしてリスクの大きさを求めます。さらに、悪用が確認された脆弱性（Known Exploited Vulnerabilities）[ix]のカタログや攻撃（PoC）コードの有無も考慮して優先度づけを行います。本手法の実装例としてCVE_Prioritizer[x]やSploitScan[xi]といったツールが公開されています。
優先度づけ手法②：SSVCによる優先度づけ
SSVC（Stakeholder-Specific Vulnerability Categorization）[xii]は2019年にカーネギーメロン大学が提唱した手法で、脆弱性がシステム（ソフトウェア）やビジネスに与える影響に基づき脆弱性管理に関わるステークホルダーごとの優先度づけを行います。
本記事の中では各手法の詳細まで解説しきれないため、興味があればIPAの中核人材育成プログラムにてまとめられた文献[xiii]や当社の別記事も参照ください。
CVSSに代わる脆弱性の評価手法「SSVC」とは｜迅速な脆弱性対応を目指して
情報共有フェーズの解説（「導入の手引」ver2.0の7.4.3）
前述の脆弱性特定、対応優先付けフェーズのプロセスは、一般にソフトウェアをつくる・つかう組織のPSIRT（Product Security Incident Response Team）や品質保証部門により行われます。特定した脆弱性がリリースしたソフトウェアの脆弱性か否かの判断や脆弱性と判断された場合の対応は、必要に応じて開発部門やソフトウェア部品のサプライヤーといったステークホルダーと協力して行う必要があります。脆弱性管理のプロセスや体制の構築・改善の中でステークホルダー間の協力依頼や、SBOMを含む情報の共有方法の取り決めを行うことが求められます。
脆弱性対応フェーズの解説（「導入の手引」ver2.0の7.4.4）
対応優先付けフェーズにおいて絞り込んだ脆弱性を対象に、リリースしたソフトウェアの脆弱性か否かの判断、ならびに脆弱性と判断された場合には対応を行います。
脆弱性か否かの判断は、SBOMや脆弱性情報をもとに脆弱性の対象や原因、攻撃方法の詳細を確認しつつ、リリースしたソフトウェアの仕様や実装、使用環境を考慮して判断します。
特定した脆弱性がリリースしたソフトウェアの脆弱性であると判断した場合、次に脆弱性を悪用した攻撃のリスクの評価を行います。攻撃により想定される被害の大きさと攻撃が発生する可能性を実際のソフトウェアの使用環境や生じる被害によるビジネスや人命等への影響に基づき評価します。脆弱性情報だけでなく、ソフトウェアの設計時に実施した脅威分析、リスクアセスメントの結果もふまえつつ評価することが推奨されます。
リスクの評価を通じて影響が大きく急ぎ対応が必要であると判断された場合、攻撃の発生や被害を抑えるための暫定対応をステークホルダーと協力して行います。その後、根本対応としてリスクの評価結果に応じたソフトウェアの修正やソフトウェア部品のバージョンアップ等の対策を行います。あわせて修正したソフトウェアのSBOMの生成、ステークホルダーへの脆弱性対応に関する情報提供も行います。
ソフトウェア（部品）をつくる側からつかう側への情報提供にあたっては、「導入の手引」[i]においてVEX（Vulnerability Exploitability eXchange）[xiv]の活用に言及されています。VEXは、つくる側の脆弱性の対応結果をもとに”影響なし”、”修正済み”といった対応ステータスをつかう側に伝えるためのもので、VEXを活用することでつかう側が特定した脆弱性の絞り込み（トリアージ）を行う際につくる側が判断した対応ステータスに基づき”影響なし”、”修正済み”の脆弱性を除外できます。現時点ではVEXを運用している例は多くなく、今後SBOMとあわせて普及が進むと思われます。
おわりに
駆け足での解説となりましたが、SBOMを活用した脆弱性管理は、従来から行われている脆弱性管理からの地続きの取り組みであり、SBOMやVEXを活用して効率化、精緻化を図ることが主旨であることが分かります。また、ソフトウェアのセキュア開発、構成管理やPSIRTの活動にも関わるため、導入にあたってはステークホルダーの協力が不可欠です。
当社では本記事で解説した脆弱性の特定（監視）、対応優先度づけを支援するSBOMに対応した脆弱性監視サービスを提供しております。それらの手段や運用を検討されている方、課題をお持ちの方は是非当社へご相談ください。
本記事で解説しきれなかったSBOMを活用した脆弱性管理の取り組みや課題の解決、EUサイバーレジリエンス法（CRA）等の法規・ガイドライン対応、PSIRTの構築といった支援についても可能ですので、お気軽にお問い合わせください。
＜関連サービス＞
[i] https://www.meti.go.jp/press/2024/08/20240829001/20240829001.html
[ii] https://www.shoeisha.co.jp/book/detail/9784798187969
[iii] https://www.ipa.go.jp/security/vuln/scap/cpe.html
[iv] https://github.com/package-url/purl-spec
[v] https://nvd.nist.gov/
[vi] https://jvn.jp/
[vii] https://www.ipa.go.jp/security/vuln/scap/cvss.html
[viii] https://www.first.org/epss/
[ix] https://www.cisa.gov/known-exploited-vulnerabilities-catalog
[x] https://github.com/TURROKS/CVE_Prioritizer
[xi] https://github.com/xaitax/SploitScan
[xii] https://github.com/CERTCC/SSVC
[xiii]https://www.ipa.go.jp/jinzai/ics/core_human_resource/final_project/2024/risk-assessment-methods.html
[xiv] https://www.cisa.gov/sites/default/files/2023-01/VEX_Use_Cases_Aprill2022.pdf
