『ソフトウェア管理に向けたSBOMの導入に関する手引』の4章を読む前に
渡邊歩氏（以下、渡邊）：ではさっそく今日のお話に入っていきたいと思います。こちらの資料に関しては、今日のセミナー用に作った資料になっていまして、手引き書の内容を少しサマライズしてPowerPointにまとめたものです。こちらを映しながらお話をしていきます。
ちょっと1点、注意事項というわけではないんですが、最初にお話ししておきたいこととして、昨日は飯塚さんに、経済産業省さんの立場で出てきていただきましたが、今日の篠原さんと私はそれぞれ三菱総研と日立ソリューションズという立場で出ていますので、今日お話しする内容は、例えば私個人の意見だったり、篠原さんの考えみたいなところがあったりするかと思います。
それは経済産業省さんの意思や方針というわけではなく、あくまで日立ソリューションズや三菱総研の方針であったり、私たち個人の考えになるので、その点だけご留意いただいて聞いていただければと思います。
それでは、今日触れていきたい内容です。まずこちらに映っているのが目次です。これは手引き書の目次そのままです。昨日もちょっとお話ししましたが、全体構成としては1章から7章までありまして、7章は「付録：チェックリスト・用語集等」になっているので、本編は1章から6章になっています。
昨日は1章から3章までを飯塚さんにお話ししていただいて、今日のDay2で私たちは4章から5章をカバーできればと思っていますが、実際のところ、実は4章がけっこうボリュームが大きいので、今日は4章で終わっちゃうかもなというところで、もしかすると明日に5章、6章というかたちになるかもしれません。
あとは、昨日ご参加いただけなくて、今日からですよという方がいるかもしれませんので、ちょっと復習も兼ねて、1章から3章の部分も少し拾ってカバーしていきたいなと思っています。
1章のおさらい
では、まず1章のところです。いきなり復習から入っちゃうんですが、背景と目的というところです。全部は読まないので、画面を見ながら話を聞いていただければと思いますけれども、1章は昨日もお話がありましたが、SBOMがこのように活用されるようになった背景についてまとめているものです。
少し簡単に、全体として何が言いたいかというと、産業に占めるソフトウェアの重要性が高まっていますと。それによってソフトウェアを利活用した製品の安心・安全の担保が非常に気になっていて、その中から脆弱性の確実な管理が謳われるようになってきました。
例えばサイバー攻撃なんかで、あまり例が良くないですが、何か乗り物のようなものがハッキングされてしまい事故にあったりとか、あとは何か踏み台にされて他者への攻撃に使われてしまったりとか。そんなことがあったりしますので、脆弱性の確実な管理というのは非常に重要ですね、というのが課題としてあります。
その中で、確実に脆弱性の管理をしようと思った場合に、何が課題になってくるのかというと、そもそもその製品であったりサービスだったりに、どのようなソフトウェアが含まれているのかを把握できていない。あとは、もし把握できていたとしても、間接的な脆弱性の影響ですね。
これは例えばですが、1つのモジュールで何か部品があった時に、その中側でまた別のモジュールを使っていたりするような、入れ子構造になっているようなケースがあったりします。そうすると、その間接的に使っているものの影響を検知できなかったりするようなリスクがあったりします。こういったところで、脆弱性管理における課題のために、SBOMの活用に注目が集まっています。
SBOMは昨日も説明しましたが、Software Bill of Materialsの頭文字のS、B、O、Mを取って「エスボム」と呼ばれていて、ソフトウェアの部品表のことです。SBOMというと、昨日もちょっと質問みたいなものもあったりしたので。SBOMってどういうもの？ というのを少し実感してもらうなら、やはりみなさんが例に出すのは食品の原材料表示ですね。
篠原さんも、たぶんよくそういった例でお話しされるんじゃないのかなと思うんですが、みなさん手元に、例えばおやつとかでこういうのがあったりすると、食べ物の裏側を見ていただくと、食品の原材料表示というのが出ていまして、中にどんなものが入っていますよというのが書いてあったりします。これはちなみに静岡県限定の源氏パイです！
これですと、アレルギーの物質として小麦とか乳製品とか、大豆とかが入っていますよみたいな表示があったりします。SBOMというのは、これのソフトウェア版のようなものですね。中にどんなものが入っていてどんなリスクがあるのかがわかるというのが、SBOMのうれしい部分です。
経産省における取り組み
次のページですね。経産省さんにおける取り組みということで、こちらは昨日飯塚さんにたくさんお話ししていただいたので、ほぼスキップでいいかなと思いますが、見ていただきたいのはここですね。実証参加企業の分野に関して、2021年は自動運転システム開発向けの検証基盤ソフトウェア。2022年は医療と自動車とソフトウェアの分野。それぞれ産業界の会社に参加していただいて、実際にSBOMを作ってみるということが行われた実証実験です。
ここで篠原さんにおうかがいをしたいんですが、ここは今自動運転とか、医療、自動車、ソフトウェアの分野で出ていますけれども、なぜこういった分野のものが選定されたのか、その理由は何だったのでしょうか？
篠原巧氏（以下、篠原）：総論的にいうと、どの分野もSBOMに関する関心ですとか注目度、さらには要求度合いが高まっているというところがあったかなと思います。医療機器も自動車も米国を中心に規制化や推奨化の動きがあるほか、ソフトウェア分野については先ほど申し上げたような大統領令の中で米国の政府調達についてSBOMを求めていくということが発表されていました。
総じて、かなりの分野それぞれでSBOMに関する高まりを見せていたので、日本でも取り組んでいく必要があるだろうということで、こういった分野を選定しました。
渡邊：なるほど。やはり感度が高くて、というところなわけですね。じゃあ実際に、例えばこれらの分野の方で共通するような期待効果というか、SBOMを入れることによってこんなメリットがあるだとか、逆に課題に共通的に対応できるんじゃないかみたいな、そういった何かこれらの分野に共通する特徴とかがあったりするんでしょうか？
篠原：そうですね。手引きに書いている内容は、けっこう共通している部分かなと思っていて、SBOMのメリットとしてはその脆弱性管理におけるメリットやライセンス管理におけるメリット。またそのリスク低減効果とコスト低減効果というところで整理しています。そういったメリットを享受できるのは、分野に寄らず共通して言えることかなと考えています。
一方で分野ごとに、やはりサプライチェーンの構造が異なるというか、契約の形態とかも異なることが多いので、そういったところは留意が必要かなと考えています。
渡邊：なるほど。例えば具体的なその違いというのは、例を挙げるとしたらどんなものになるんですか？
篠原：例えばその自動車分野ですと、一番上にサプライヤーがいて、Tier1さんがいて、Tier2さんがいてというサプライチェーン構造になっているかなとは考えていますが、ソフトウェア分野がそうなのかというと、ソフトウェア分野ですとOSSの利用が活発であったり、そういった契約形態がない部分でソフトウェアを使っていたりというところで、使っているソフトウェアに関する契約形態とサプライチェーン構造は異なっているかなと思います。
渡邊：なるほど。あとは例えば自動車の分野とかでよく聞くお悩みとしては、ソースコードが納品されなくてバイナリしかないとか、部品しかないみたいなかたちで、ちょっと情報が少なめとかそういう話もあったりしますよね。
篠原：そうですね。おっしゃるとおりですね。
渡邊：そういったいろいろな課題みたいなところに関して実際にSBOMを作ってみると、例えばコストだったりそれに見合うROIだったりとかなのかもしれないですが、どういった効果があるのかというところを実証で調べていって、明らかにしていこうというようなところが、この実証実験の目的なのかなと思います。
SBOMを導入すること自体が目的ではない
渡邊：こんな感じで実証実験をしまして、手引き書の作成の目的がこちらです。ここに関しては、例えばこれは篠原さん、ここも絶対に目的としてポイントにしているところがあったりしますか？
篠原：この手引きを書く中でけっこう気にしていたのは、SBOMを導入すること自体が目的になるわけではなくて、あくまでソフトウェア管理の一手法としてのSBOMなので、SBOMは手段であると我々としては考えています。先ほど申し上げたとおり、脆弱性管理やライセンス管理という目的がある中で、それを効率的に済ませることができる1つのツールがSBOMだと考えています。
なので、この手引きの目的に限らず手引き全体を通じてのところではありますが、SBOM（の作成）が目的化しないように、そういった記載はちょっと工夫したところがありますね。
渡邊：活用の部分とかがむしろ目的ですよ、というところなわけですね。
篠原：はい。なので手引きの正式タイトルも「ソフトウェア管理」というところが最初の冒頭にはありますが、あくまでSBOM導入がドンというわけではなくて、ソフトウェア管理という目的があって、それに対してSBOMをどう導入していくのかの手引きを策定しているという点は、認識していただけると大変助かります。
渡邊：そこは重要なポイントですね。あとはこの太字の部分にもなりますが、この手引きは主にソフトウェアサプライヤーを対象にしたものです、と。また、ソフトウェアを調達をして利用する企業さんでも使っていただけますよということが書いてありますけれども。今回のこの手引きでソフトウェアサプライヤーさんを主対象にしたところは、何か理由があったりするんですか？
篠原：SBOMのメリットを一番享受できて、かつその導入に関して課題に直面しているというところで、ソフトウェアサプライヤーさんを主に対象にはしていますが、対象としているソフトウェアについては、こういったいわゆるPCに入れるようなソフトウェアに限っているわけではなくて、実証で行った医療機器の組み込みですとか、自動車の組み込みというところも対象にはしています。
なので、必ずしもソフトウェアサプライヤーさんだけが参考になるというわけではないというところは、ご認識いただけると幸いです。
渡邊：はい。そうすると今ちょっと具体例が出ましたが、例えば医療機器のメーカーさんや、ハードウェアのサプライヤーさんみたいな方たちは、この手引き書をどうやって活用するのでしょうか？
篠原：そうですね。そこは基本的にはサプライチェーン構造にも寄ると思うんですけれど、やはりソフトウェアにSBOMを適用して、それを活用していくというプロセス自体は大きく変わらないかなと考えていますので、同じように手引きを確認して、その導入に向けて準備を進めていくことができると考えています。
渡邊：なるほど。そういった目的で作られましたというところですね。実際に読んでみていただければと思います。
2章のおさらい
渡邊：というところで、次の2章にはSBOMの概要ということが書かれています。この概要についても、昨日飯塚さんのほうで細かくお話ししてくださいましたので、ここはもう本当に読むだけというか、見るだけというかたちです。
SBOMというものはこういうものですよという、ちょっと概念的なイメージで、実はこれそのものがSBOMというわけではありません。イメージとしてこういう複雑な構造でやり取りをされるソフトウェアの中身、それから依存関係を表したイメージということで、よくこういったような表をスプレッドシート形式みたいな感じのイメージで見せられることが多いかな、というところ。
特に脆弱性の管理の課題に対する1つの解決策として期待されているということで、先ほどの繰り返しですが、SBOMは作って終わりではなくて、そのあと何をするかというところまで考えて作っていただくのが大事というところかなと思います。こちらの図も昨日お見せしていたので、ここも見るだけかなと思いますが、SBOMありの場合・なしの場合と比べて、脆弱性で何か起こった時なんかに対応が完了するまでの時間が非常に短縮することができるというところ。
あとは実際にコンポーネントを管理する、SBOMによる脆弱性の管理コストに関して、これは実証の検証結果のグラフですが、手動でコンポーネント管理をしている時に比べて、SBOMを使うことによって約30パーセントに低減できます。7割カットですかね。ここに関しても実証の結果、非常にコストメリットがありますよといったようなところが出ています。
こういった数字というのは、現場の方が見るというのも、もちろんありかもしれないんですけれども、どちらかというと、SBOMをやるとこんなにコストに関するメリットもあるので「やりましょうよ」と経営層の方を説得するための材料にも使っていただける情報かなと思っています。これら2つの図も、手引き書の中に書いてあります。
次ですね。NTIAが定める最小要素の定義というところで、SBOMって結局何なの？ というところのいわゆるちょっとデファクト的な定義がこちらのNTIAさんが定めている最小要素の定義です。こちらも昨日飯塚さんにお話ししていただきましたけれども、データフィールドとしては、7種類でこういった内容が書いてあること、と定められていたりですとか、特に自動化のサポート。
SBOMは、やはり効率的に管理をするところが目的としてありますので、自動生成とか可読性のところの自動化のサポートがあったほうがいいと。そのためには機械判読かつ相互運用が可能なフォーマットが使われることが推奨されています。決まっているというわけじゃないんですけど、そういうかたちになっていますというところですね。
NTIAの最小構成がスタンダードなのか
渡邊：このNTIAさんの最小構成というのが、今回の経産省さんの手引き書の中でもやはり一番最初に、定義というところで紹介されていたものです。ここを篠原さんにおうかがいしたいんですが、これは例えば海外でも同様に、このNTIAさんの最小構成がスタンダードみたいなポジショニングなんでしょうか？
篠原：そうですね。スタンダードという位置づけと理解していますが、全世界がたぶんこれをベースに、今後も永続的にこれを使っていくかということではないかなと個人的には考えています。例えばなんですが、ドイツのBSIという情報セキュリティ庁が、同じようにこのSBOMの手引きというか、技術要件のガイドラインを出しているんです。
その中で、ドイツの国内のソフトウェアベンダーに対して最小要素というかたちで提供しているのは、データフィールドだけでいうと、ここに書いてある7項目に加えて「ライセンスの情報も含めてください」ということを言っているんですね。
なのでこのNTIAが言っている最小要素というのは本当に最小で、ベースにはなっているんですけれども、各国の状況を踏まえて、各国が独自で追加したり、「これはいらないよね」という項目があれば削除したりというところで、独自の取り組みが進んでいくかなと考えています。
あとは、このNTIAが定めた最小要素というのが2021年7月。なので、今から見ると2年半ぐらい前に出た情報になっていて、このSBOMの注目度合いを見ると、2年半前ってけっこう状況が変わってきているので、その見直しも必要だよねというところを言われているので、最初に申し上げたとおり、今出ている（定義）である、2021年7月のこの最小要素が今後未来永劫続いていくわけではなくて、今後も改訂がなされるのかなとは個人的に考えているところです。
渡邊：なるほど。私も「なんでライセンスが入らないんだろうな」というのがずっと不満というか（笑）、疑問なんですよね。何かモノの情報を伝えていくところで、ライセンスって絶対に重要な情報だと思うんですけど、このNTIAの最小要素には入っていないというところが、自分的にはモヤモヤするところではあったんです。
けれども、例えばドイツでライセンスの情報を入れるという話が出ていたりしていて、「同じことを考えている人がいるんだなぁ」と、ちょっと今うれしくなりました。そして今後もこれが変わっていく可能性があります、というところですね。そこも非常に重要な情報かなと思います。
あとは本当にちょっと細かい話になってきてしまうんですけれども、このOther Unique Identifiers。一意な識別子のところなんですけど、ここって単にIDが付いていればいいだけではなくて、ちゃんと活用できる情報であるべきというのを思っていて、なのでここがそれこそPURLだとかCPEだとか、そういう情報になるべきなんじゃないのかなと思ったりするんですけど。それは私の個人的な意見でしかないんですが、篠原さんはこのへんのUnique Identifiersについてはどうお考えですか？
篠原：おっしゃるとおりで、そこはなるべきかなとは思います。ただ、理想論を言えばなるべきなんですけれども、まさにその脆弱性のIDの部分って、CPEなのかPURLなのかについては、昨日の飯塚さんのお話にもありましたが、まだ一意に定まっていないというところなので。仮にそれを決めてたとしても、じゃあどういったIDを入れればいいのかという部分は、かえって作る側が困ってしまうという懸念もあるので、なかなかそのSBOMだけで決められないという状況もあるのかなとは考えていますね。
渡邊：なるほど。そういうことですね。そういう意味でも、今のところのスタンダードとして、何かベースラインがないとみんな議論ができないというところはあるかと思うので、このNTIAの最小要素というものが定義されたこと自体は、すごくすばらしいことだとは思います。ただ、やはりここに今後変わっていく可能性とか追加の議論の必要性というのはあるよねというのは、ちょっと思っていることですね。
SBOMのフォーマット
渡邊：では続けていきますね。最小要素の話に触れました。このあとこのスライドに関しては、代表的なSBOMフォーマットというところで、こちらはちょっと右側に書いてありますが、導入手引きには書いていなくて、今回作ったスライドなんですが、SBOMのフォーマットというものがありますよというところです。
これはなんでかと言いますと、SBOMは最小要素が書いてあれば基本的に何でもいいと言えば何でもいいんですが、やはりもらった側がそれをちゃんと自動的に読み取って管理をするというところまでが目的というところがあります。なので、例えばA社さん独自のフォーマット、B社さん独自のフォーマットの両方が生まれちゃってどうしようという状態になりかねないというところで、代表的なフォーマットが一応あります。
推奨フォーマットなんですけど、これに従って作っていただくと相互のやり取りが簡単になりますよといったようなもので、定義があります。代表的なものとしてSPDX、CycloneDX、SWIDがあります。よく「違いは何ですか？」と、聞かれることがありますが、どれも本当に実績のある重要なもので、良い・悪いの話ではぜんぜんなくて、好みの問題かもしれないみたいなことを思ったりもするんです（笑）。
けれども、一応の特徴としてSPDXはライセンスの情報の表現に強く、CycloneDXはセキュリティの情報の表現に強いというところかなと思うので、こういったところのどっちを重要視するかみたいなところで、使い分けるというのもありかもしれないなと思います。
ちなみに、先ほどのお話で、NTIAの最小要素には入っていないライセンスという話になってくると、SPDXはライセンスの情報がすごく豊富に書けるので良かったりもします。一方、先ほどのセキュリティの話、CPEとかPURLとかはCycloneDXのほうにはちゃんとそれ用のパラメーターがあるので表現しやすく、そういったところに特徴があります。
これはもう使い分けでしかないかなと思うので、後から出てくる取引慣行みたいなところも踏まえて、適切なものを適用していくというかたちになるかと思います。
ここまでが2章の最後なんですけれども、昨日のお話にもありましたけれども、明らかになった誤解と事実というところで、やはりもともとのみなさんの誤解だったり、本当はこうですよというようなことを言いたいものもあったりして。2022年の日本における実証を通じて明らかになった誤解と事実がありました。
特におそらくみなさんも同じような思いや考えがあったりするのかなと思いますので、その誤解を解いていくという意味では、非常に参考になるコンテンツかなと思っています。篠原さんはこの、ページとしては2ページ分ありますが、例えば取り上げたいものとか、確かにここはすごくあるなと思ったような誤解とかあったりしますか？
篠原：そうですね。今レーザーポインタがある3番のところは、個人的には誤解していた部分です。やはりそのSBOMツールは国内のベンダーさんや海外のベンダーさんあわせて、いろいろなツールがありますが、けっこう値段が高額だったりするので、なんとなくそのツールを使えば完璧なSBOMが出るんじゃないかと思ってしまうんですが、実際はそうではないよねというところ。
ボールド（太字）にしていただいていますが、SBOMツールによって出力されたSBOMをレビューする工程が必要です。言い換えると、誤検出とか検出漏れの可能性があるので、そこも見据えて、きちんとSBOMを作っていかないといけないというところが、実証で明らかになった一番大きなポイントかなと考えています。
渡邊：なるほど。確かにそうですね。私もお客さまにツールをご提案して、ご提供している立場でもあるんですが、実際にそのとおりで、機械に満点を求めるというのもなかなか難しいところもあったりもします。やはりツールは完璧ではないんですよ、というところはあるかなと思います。
逆にツールの弱みをカバーするような運用や、出力されたSBOMをレビューする工程とかそのやり方みたいなところなどを人がカバーしてあげないといけないですよというところは、確かにこの誤解と事実というところではあるかなと思います。
私が個人的に気になった誤解はこの4番で、すべての脆弱性に対応する必要があるというところ。これはなんか誤解というよりは、そう考えている方も多いんだろうなというようなところではあるんですけど。例えばSBOMを作って、ツールが例えばこのコンポーネントにこういう脆弱性がありますよというものを出してきてくれたとします。
けれどもそれが例えば何十個、何百個みたいなレポートがされるようなケースがあったりして、じゃあそれを全部見て確認して対応するのかというと、それはかなり時間的に拘束されるし、どうしようかなというところがあったりすると思うんですね。やはりゼロにしなきゃいけないのか、脆弱性ゼロというのが現実的なのかというところの問題になるんです。
けれども、やはりここもコストだったり実際にそれを放置しておくことのリスクの大きさだったり、そういったところの兼ね合いになるかなというのはあって、ちょうど書いてありますが、優先度を踏まえた脆弱性対応が必要なのかなと思います。
例えばネットワークに接続していない、本当に閉鎖環境で使うような製品なのにネットワーク越しの攻撃のなんか、例えばリスクとかを報告されても「いやいや……」みたいなところもあったりするかなと思います。
ここはどうですか？ 2023年の実証実験だと、脆弱性のトリアージにも触れているかと思うのですが、こういったところは2023年に何か明らかになってくるようなものなのでしょうか？
篠原：そうですね。2023年は、まさにこういったところを実証しているので、何らかの考え方や優先度付けのユースケースというところは、今後示していければと考えています。
渡邊：なるほど。ここはけっこう大事なポイントなので、あとからぜひこの手引き書を読んでいただきたいなと思います。
3章のおさらい
渡邊：3章ですね。ここはもうこれだけなんですけれども、この手引き書としてはSBOMの導入プロセスというものをこういうふうに定義していますというところです。フェーズとしては環境構築・体制整備のフェーズがあって、いろいろとステップに従ってやっていただいて、それで体制の構築ができたら、次にそれを使って実際にSBOMを作っていきましょうと。
SBOMを作ることだけがゴールではなくて、それを使った運用管理もやっていかなくちゃいけないので、ここまでできるようになって、初めてSBOMが導入できたといえるような流れになっています。手引き書としては順番にこの環境構築のフェーズからステップに従って、こういうことをやっていくのであれば、こういうことを気にしましょうというお話ですとか、それに関する補足情報なんかが書かれているので、この先からはこのステップに従って見ていきたいと思います。
（後半につづく）
