SBOM運用のベストプラクティスとは？　経産省発行の資料で提案された、具体的な活用方法

SBOM運用のベストプラクティス

鈴木康弘氏：今回のメインのver 2.0の追加内容の解説に移っていきたいなと思います。

こちらも、概要資料になります。経産省が掲載してくれている概要資料になります。6章までがver 1.0で、7章以降がver 2.0なんですが、脆弱性管理プロセスの具体化を、さらになぜ追記しようと思ったのかが、目的・背景に書かれています。


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

実は、SBOMをしっかり活用していくことや、それを脆弱性管理に役立てていこうとした時に、現状では未解決の課題が（あった時に）なかなか1つのツールだけだとカバーしきれないなど、いろいろな問題が出てくるケースがあります。おそらく1年経って、そういった声も多く聞かれたんじゃないかなと思います。

新しいセクションとして、実際に運用していくとなった時のベストプラクティスをまとめて示していきたいということが追加背景になっていると書かれています。

具体的に、この脆弱性管理のプロセスをしっかり構築していく時に、さらにそのプロセスの中でフェーズが4段階に分かれて、それぞれにポイントがあります。この7章だけでかなりの文量が割かれています。ボリューミーなので、さっそくいきたいと思います。

まず、ドキュメントの中で書かれているところで言うと、具体的にいろいろな問題が脆弱性管理などにおいて起きると言われています。

例えば、SBOMファイルをもらって、ファイルだけある時は、実際にどうやって脆弱性データベースとマッチングと突合して、脆弱性情報を抽出するのか。フォーマットが今スライドに出てきましたけども、部品の識別子にどういったものを使うのかが書かれています。


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

ツールだけではなかなか特定できないので、手動で管理しなければいけない部分もあります。実際に、脆弱性情報が出てきた時に、どう優先順位付けをするのか。1,000件、2,000件の脆弱性が出た時に、それを全部チェックするのかという問題が現実に出てきます。

さらに、優先度が高い脆弱性があぶり出されました。その時に、サプライヤーから最終ベンダー、ユーザー企業までどう流通させるかが、さまざまなフェーズにおいて、いろいろな課題が具体的に出てきているのが現状かなと思います。

SBOMの問題解決、3つの方法

そのプロセスを、モデル化したのがこちらの図になっています。3つの方法があります。まず1つ目が、脆弱性情報を特定する方法です。要はSBOMファイルやSBOM情報がある時に、それと脆弱性情報をどう突合して、マッチングして脆弱性の検出リストを抽出できるかですね。


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

それでマッチングして最終的にはリストが出来上がるかたちになっています。また、このリストに脆弱性がたくさん出てきた場合、優先順位付けはどうするか。いくつかの方法が紹介されています。

対応すべき優先度の高いリストができた時に、それをどう共有していくのか、どう対応していくのかのポイントが書かれているのが、この7章です。

フェーズ1の脆弱性の特定についてはどうしていくのか。初めはver 1.0の適用範囲を明確にするとありましたが、適用範囲を明確にした時に、ツールだけで対応できればいいんですが、ツールだけだと対応しきれない領域もあったりします。


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



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

具体的にどうやっていくのか。ツールをそのまま利用して、そこだけで対応できるのが一番楽ではあるんですが、あぶれてしまっている時に、自分たちでスクリプトを書いて、APIを叩いてマッチングすると紹介されているのが2番目です。

3番目のWeb UIは、Webブラウザを自分で駆使して、人力でマッチングする手法が紹介されています。非常に「大丈夫かな？」というかたちになってきていますが（笑）、もともとは、機械的に全部やりたいので機械読み込み可能なものになっています。
 
出典元：経済産業省『ソフトウェア管理に向けたSBOMの導入に関する手引Ver2.0』

現実的に考えると機械側が追いついていないところがありますので、Web UIで人力でするみたいな方法も紹介されています。

APIを利用してスクリプトを自分で書いた時のメリット・デメリットも紹介されています。自分たちで脆弱性データベースのAPIを叩いて、スクリプトを書いて、SBOMから脆弱性情報をマッチングするプログラムのスクリプトを書きます。

そうすると、既存ツールではなかなかカバーできない複数のデータベースを跨いだものをカスタマイズして作ることができるメリットはあります。

