SBOM実証の全体像
飯塚智氏（以下、飯塚）：2022年度までは、SBOMを作成するところを含めて実証を行ってきました。その結果のノウハウを2023年7月に、SBOM導入手引きとしてとりまとめて、公表しました。2023年度は、そのSBOMの運用に主眼を置いて実証を行っています。
特に運用の中でも、SBOMを活用した脆弱性管理の効率化を主に検討していくということを考えていまして、その全体像を示したものがこちらのスライドです。
まずサプライチェーンの中には、サプライヤー、最終ベンダ、ユーザー企業、そういったステークホルダがいます。そういったプライチェーンの流れのなかで、部品ないしSBOMを情報共有して、プレイヤーごとのフェーズにおいてSBOMの集約などを適宜行うことが想定されます。
右側の公的、民間的なものを含めた脆弱性データベースや、あるいは脅威情報とのマッチングを行いながら脆弱性対応を効率的に行っていくことを検討していきたいと考えています。
2023年度は脆弱性情報の提供に関わるところで、IPAやISACなどとも連携しながら、その脆弱性情報をどう効率的に取得するのかについても検討していきます。
また、最後にもう1つ、中小企業にもSBOMを活用していただきたいため、ツールの活用などを含めて整理していきたいと考えています。
SBOMによる脆弱性管理における課題
飯塚：これまでの実証や、ソフトウェアのタスクフォースにおいて挙がっている脆弱性管理における課題を全体的に俯瞰したものが、このようになっています。
横軸が脆弱性管理に関するプロセスで、脆弱性の特定や、特定した脆弱性の評価、優先付け、あるいは情報の共有や暫定対応、本格対応のように分かれてくると考えています。
縦軸が主要なプレイヤーやステークホルダです。最初の脆弱性特定とか優先付けのところではプレイヤーごとにそれぞれ並行して対応することになると思うので、ここでは各プレイヤーと記載しています。
情報共有フェーズ以降はプレイヤーごとに役割分担が生じてくるので、プレイヤーごとに分けて期差しています。
最初の段階では、SBOMが共有されているという状態をある程度想定しているところで、そのSBOMを活用しながら、脆弱性データベースとマッチングを行っていきます。
この際の課題として大きいのが、部品IDの一意性がないというところです。これが脆弱性マッチングの障害になり得ると考えていて、例えばツールによって独自の部品IDの形式が提供されていたり、部品IDの標準が複数の標準存在していたりすることがあります。それが脆弱性のマッチングの障害になるという課題があります。
それに加えて、脆弱性データベースというのも公的、民間的なものを含めて多数あるので、その網羅性をどう確保していくかが課題になってきます。
さらに、脆弱性が特定された後の課題として、特定された多数の脆弱性にどこまで対応するのかがあります。先ほども少し説明しましたが、全部対応する必要があるのか、その優先付けが必要になるので、その優先付けをどうやるのかも課題です。
その時に、深刻度の情報や悪用可能性、アドバイザリ情報などをどう使うのかなども課題になるかと思います。
さらに、各プレイヤーの対応の要否や優先付けを判断しながら、ソフトウェアの修正をする時は、部品を開発していたところにユーザーを含めてどう対応していくのか、ソフトウェアを修正した後にSBOMの情報のアップデートなどを通じて、サプライチェーンにどう共有していくなどが課題になると捉えています。
今、口頭でいろいろ課題を説明しましたが、こちらはあらためて課題を実証の要件ということで一覧に整理したものです。詳細は割愛します。
SBOMによる脆弱性管理プロセス
飯塚：このような課題を踏まえ、2023年度はSBOMを活用した脆弱性管理プロセスの整理や、実際の具体的ソフトを対象にした実証評価を行っています。全体のプロセスや具体的なステップにまで踏み込んで整理したものがこちらになっています。
まず（1）の脆弱性マッチングについてですが、こちらは具体的なステップとして、（1.1）のマッチング手法の選択や区分の選択、（1.2）の利用可能なSBOMデータの特定、（1.3）の対象とするDBの選択、（1.4）のマッチング手法の選択・自作と進み、ツールなどを含む脆弱性マッチングの手法を特定していきます。それから、脆弱性マッチングを実行してマッチング結果を得ます。
次にその結果に対して、（2）で対応の優先付けを行っていきます。そうしましたら、最後に（3）で共有以降のフェーズで進んでいきます。
ここでは主に（1）と（2）についてそれぞれ実証しているので、簡単ではありますけれども、実証の結果について説明したいと思います。
脆弱性マッチング
飯塚：（1）の脆弱性マッチングでは、先ほどのステップで実際に実証を行っています。マッチングの手法区分としては、APIや既存のツール、Web UIといった3つの手法区分について実証しています。
ポイントは、例えばAPIについては部品IDの変換、複数の脆弱性データベースとのマッチングが行えるといったところを確認してきています。
SBOMについては、Package URL（PURL）の採用が多く、脆弱性DB側はCPEの採用が多いということがわかってきています。対応が取れないといった場合には部品IDの変換などを行いつつ、柔軟に対応していく必要があることがわかってきました。
脆弱性対応・優先付け
飯塚：（2）の脆弱性対応の優先付けでは、今回、企業向けエンドポイントセキュリティ製品を対象に検証しています。コンポーネント名＋バージョンで検索した場合、脆弱性を10件程度確認しています。
CISAのSSVCという優先付けの判断ツリーに基づいて、実際に対応の方法の分類を行ってみたところ、通常対応が2件とか対応保留が8件などと分類できたという結果が得られています。
こちら、脆弱性の検索漏れを防ぐために、部品IDの検索の仕方について条件を緩めてやってみたところ、脆弱性の件数が385件とけっこう増えて見つかりました。これはけっこう誤検知の可能性が多いのではないかということで、件数が多いため、手動での精査も難しいのではないかというような課題も見つかりました。
以上が説明になりますが、ここで説明した最新情報は経産省のサイバーセキュリティ課におけるソフトウェアのタスクフォースのホームページで公開されているので、もしお時間があればご確認ください。
私からの説明は以上です。ご清聴ありがとうございました。
【質問Q&A】SBOMが経産省で話題になりはじめたのはいつ？
渡邊歩氏（以下、渡邊）：それでは、ここから質問タイムとさせていただきます。まず初めに、モデレーター特権ということで、私が聞きたいことをいくつか質問したいと思います。よろしくお願いします（笑）。
飯塚：（笑）。
渡邊：まず今回の実証実験のお話、SBOMがテーマになっていますけれども、「SBOMって？」みたいなことが経産省の中で話題になり始めたのは、いつぐらいなんですか？ けっこう昔からですか？
飯塚：もともと経産省のソフトウェアタスクフォースは数年前から立ち上がってきているもので、2023年の10月下旬にやったものが11回目になります。そのぐらいの回数で数年やっていて、SBOMの実証自体は2021年、2年前〜3年前ぐらいから取り組んできているところではあります。
それ以前は、これも我々経産省サイバーセキュリティ課から出しているOSSの管理の事例集として公表してきました。
そのような状況で、SBOMが米国の大統領令なども出てきた関係で動きが活発になってきていて、経産省も実証を踏まえて取り組みをいろいろ加速させています。
渡邊：なるほど、ありがとうございます。
【質問Q&A】海外の政府機関とはSBOMについてどんな話をしている？
渡邊：今ちょうど米国の大統領令のお話がありましたけれども、やはり国的な横の連携みたいなものはあるのかなと思うんですけれども。実際、例えば外国のこういったSBOMの検討をされている政府機関の方とかとお話をする際には、どんなお話をされているのか、あと、国として活発な活動をされているのってどこなのかなどが気になるんですけれども、可能な範囲で教えていただけますか？
飯塚：そうですね。もちろん我々も、必要に応じて米国あるいはEU、ないしは関連する各政府と、SBOMに関して会話をすることもあります。
ただ、ご存じのとおり、各国によってSBOMをどこまで求めるかは、けっこう時期によって考え方などがいろいろとアップデートされることもあるので、そのあたりは定期的に確認をしていく作業をしています。
大きいところでいうと、米国CISA主催の「SBOM-a-Rama」などのコミュニティ活動があり、そこで米国における実証の状況等が共有されていたりします。
あと、EUの各国で温度が高い方もいるので、そのあたりの方と、経産省の温度が高い方とも、必要に応じて確認はしています。もちろんそこに出ていない方でも、感度高くやっている方はいると思いますが。
渡邊：日本でもやはり独自でコミュニティ活動していたり、SPDXの活動をしたりしていることもありますので、本当に感度の高い方は、どんどんそういったところに参加されて、いろいろなところで情報収集とかされている感じかなと思います。聞きたいことを聞かせていただいて、ありがとうございました（笑）。
それでは会場の方からのご質問をいくつかピックアップして、聞いていきたいと思います。質問をたくさんありがとうございます。
【質問Q&A】『医療機器のサイバーセキュリティ導入に関する手引書（第2版）』にも経産省の意向が反映されているか？
一番初めにご投稿いただいた方がいたので、まずはこれからおうかがいします。
1件目の質問です。「『医療機器のサイバーセキュリティ導入に関する手引書（第2版）』にもSBOMの必要性が明示されました。こちらの手引書には、経産省の意向が反映されていますか？」という質問です。
ちょっと管掌の省庁さんが違うので、なかなかお答えしにくいところもあるのかなと思いますけれども、こういった、例えば医療機器のお話の動向も少し、何か議論をされたりはしているんでしょうか？
飯塚：政府全体として、まず、各省庁がバラバラなことを言うわけにもいかないので、基本的に、一般論に近いところでは基本的には足並みをそろえていて、そのへんは必要に応じて必要な会話は当然しています。
『医療機器のサイバーセキュリティ導入に関する手引書（第2版）』については、どのぐらいというところはあるものの、基本的な考え方としては整合性が合うように、政府として気をつけているところはありますね。
渡邊：なるほど、ありがとうございます。
【質問Q&A】SBOMの導入手引きはEUを意識したものになっているか？
渡邊：それでは、次の質問にいきたいと思います。「SBOMに関する説明、ありがとうございます。欧州方面への輸出がある製造業で勤務しています。EUで最近暫定合意されたCyber Resilience Actでは、SBOMの作成が求められており、欧州委員会がSBOMの形式や要素を指定できるようになっているかと思います」。大変お詳しい（笑）。もう解説みたいですね。
「ご質問としては、まず1点目、本日のセミナーでは、このあたりを意識したものでしょうか？ そして2点目、EUでのSBOMの形式、要素指定を待たずにSBOM作成に取り組んだほうがよいでしょうか？ ご意見をいただきたくお願い申し上げます」ということです。それはいかがでしょう？
飯塚：まず1点目ですが、今回の「SBOMの導入手引き」など、経産省がやってきているSBOMの関連の取り組みは、米国の動向やEU、Cyber Resilience Acなどについては常にアンテナを張って調査していて、動向を把握・確認しています。
どのくらい盛り込んでいるかと言われるとちょっと難しいところはありますが、当然SBOMは国内に閉じないサプライチェーンセキュリティに関する内容も含まれているので、まったく無視しているというわけではありません。
サプライチェーンは国内だけで閉じず、海外との連携、国際整合がどうしても必要になってくるようなところも応用例としては多いと考えているので、経産省もそういったところを意識しながら取り組んでいます。
2点目のお話は、「EUでの指定を待たずSBOMに取り組んだほうがいいでしょうか？」ということで、こちらは、SBOMの導入手引きにも書かせていただいています。
まず、EUの規制や米国の規制、日本の規制も当然意識していただきたいところではあるんですが、まずそもそもの組織内においてのソフトウェアの透明性を確保する、SBOMを使った脆弱性管理をより効率的にやる、なにか起こった時にすぐに迅速に自動的に対応できるようにする、などによって脆弱性対応を迅速化することが大切です。
あるいはライセンス管理について、ライセンス違反がないようにするであったり、開発の生産性を上げていくであったり、そういったような効果のもSBOMで十分得ることができるのではないかと考えています。
いわゆる御社のガバナンスの取り組みを上げるためにも、ぜひ積極的に前向きに捉えて取り組んでいただきたいと考えています。
渡邊：はい、ありがとうございます。SBOM、けっこう会社全体の動きになると大変な話で、「さぁ、やるぞ。今日やらなくちゃ」ってなってもなかなかすぐにはできないものでもありますので、そういう意味では、かなり準備期間をしっかり取っていただいて早めに取り組んだほうがいいとは、これは私の個人的な意見なんですが、思っています。
【質問Q&A】機械屋のBOMは公開されているが、ソフトウェアのSBOMも公開されているのか？
渡邊：では、次の質問です。「小職は機械屋なので愚問になると思いますが」、そんなことないですよ！「機械屋さんのBOMは公開されますが、ソフトウェアのSBOMも同様に公開されているのでしょうか？ ご教示いただけると幸甚です」とのことです。こちらはいかがでしょうか？
飯塚：モノによると思います。自ら作ったSBOMを公開している方やコミュニティの方もいるとは思います。それは今、この瞬間はいるということだと思います。
ただ、公開する義務が今後も発生してくるかというと、こちらは非常に難しいところもあり、導入手引きの中の「誤解と事実」のところでも書かせていただいていますが、必ず公開するというわけではない、ということです。
まずはサプライチェーン上の必要な方に必要なだけSBOMというものが共有され、運用されているというのが最低限重要なことです。
それをインターネット上の第三者に毎回必ず公開するかというと、それは場合によるかなと思います。必ず全部が公開されなきゃいけない、インターネット上の第三者に公開しなきゃいけないとかではないのかなと思います。それは、立場とかユースケースによるのかなと思います。
渡邊：ありがとうございます。
【質問Q&A】SBOMはどれぐらいの企業で導入が進んでいるか？
渡邊：それでは、次の質問です。「SBOMがどれぐらいの企業で導入が進んでいるかといったような情報はありますか？」という質問です。ちょっといきなりなので、数字的な情報などをお答えいただくのは難しいかもしれないんですけれども、なにか、例えば、ありますかね？
飯塚：確かに数字的なところをこの場で直接的にお答えするのはなかなか難しいところではありますが、経産省がこれまで実証してきたところでいうと、自動車ないしは医療機器、あとはソフトウェアの分野ですね。
特に、医療や自動車に関しては、人の命に関わる安全性が重要なところもあるので、ソフトウェアの透明性や脆弱性の管理もしっかりとした対応をやっていかなくてはいけません。今申し上げた3つの分野は、実証も含めて特に進んできているようなところはあると思います。
いろいろなSBOMフォーマットがあるので、企業によっては一部のフォーマットで実験的に進めているところもあると思うので、そのような企業では比較的前向きに進めていただいているのかなと思います。
渡邊：ありがとうございます。数値的な情報という意味では、同じデータが手引書の中にも使われているので参考程度に、というところにはなりますが。
こちらはLF ResearchというLinux Foundationのリサーチの結果で、日本の数字ではないんですが、海外の企業さんを対象に調査した結果として、例えば、この左上のところ対象組織の47パーセントがSBOMを導入済みみたいな、こういった数字なんかもあったりします。
手引書の中に書いてある数字ですので、手引書も見ていただきながらということにはなりますが、海外ではこれぐらいの数字になっているというところですね。
ちなみにですが、「どんどん増えていくよ」っていうところで、左の下のところですけど、2023年の導入率は88パーセントに達するとの推測なども出ています。ご参考までに。
【質問Q&A】脆弱性の発見は、手動で行う必要がある？
渡邊：では、次の質問にいきたいと思います。次はちょっとお答えが難しい質問かもしれないんですけれども、脆弱性のお話のところを取り上げたいと思います。
「脆弱性の発見は、手動で行う必要があるんでしょうか？ コンポーネントの情報を取り込んでおけばSBOMが自動で調べてくれるのでしょうか？」という質問です。こちらはいかがでしょうか？
飯塚：少し補足的に説明しようと思いますが、SBOMはそれ単体だけ見ても、構成情報や部品情報しか書いていません。例えば、ある部品がSBOMの中に書いてあっても、それが脆弱かどうかは、SBOMだけ見てもわかりません。
その、SBOMの中に書いてある部品が脆弱かどうかは、先ほど私が少し説明した、脆弱性データベースに問い合わせて、初めてその部品が脆弱かどうかの判断ができるようになる、という流れになっています。
そこがツールを使って自動的にできるのであれば自動対応可能ですし、「ツールやAPIで自動処理できないので、じゃあ手動でやるか」みたいな話にもなってくると思っています。
まずは、コストや費用対効果もありますが、なるべく脆弱性のマッチングやSBOM対応は、自動でまず処理するというのが、基本的には最初に考えるべきところかと思います。
まずそれを前提に考えた上で、どうしても残ってしまうところ、対応しなきゃいけないところについては手動で対応するなど、そのコストや効果を見た上で判断していきながら、導入を進めていくということだと思います。
渡邊：ありがとうございます。
【質問Q&A】SBOMの情報は、原則どこが作成するべき？
渡邊：では、次の質問なんですが、お二方、違う方からのご質問で、ちょっと関連するご質問が続いてきたので、この2つの質問を一緒にして答えていただきたいなと思います。読みますね。
「SBOMの情報は、アプリケーション製品を提供している企業が原則作成するものという理解でよろしいでしょうか？ アプリケーション内にどんなコンポーネントが含まれているのかという情報は機密情報になるので、一般的に開示してもらえないような気がするのですが、理解が誤っているのでしょうか？」というご質問が1つ。
それから、もう1つですね。「SBOMで管理する対象は、自社で作成したEXEやDLLなども含める必要があるのでしょうか？ 使用しているOSSだけを管理すればよいのでしょうか？ 『.NET Framework』や『Visual C++ランタイム』などもSBOMの対象になるのでしょうか？」
ちょっとたくさんあるんですけれども、1つずつお答えいただければと思います。
飯塚：（笑）。
渡邊：けっこう、このへんやはり気になるところ、多いんだなというイメージで。
飯塚：そうですね。
渡邊：まず「企業が原則作成するものという理解でよろしいでしょうか？」っていうところに関しては、いかがですか？
飯塚：こちらはケースバイケースかと思います。本来は、アプリを作っている人がそのままSBOMを作って納品先に納品するのが一番典型的な例として考えられますが。
ただ、何らかの事情でそういったことができない場合には受け手側、いわゆる納品を受ける調達側で、なんらかの情報に基づいてSBOMを作るとか。一部ではたぶんそういうこともあり得るかと思います。ケースバイケースですが、基本的にはどっちのケースもあり得るのかと思います。
渡邊：ありがとうございます。あとは、「機密情報だと思うんですけど、一般的に開示してもらえないですか？」というところ、いかがですか？
飯塚：これも企業によるのかなと思います。SBOMの重要性や脆弱性管理の重要性が、既存の契約の中でどう契約されているかにもよりますし、アプリケーションの開発元の企業のポリシーなどにもよると思います。
ここも「SBOMの手引きの中」で書いてあったと思うんですが、SBOMはソフトウェアに含まれているコンポーネントの一覧リストであり、特許やアルゴリズムは含まれておらず、知的財産を公表するものではない、などの記載があります。まずは商慣習に合わせて、対応できる範囲はどこなのかというのを、まずは前向きに検討してみてください。
どうしても一部は無理なんだということであれば、そこはあらためて精査する必要があるというところかと思います。
渡邊：ありがとうございます。あとは、もう1つEXEですとかDLL、自分で作ったもの。あとは、「OSSだけじゃなくて.NET Frameworkとかの商用製品、Visual C++ランタイム、こういったものもSBOMの対象になるんでしょうか？」というご質問。こちらはいかがでしょうか？
飯塚：ソフトウェアであれば、基本的には対象にするのがSBOMの大きな考え方です。よくある誤解というか、「OSSだけやればいいんでしょう？」というお話がよくあるんですが、そうではありません。攻撃者は別にOSSかそうじゃないかを意識して攻撃してくる人だけではないので。
やはりSBOMは、本来であればなるべく広い範囲で、OSSも含めてもう少し広いかたちで対応していくのが理想的な使い方かなと思います。
何をどこまで、そのSBOMの作成範囲にするのかといったところについては、当然議論もあると思うので、まずはどこまでSBOMの作成対象にするかを整理するのが重要ではないかなと考えています。
このあたりは、手引きの中でも対応範囲のところで触れているので、該当箇所を読んでいただければと思います。
渡邊：ご質問ありがとうございました。そしてご回答ありがとうございました。
飯塚：はい。
渡邊：まだまだたくさんご質問いただいていますが、時間の関係上、今の質問で最後とさせていただきます。申し訳ありません。
それでは、ここまでで飯塚さまのご講演、それからQ&Aのご対応ありがとうございました。
飯塚：ありがとうございました。
