SBOM取引における現実的な諸問題　経産省が推奨する取引モデルとは？

サプライチェーンの中で情報をどう共有すべきか

鈴木康弘氏：優先度が高く、対応しなければいけないものがわかった時に、サプライチェーンの中で情報を共有する時にそのポイントがまとまっているのが次になってきます。


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

実際、もうすでにSBOMの運用や要求が明確にある場合は、その明確な要求や共有に対する要求に基づいてしっかり共有していかなければなりません。また、これからその要件を作る場合は、こういった情報も観点として見ていくべきかなと思います。

共有すべき情報をまず特定することです。SBOMといっても、さっきのVEXみたいな情報もあるので、そこまで含めるかどうかも決めるべきです。あとは、共有する相手についても、どういう相手を対象にしていくのかも考えなければいけません。

上流のトリガー、サプライヤーの方々がプッシュ方式で下に伝えていくのか、共有のタイミングも決めていきましょう。どうファイルを共有していくのかも決めていかなければいけません。

「暫定対応」と「根本対応」の要点

共有ができたら、最後に対応しないといけません。脆弱性情報で対応していかなければいけないものがわかってくるので、それを実際にどう対応していくのか。対応のステップとして、大きく暫定対応と根本対応が紹介されています。基本的な考え方だと思いますね。


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

暫定対応としては、例えば抜本的な対応は難しいんですが、防御機構……例えば何かファイアウォールなどの追加設定とかで一時的にしのげるかどうか。別の回避策も脆弱性によってはあり得ると思いますので、そういった回避策が模索できるかどうかを検討していかなければいけません。

開発側であれば開発側で検討しなければいけませんし、下流の方々が脆弱性があるとわかったら、ベンダー側に「どういう対策をしていますか？」と言わないといけません。こういうことが書かれています。

根本対応のところもそうですね。基本的には根本対応していくのであれば、例えば脆弱性の情報が、パッチが当たったバージョンまでアップデートしたり、パッチを自分で当てていったり、そういったことが考えられます。

普通に脆弱性のあるものを使わないことだったり、直していったりするかたちになります。そういったものを行うと、SBOMの例えばバージョン情報が更新されます。VEX情報の更新などをやっていく必要がありますし、利用者側からするとそういったものを開発側に依頼しないといけません。

こういうふうに、7章には脆弱性の対応フェーズでどういう考え方で、対応が必要なことがまとめられています。

これが新しく追加された内容です。SBOMを使った脆弱性管理プロセスを具体的にどう落とし込んでいくかのポイントや考え方がまとめられているセクションになっています。

リスク対応において起きる現実的な問題

次のセクションが、対応モデルです。


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

次の取引モデルと関係してきているところではあるんですが、SBOMは、もちろん自社だけで活用して、自社でしっかりソフトウェアをリスク管理する用途でももちろん使えます。SBOMはサプライチェーンの中で相互運用していくことが目的で作られている考えであり、方法・手法論になります。

ただ、実際にはいろいろな問題が起きます。会社を跨いでいろいろなことをやろうとすると、すごく負荷が高くて、なかなか落としどころが見つけにくいです。

そういった実証実験を通して課題がわかってきたので、経産省で具体的にどういうところで落としどころをつけるべきかを一応のモデルとしてまとめたのが、こちらのセクションになるのかなと理解しています。

最初から大変なことをやろうとすると、すごく大変になってしまうので、やりやすい範囲からまずやり始める。会社間でやっていくとなると、大変になってくるので、そういうふうに考えていったり、落としどころをつけていくことも必要になってくるという提案ですね。

医療機器や自動車産業、ソフトウェアのサプライチェーンの実証実験の結果も、本ドキュメントにはすごい分量で書いてありますので、もし興味がある方は見ていただきたいんですが、ここではまとめだけサマライズさせていただきます。

会社間でSBOMの対応をする時に、どういう観点で大変になっていくかが、大中小のコストで書かれています。

例えば、ソフトウェアのSBOMを作成する場合。自社の開発で自社だけで作成することになると、自社の問題に閉じますので、非常に楽というか、コストは安いです。ただ、上流のサプライヤーや開発依頼しているところに、SBOMを作ってもらって出させないといけないことになってくると、コストが上がりますよね。

ぜんぜん取引関係のないオープンソースの方々にSBOMを出してもらわないと成立しないところまで行くと、もう方法がわからなくなってきます。「コストが大」と資料に書かれていますけども、非常に難しさが上がってきます。

まずは、適用範囲においても直接依存だけにして、管理していくところでいったん落としどころをつけるかたちであれば、やりやすさもあります。ただ、間接依存までマストの要件にしてしまうと、やりきれない部分も出てきてしまうケースもあります。そこは努力目標にするなどの落としどころもあるんじゃないかなと思います。（これも）「コストが大」と書いてありますね。

対応コストには大中小の難易度がある

あとは精査ですね。先ほど（の資料に）手動でやるか、ツールでやるかなどでも対応コストや難易度の大中小が分かれると書かれています。細かい話になりますけども、どのレベルまでやるかの問題があります。

バイナリのソフトウェアしか対応策がない。ただ、そこを解析できなかったりして、難易度が高いです。スニペット解析やバイナリ解析になると、すごく高いツールを使わないといけません。

それでも精度が保証できないみたいな世界になってきますので、そこまで完璧にやろうとすると、難易度がかなり高くなってきます。

まず、パッケージマネージャーや手動管理できる部分だけであれば、認識している範囲だけでやればやりやすいとか……資料の中でコストが小・中からまず始めるところが、いったんの落としどころとしていいのではないかという提案されているのかなと理解しています。