ただ、自分たちで作り上げる技術力、工数、リソース、ノウハウもかなり必要な領域なので、そういった知識も含めて必要になってきます。もちろん、既存ツールを使ったケースで収まればいいんですが、既存ツールを使う場合は無償ツールもあれば有償ツールもあります。

有償ツールも、高いものからなんとかお買い求めできるレベル感の金額帯のものまで幅広くある状態なので、その中で取捨選択が必要になります。得意・不得意があるので、不得意領域は精度が落ちることもあります。

最後にWeb UIの利用です。実際にAPIを作る前のテスト的なところでも使えますし、Web UIで一時的にやってみるのはいいかもしれません。

ただ、デメリットのところにも書かれていますけども、定常業務の中で定期的にチェックしていくとなると、それも工数がかかって非効率になってしまうので、現実的にはどうなのかなというかたちですね。

現実的な解決方法としては3つ

こうして、現実としては3つの手法が紹介されています。1番目が既存ツール。2番目が自分たちでAPIを叩いてスクリプトを書きます。3番目がWeb UIを通して自力かつ人力でマッチングする方法です。

マッチングできる手法を見定めた後に、具体的にSBOMにどういったデータが入っているかをチェックしないといけません。

その時にSBOMを外部からもらうケースもあれば、ツールを通して自動作成されるケースもあったりします。外部からもらうパターンは、オープンソースのような、サードパーティソフトウェアから提供を受けられるパターンもあります。

または、委託開発契約している、要は開発をアウトソースしているSIerさまに出してもらわないといけないケースもあったりします。その時は、フォーマットや部品IDをどう合意を取るかが重要になってくると書かれています。やり取りするフォーマットを何にするのか、中で使われている部品IDを判別するかが大事です。


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


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

この方法で一般的なものがPURLですね。2つの方式があって、まずはケースパッケージマネージャーを中心としたリポジトリに応じてIDが決定する方式。

もう一つはCPEという方式です。NISTやNVDを管理しているNISTが管理している、主に脆弱性が割り当てられた製品に対して、製品を特定するキーが割り当てられます。この2つのケースが使われることが多いです。

部品IDとして何を使うのかが、しっかり話し合われて決定されていないといけません。ここからさらに複雑になってくるんですが、このドキュメントの中では、それらをクリアした後に、活用する脆弱性のデータベースを選別していく話になります。


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

ドキュメントの中には民間のデータベースが1から6まであります。公的なデータベースが1から2までです。それぞれでカバレッジの広さや脆弱性だけではなく、さらに優先順位付けするための情報が必要になります。

Exploitやインシデントがあったかなども含めて情報提供されているか。APIが公開されたり、部品IDがあって自動化できるか、日本語で提供されているか。そういったところが観点としてあります。

データベースに限らずツール選定の時にもこういったかたちで、脆弱性情報の観点を見ていただいてもいいと思っています。

検出手法を決める際のポイント

経産省が出している公式ドキュメントなので具体的な名称は書いていないんですね。何のことなのかがよくわからない書き方なので、参考にならないケースも多いかなとは思います。こういう観点から見ながら、使うデータベースを評価していこうと書かれている状態です。

最終的に使うデータベースや方法も決まった時にどういう手法を使うか。既存ツールでうまく脆弱性情報がマッチングできるのであれば、それでいいのかもしれません。しかし、そのツールの裏側にはデータベースの問題もあると思います。

もちろん、人力であれば全部のデータベースを広く見られますが、かなり工数がかかりますし、人力では不可能というケースもありますので、基本的にはAPIで自力で作っていくことになります。

ただ、APIがないデータベースもありますので、そこらへんは、考えながらやっていく必要があります。ここも具体的な名称は避けられている状態ですね。

手順としてはこういう手順です。例えば既存のツールを使い、自分たちでAPIを叩いて自作をしていくのかも含めて検出手法を決めなければいけません。要はカスタマイズしたり、しっかり考えて決めていかないといけないです。こういったことがこの脆弱性を特定するファーストセクションで説明されています。


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

どう優先順位付けしていくべきか

次に2番目の優先順位付けの部分になります。いろいろ書かれているんですが、まず1つ目が脆弱性のフィルタリングによる絞り込みです。まず見なくていいものは、横に置いておくとのことです。

具体的にはサプライヤーから「すでに脆弱性に対応済みだよ」みたいなことが書かれています。これはVEXという情報なんですが、要は対応ステータスみたいな、情報もSBOMに付加できるようなかたちになっています。



VEXがどういったものかという概念的な図です。SBOMと脆弱性データベースをマッチングすると、検出された脆弱性一覧が出てきます。この中で実際に影響がある脆弱性一覧を考えていく時に、このVEXという情報を加味してさらに絞り込むみたいなことができます。

具体的に、どういう情報か。脆弱性の情報もあれば、そこに対してステータスの情報が付加されているイメージですね。調査の結果、この脆弱性はAffectedであるとわかったり、影響はあるというステータスがついていたり、製品には影響しないというNot affectedがわかったりします。

（スライドを指して）Fixedはすでに修正されて、Under Investigationという調査中のステータスが表示されました。


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

こういうものがわかっていると、Not affectedは省けますし、Fixedも省けます。現在、Affectedの中で対応を考えればいいので、理論的にはこういった情報があると脆弱性情報が絞り込めます。

Affectedな脆弱性の中で、さらにどうやって絞り込んでいくのか。優先順位付けしていくのか。公式には、効果をコストで割ると書かれています。脆弱性リスクの低減効果をコストで割ります。脆弱性リスクの低減効果を分解すると、要は脅威発生可能性と影響度、コストに分解されるので、こちらの表がまとめられています。

難しく書かれている部分もあるので、簡単に言うと、リスクは、発生可能性や悪用可能性と影響度の掛け算ということですね。そういった概念で表現できると書かれています。対応コストや悪用された場合のコストに細かく書かれています。


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

影響度の指標としてよく使われるのが、CVSSのスコア、脆弱性のスコア、サービスの特性、資産の重要度です。発生可能性や悪用可能性で言うと、一番使われるのが悪用実績があるかです。

その脆弱性を突かれて悪用やExploitが証明されて、もう実績がある状態、Exploitコード、PoCコード等の攻撃コードが公開されている状態です。

加えて、さっきのVEXのステータスや評価情報も併せて活用していくと書かれているかたちですね。細かいところがいくつかありますけども、そんな概念で書かれています。こういったものを評価指標として何を使うのかを考えて、対応と優先度を考えていくと書かれています。

脅威情報のカタログが意味すること

補足の情報として、最近よく使われるこのKEVカタログをyamoryでもしっかり取り込んでいますが、これはアメリカのCISAという省庁が出している、悪用が確認された脆弱性のリストですね。

ここに載っているということは、インシデントがあり、悪用が実際あった脅威情報のカタログなんですね。

FIRSTという団体が出しているEPSSスコアもあります。時系列を加味して、攻撃が流行っているか、流行っていないかも加味をして、直近何日以内に攻撃される可能性の指標を出してくれます。

流行り廃りもある世界なので、こういったところも加味してもいいと書かれています。基本的な概念としては、スコアリングや優先順位付けの尺度、考え方の紹介がされています。

さらに、SSVCの紹介もされています。SSVCは悪用可能性や効率性、自動化された攻撃ができるかを決定木分析します。技術的な影響度やユーザー側の影響度を加味して、自動的に対応区分が決まる優先順位付けの方法になります。


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

赤のimmediateが即対応なので、すぐさま対応しなければいけません。悪用可能性が高くて自動化されやすくて、影響度も高くて、使われ方やユーザー影響度も非常に高い、全部高い場合は即時対応しなければいけない。そういった感じで振り分けられるかたちです。


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

即時対応もあれば、少し優先的に対応する。通常のメンテナンスタイミングで対応する。いったん保留する。対応しません。対応を注視する。4区分に自動的に割り当てられるのが、SSVCの考え方です。こういった手法論も紹介されています。

会社独自のスコアリング方式を、先ほどの区分からポイントを加算して、会社独自のポリシーを作って、独自のスコアリングを作って、評価していくことがいくつか紹介されているかたちですね。

なので、SSVCのようなモデルを使うケースも考えられますし、独自のスコアリングを考えることもあります。これらは普通に用いられているケースになりますので、参考になると思います。