これから、会社間でどういうモデルにしていくかを考えるお立場にある方は、自動車産業の実証実験の例、ソフトウェア産業の例や医療機器の分野の例が分量を割いて載っていますので、参考モデルとして見ていただくといいと思います。

取引モデルをどうするべきか

最後は、この取引モデルですね。一つ前のセクションで、企業間や会社、組織を跨いでやり取りする時に、こういうモデルでやるのはだいたい大枠が決まってくるようになると思います。


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

それを契約や契約事項、取引の条件に落とし込んでいく時に、どういったところが観点として必要になるかが書かれているセクションになります。契約で規定すべき事項などを具体的に書いてくれています。

レベルとしては、基礎、発展で書かれていまして、基礎は最低限あってもいいんじゃないかと思います。例えば、SBOMのフォーマットは標準的には「SPDXの何バージョンでやり取りするかは、あらかじめある程度決めておかないといけません。出力したり、読み込んだりができませんので、そういったフォーマットはルールを決めておこうと提案されています。

文書の中では……その中で利用する部品のIDの標準は、CPE形式やPURL形式でやりましょう。どちらかでやりましょう。こういった一定のルールを決めておきましょう。この項目は、最低限やりましょう。

最小要素と言いつつ、最小要素が一つ欠けても問題ないです。ただ、このやり取りの中ではコンポーネント名とバージョン名とIDだけは必須で入れてください。最小の要件はすり合わせましょう。こんなことが提案されています。

委託開発の中でどの程度までやらせるか、どのレベルまでやるかが書かれていたり、先ほどの解析手法でもありましたが、バイナリ解析までやるのかなどのルール決めも書いてもいいんじゃないですかと提案されています。

SBOMに関する責任範囲の落としどころ

細かいところは発展で書かれていますけども、基礎的なところでは一つ決めてもいいと思います。

共有方法はどういうファイル形式でどう受け取るのか、リアルタイムに受け取るのか、何日以内に受け取るのか。脆弱性情報がある場合はアップデート情報をどう受け取るのか、SBOMの更新があればどう受け取るのか。

発展のところで脆弱性やEOLが出た時に、情報も受け取るのか受け取らないのかなども、契約事項というか要件事項にしっかり組み込んでいくことも必要になってくるかもしれません。

ここまでは、SBOMの要求事項、SBOMに関連するところですが、責任範囲として契約不適合責任、損害賠償や免責などは、しっかり明確にしたほうがいいと書かれています。

最後はコスト負担ですね。部品メーカーにSBOMを要求する際に、コストがかなり高くなるので、どう持つのかは書かないといけないかもしれませんね。そういったところも今後具体的に発生してくる可能性があるかもしれません。権利関係でも、知財や機密保持はもちろん書く必要があるかなと思います。

どんな対応モデルにして落としどころがあった上で方向性を決めて、取引モデルとして今話した事項をしっかり項目として書面にしていくのがいいんじゃないかと書かれています。

ドキュメントの最後にも、モデルや方向性を決めて書面に落として、SBOMの水準の保証をしていく必要があると書かれています。

経産省資料に国産ツールとして唯一紹介された「yamory」

いったんここまでが、ver 2.0でアップデートされた部分の解説になります。分量が多いドキュメントなのでワーッと話してしまいましたけども、足された部分については、実際問題起きる課題に対するベストプラクティスや、現時点での政府のベストプラクティスで紹介されていると思います。

最後にyamoryの紹介もさせていただければと思います。概要のところは、初めにyamoryの笹原から説明がありましたが、yamoryはいわゆるSCAツールですね。



ソフトウェアの開発やITシステムにおいて、ソフトウェアのコンポーネント、SBOMの管理などに基づくリスク管理が行える国産ツールになっています。

カバレッジが広いと紹介しましたが、先ほどの依存関係みたいな問題……脆弱性やライセンス、コンポーネント、EOLの問題も取り扱うことができます。そういった複数のリスクコンポーネントやソフトウェアのリスク管理の観点でお使いいただけます。


実は、今説明したver 2.0のP.153ページ目に国産ツールとして唯一紹介されています。ほかのツールは全部が外資系ツールなんですが、テストアカウントも渡して評価いただいて、国産ツールとしてしっかり載ることができています。品質も一定の評価をいただいたのかなと理解しております。


また、経産省の「情報セキュリティサービス基準」の適合認定も受けているソフトウェア、サービスになります。



どんなアプリケーションなのかを説明すると、こういうソフトウェアがあった時に、内部の部品を全部解析して、この部分に脆弱性やリスクがあることがパッと出てくる仕組みになっています。



ソースコードの解析や手動登録も行え、ツールでスキャンしきれない部分は手動でリストアップして登録する手法も用意しているので、カバー範囲が広く、いろいろ対応していただけます。

優先順位付けもできて、先ほどのKEVカタログみたいな悪用実績も瞬時にわかります。例えば、全体としてはすごく数が多いけど、まずこの4件から対応ということがパッとできたり、日本語化対応も進んでいるツールになります。日本でも活用していただけるツールを目指しています。いわゆるVEX情報もyamoryで管理できますので、対応ステータスの管理もできます。

もちろん、SBOMのエクスポート、インポートもできますね。SPDX、CycloneDX形式でエクスポートする感じですね。

基本的な機能は一通り揃っているかなと思いますが、脆弱性やライセンス、EOLなど、ライセンスのリスクをシンプルに確認できます。優先度が高いところから絞り込んで対応確認していくことをワークフローとして、組織的に作っていくことを目的としたツールになっています。

以上、終わりとさせていただきます。