近年、ソフトウェアの脆弱性やマルウェアの台頭で、ソフトウェアのバージョン管理や脆弱性管理などの重要度が日に日に増しています。SBOMはソフトウェアの部品構成表ですが、構成情報の透明性を高めることでライセンス管理や脆弱性対応への活用が期待されます。 3日目は、2日目に続き『ソフトウェア管理に向けたSBOMの導入に関する手引』の概要について、4章～6章を中心に解説します。後半は「SBOMの作成に関するポイント」から。

提供元：ログミー株式会社

渡邊歩（以下、渡邊）：SBOMの作成に関するポイントというところですね。これはもう、どのフォーマットがという話ではなく、SBOMそのものの全般の話ですけれども、いろいろポイントとして書かれています。

例えば、正確な情報は不足なく記載することが望まれます。「NO ASSERTION」はわかりません、不明みたいな感じの意味なんですが、これを書くこともフォーマット上は許容はされていますが、多用しないでできる限りちゃんと正しいものを書きましょう、と書いてあります。

2点目は、先ほどと同じですね。人からもらったものをそのまま使えないケースもありますよ、ということ。

3点目は継続的管理の観点ということで、いつ作ったSBOMなのかをちゃんと記録しているか。

あとは、この、自分が作ったSBOMっていうものを誰かに渡した時に、その渡された方もちゃんと使えるようにっていうところで、フォーマットがちゃんとできているか、自分としてはSPDX形式で書いたつもりだが、実は書式をちょっと間違えていましたとかがないように、ちゃんと渡す前に確認をしましょう。そういったことが書かれています。

ここからが補足になるんですけれども、例えばこういったフォーマットチェックができるツールなんかもあります。画面のキャプチャーが載っているのは、SPDXのバリデーションをするツールです。オンラインのツールなんですが。

例えば、自分がSPDX形式のSBOMを作りました。これを人に渡す前に、「本当に大丈夫かな？」っていうチェックをしたい時に、例えばこの「SPDX Online Tool」のValidateっていうのを使います。

SPDXのファイルをアップロードして、ちゃんとフォーマットに従って書かれていれば「OK」、ちょっと間違っているところがあれば「NG」って出てくるので、そういったチェックをするツールもあります。CycloneDXも同じようにありますので、使ってみてください。

4点目、ここがけっこうポイントだと思いますが、自分が作ったSBOMをほかの人に渡して、ほかの人がまた活用するっていうことがあるので、使う内容というか書き込む内容、例えば、コンポーネントの名前に社内のプロジェクト名称を書いちゃうとか、バージョンの情報とかを自分たちだけのIDを書いちゃうとか、そういうことをなるべくしないようにしましょう、ということもポイントとして書かれています。

渡邊：次が実際に作ったSBOMを他社にお渡しして共有するポイントです。

対象のソフトウェアに関して、利用者および納入先に対するSBOMの共有方法を検討して、必要に応じて渡しましょう。共有にあたっては、改ざん防止のための電子署名などもありますよ、ということが書かれています。

ポイントとしては、50ページのところに書いてありますね。ちょっとここがたぶん実証のところでポイントになったかなと思いますが。

共有することがあった時、実際に自分が作ったSBOMをほかの人に渡した時、ほかの人がそれをどう扱うのかという話になった時に、ほかの人が例えばそれをまた別の自分が使っているツールにインポートして管理ができれば楽だよねという話はありました。しかし、ツール同士の整合性みたいな話もあって、インポートがうまくできないみたいなケースもありました。

それについて、例えば、クラウド上でツール自体を共有するみたいなお話であったり、納入先と納品先、いわゆるサプライチェーンの中で同じツールを採用するといったことも検討することが実証の中でも書いてあります。

もう1個のポイントとしては、改ざん防止ですね。電子署名や分散型台帳技術なども使うといいですよ、ということが書かれています。

例えば、SBOMの電子署名としては、「Sigstore」とかがよく使われます。Sigstoreに関しては、使ってみられた方、詳しい方がいると思いますが、あまりよくわからない方は、2022年のセミナー「OSSマネジメントフォーラム2022」で、LINUX系VTuberの熊ケ谷リナさんがこれについて解説をしていますので、このリナちゃんの解説を読むと、少し使い方がわかるかなと思います。こちらもチェックしてみてください。

ここは、篠原さんにちょっと聞きたいんですが、例えばこの改ざん防止みたいなお話、電子署名みたいなお話は、今もう一般的になっているものなんでしょうか？

篠原巧氏（以下、篠原）：いえ、まだ一般的とは言えないかなと思いますね。そもそもSBOM情報の共有がまだ一般的になりつつあるぐらいかな、と考えていて、今後共有方法に関しても議論が進むものと考えています。実証の中でも、インポートできるのか否かの課題に直面した部分でもあるので、まずは、共有をしっかりやった後に電子署名としてどうするのかの話があるかなと思っています。

渡邊：なるほど、次のフェーズで。

篠原：はい。参考情報として、米国のほうで2023年の4月ぐらいに、SBOMの共有に関する文書が出ていたんですが、その中で、SBOMの共有に関する成熟度ということで低・中・高の3段階あったんですが、電子署名とか、このブロックチェーン技術は、成熟度「高」に位置づけられていたので、ちょっとまだまだそこに、社会全体としてそこに成熟するには時間がかかるかなと、個人的に考えています。

渡邊：なるほど、ありがとうございます。そういうことですね。これからという感じ。

私の周りでも、あんまりまだここに取り組んでいる方、「具体的に実用化していますよ」というお話をそんなに聞かないので、たぶんまだこれからなのかなとは思いますけれども、また次のテーマとしてこのあたりもありそうですね。ここまでが、共有のお話です。

渡邊：最後に、共有した後、例えばもうこれは自分が作ったものとか、人からもらったものとか、両方あるかと思うんですけれども、SBOMを実際に運用・活用するフェーズのお話です。

昨日のお話でも、SBOMは作って終わりじゃなくて、活用して初めて活きるものっていうお話があったので、例えば脆弱性の管理とかライセンスの管理とか、こういったところに、活用するというフェーズのお話があります。

あとは、SBOM情報自体の管理というフェーズがあって、6章は運用・管理のフェーズになっています。

まず実施事項としては、導入可能な環境の要件を確認して整備しましょう。取扱説明書をきちんと読んで導入と設定を行いましょう。

その中で、認識しておくべきポイント、注意ポイントですが、やはり特殊な環境になると思うので、例えばですが、ちゃんとそれがインストールできる環境が自分たちの会社の中にあるかが確認ポイントです。

あとは、無償のツールの場合はやはり情報不足なので、やってみてちょっとうまくいかなくて、またちょっと設定変えてうまくいかなくて、という試行錯誤的に行う必要があります。

これができる体制とか体力、あとはナレッジ、スキルが会社の中にあるかも含めて、意外と、無償のツールがいいと思って始めたが、使いこなすところまでがすごく難しくて工数がかかっちゃって、有償のツールを買ったほうが安かったかも、というようなことも、なくはないかなと思います。

そういった部分、ご自身の環境、会社の中の体制とかパワー、リソースに適切なものをという意味で、無償のツールを使う場合は、そういったことができるかどうかを事前に確認することが大事かなと思います。

あとは、脆弱性の管理に活用する場合は、障害発生すると止まっちゃって、その間の脆弱性が検知できなくて攻撃されることもなくはないので、障害発生時のための稼働監視、それからバックアップにも気をつけておきましょう、ということがポイントとして書かれています。

こちらが補足の中に書いてありますが、各段階における課題と対策というところで、実際にツール導入の環境整備のところと、実際にツール導入、インストールするとか環境構築するところで、稼働後のそれぞれの課題とその対策が手引書の中には書かれています。

最初のところ、まずSBOMに基づく脆弱性の管理、ライセンスなどの管理の実施ということで、活用を具体的にどのようにするのかというお話です。

例えば脆弱性の話になると、SBOMツールであれば、例えばSBOMの中に入っているコンポーネントの脆弱性としてこういうものがありますよ、ということをお知らせしてくれます。

それを基に、例えば脆弱性の対応をするわけなのですが、深刻度とか影響度、脆弱性の修正の方法、残存リスクの確認、あと実際に自分たちの製品に脆弱性があることがわかった時に、それをちゃんと関係機関に報告してみなさんに周知してもらいましょうとか、そういったことも検討する必要があります。

もう1個は、ライセンスのお話ですね。ちょっと今日は、もともとセキュリティのお話というところで、手引書のメインはセキュリティなんですが、セキュリティだけではなくてライセンスの話もすごく大事。OSSのライセンス違反が発生していないかどうかを確認することも重要ですよ、ということが書かれています。

ここがポイントですね。そもそものSBOMの正確性っていうところになると思いますが、こういった脆弱性の情報のリスクとかライセンスのリスクというのは、あくまでSBOMに書いてあるSBOMの内容、SBOMが特定するコンポーネントの名前とバーションから引き当てられる脆弱性があるかないか、それのライセンスがどうかという話です。

なので、そもそもそのSBOMのコンポーネントの情報が正しくないと、脆弱性の情報とかライセンスの情報もさらに間違うことがあります。なので、こういった活用をする際の情報のもともとのベースになるものなので、SBOMの中に書いてあるコンポーネントの情報が本当に重要ということが、ここに書かれています。

あとは、脆弱性の話とそれからライセンスの話もありましたが、EOL、End Of Lifeも、同じくSBOMで管理できる情報として書かれています。

ここではちょっと繰り返しですが、脆弱性の管理ができます。例えば、人からもらったモジュールにSBOMがついていれば、それを基に同じように脆弱性の管理とかライセンス管理ができます。

それから、実際の具体的な脆弱性の対応の手順ですね。脆弱性がありますよというアラートが出た時には、まずどこなのか、影響範囲があるのか、次にリスクの推定と評価をやって、それをちゃんと受容できるかどうか、リスクの確認をして、もし対応しなければいけないのであれば優先度付けもする。

深刻度を評価して、緊急性の判断もした上で対応をする。あと、ユーザーさんとかサプライヤーさんへの通知も必要ということで、このへんがけっこう具体的な脆弱性の話としてあります。

ちょうど初日に教えていただきましたが、2023年、こういった脆弱性のトリアージのお話とか対応の話が、また新しく実証実験として進んでいますので、次にこういったところの手順のお話とかが、情報が出てくるかと思いますので、お待ちください。

あとは、そもそも活用する際には、もともとの情報が誤っているとぜんぜん駄目なので、正しいのを出しましょうというところがあります。

渡邊：ここで篠原さんにうかがいたいところとしては、この2点目のポチのところになるかなと思います。やはりツールで脆弱性の管理をするとなると、工数が下がるのはうれしいので、さらにそのトリアージの部分とか、どれから先に対応すればいいのかを機械的にやってくれるとうれしいなと思うんですけれども。

そういったところも踏まえて、2023年の実証の内容でちょっとシェアできるような内容がもしもあれば教えていただけますか？

篠原：そうですね。2023年は、SBOMを活用して脆弱性のマッチングを行いつつ、脆弱性に対する対応の優先度付けを行っていけるような整理を行っています。

初日に経産省の飯塚さんから説明があったとおり、一部の内容については、経産省さんのホームページで、ソフトウェアに関するタスクフォースがありまして、そちらの中に資料が載っています。

やはり優先度付けをするにしても、SBOMがあって、どういった観点で優先度付けをするのかというところのプロセス、フローみたいなものがあると我々は考えているので、そういった優先度付けに向けたフローの中身を今整理しているところですね。

こちらについては、脆弱性の評価の指標として一番有名なのは、CVSSかなと考えているんですが、CVSSだけではなくて、もう少し脆弱性にリーチできるのかというところ、今話題のVEXという考えも、一部参考にしつつ、脆弱性の優先度付けを総合的に考えていければと認識しています。

2023年度、どこまでっていうのはあるんですけども、やはり脆弱性の優先付けに関する考え方を総論的に示していけても、分野ごとにその詳細な考え方は異なるかなという認識もしています。

ある種、ユースケースとかプラクティスではないですが、大本の考え方を示しつつ、分野に適用した場合にどういった留意点があるかというところも、将来的には考えていけるといいなと認識しています。

渡邊：なるほど、ありがとうございます。おもしろそうですね。やはりこういったところは、すごくセキュリティの専門知識みたいなものが要るのかなと思ったりもするんですが、フレームワークみたいなかたちで整理することによって、もうちょっと取り組みやすくなるのかなという印象があり、2023年の実証の結果もとても楽しみにしています。

そうですね。この、手動でやる時とSBOMツールでやる時で、脆弱性の管理もかなり自動化される部分が大きいので、ツールを使うことにメリットがありますよ、といったようなことも、実証の中では言われています。

渡邊：次のセクションが最後になるかと思います。SBOM情報の管理というところですね。実際にSBOMを作りました。それを関係者にも配布しました。それで終わりというわけではなくて、作ったSBOMもちゃんと保管しておいて、管理もしていきましょうねということが書かれています。例えば、社外からの問い合わせに対してというところもあるかと思いますが、適切に管理をしますというところですね。

ここに関しては、少なくとも作成したSBOMは、変更履歴も含めて一定期間保管をしましょう。保管の目安みたいなことも書かれていまして、例えば少なくともその対象製品を売っている間は保管をしておきましょうねとか、このあたりはちょっと、ライセンスの考え方も似ているのかもしれないので、参考にしてください。

出荷済みの製品とSBOMの情報を紐付けられるようにしておくというところで、例えば、型番みたいなものがあれば型番とSBOMとがセットで管理をしておくようになっているとよいかなと思います。

あとは、脆弱性の情報って日々更新されますので、SBOMのツールを自動で監視しておけば、新しい脆弱性があれば、それを即座に把握できます。

ここのところで最後に聞きたいのが、SBOMの管理体制のところです。篠原さん、今ここですと、SBOMの管理を会社の中でやっていく組織の例として、例えばPSIRTとか品質管理部門と書いてあるんですが、具体的に例えばどういった部署がやっているのが多いかとか、あとは、それに関する課題とか、なにかあれば教えていただけますか？

篠原：現状だとけっこうバラバラかなと考えていて、大企業ですと、PSIRTやそれに類する部門でやっている場合もあれば、個々のソフトウェアの担当者が個別に管理しているケースもあるかなと考えています。

やはり、実証の企業と話していた中だと、一番上に書いてあるPSIRTやそれに類する部門で、製品セキュリティに関する一環としてSBOMを管理していくのが効率的なのではないかなと考えているので。

ある種、目指すべき部分ではないですが、効率化のためには、そういったところの部署と連携して、部署が主体的になって管理していくのがよいかなと考えています。

渡邊：なるほど、わかりました。一方たぶん、SBOMを作るとなると、開発チームとか開発のエンジニアさんのパワーもきちんと必要だと思うので、エンジニアチームとPSIRTみたいな組織が連携しながらやっていくのが理想的なのかなと思いました。

渡邊：というところで、ここまでが実証の内容になっていまして、最後、付録は7章のところで、今までお話ししてきたような観点が、チェックリストというかたちで書いてあります。

ですので、これから取り組まれる方、これをチェックリスト的に活用して、それぞれのフェーズでどんなことをやってどういうことを確認して、実際にやったかどうかのチェックをつけながら使ってもらえればなと思います。

ここまでが手引書の内容というかたちになりまして、いったんここで、Q&Aのコーナーにいきたいと思います。

渡邊：ということで、ここからは順番に質問をピックアップしてお答えしていこうと思います。篠原さん、よろしくお願いします。

それでは1つ目ですが「経産省のSBOM実証では、SBOMフォーマットにSPDXを選択されていますが、ここでCycloneDXを採用されなかった理由を教えてください、よろしくお願いします」という質問です。こちらはいかがでしょうか？

篠原：その当時、SPDXがちょうど国際標準化をされまして、我々として、SPDXがけっこう標準になっていくんではないかと仮説を立てて（笑）、SPDXを選びました。

ただ、最近CycloneDXも、かなり活発に活動されていてバージョンアップも多いですし、逆に国際標準化することによってSPDXはアップデートしにくくなったっていう話もあって、今思うと、両方試しておくべきだったなとは思うんですけども（笑）、当時のそういった事情があってSPDXを選んで実証を行いました。

渡邊：はい、ありがとうございます。

渡邊：では、次の質問です。「ソフトウェアを購入する側のユーザー企業として、SBOMを運用するにあたって、最新化、新しいSBOMの入手のタイミングはどう考えればよいでしょうか？」という質問です。こちらはいかがでしょうか？

篠原：そうですね。タイミングについては、やはりソフトウェアのバージョンアップがなされた場合や、あとは今だとちょっと少ないと思うんですけども、バージョンアップがなされたタイミングでサプライヤーのほうからSBOMが提供されるというケースもあると思うので、そのタイミングでSBOM自体もバージョンアップする必要があるかなと考えています。

渡邊：なるほど、ありがとうございます。やはり対象物が変わった時には、またSBOMも更新するべきっていうところですね。

篠原：はい。

渡邊：ありがとうございます。

渡邊：次の質問です。「稼働後の脆弱性管理についてどのように行っていくべきでしょうか？　SBOMを作り完成させることはなんとかできると思いますが、その後、組み込まれたOSSなどの脆弱性を探知するいい方法はありますか？　常にアンテナを張っていないといけないかと思いますが、どのように脆弱性を感知しますか？」という質問です。こちらはいかがでしょうか？

篠原：これも、先ほど渡邊さんが資料で投映しましたが、脆弱性管理もツールでやったほうが効率的、というのが実証の1つの結果なので、方法論的にいうと、やはりツールを活用して、その後の脆弱性管理もしっかりやっていくのが効率的かなと考えています。

渡邊：なるほど、ありがとうございます。次の質問ですね。「サードパーティのSBOM提供を受けた場合、提供を受けた情報と作成した情報を明確に分けて管理することは、今のSBOMツールでできるのでしょうか？」というご質問です。こちらはいかがでしょうか？

篠原：これは、できると思うんですが逆に渡邊さんのほうが詳しくご存じな気がするんですけど（笑）、いかがですか？

渡邊：（笑）。そうですね。例えばツールによっては、そのツールが作ったものじゃない、別のところで作ったSBOMをインポートして管理できる機能っていうのも、最近けっこう入ってきています。

そのインポートしたものと、それから自分で作ったものとがどうなるかというと、例えばツール上だと、そのインポートしたSBOMの情報は、SBOMがその情報のもとになっていますよと表示されるようになっているので、実際にその環境で解析・スキャンして作った情報と外から持ってきた情報が、画面上は分けて表示できるようにはなっています。

だいたいどのSBOMツールでも、インポートの機能があるものに関してはそういった表示の違いがあるので、今のこの質問に関しては、イエスとお答えするのがいいかなと思います。ご質問ありがとうございます。

渡邊：では、次ですね。これ、ちょっとおもしろい質問なんですけど、「誤検知の再現性はあるんでしょうか？　同じ解析を複数回行っても検出結果は安定するのでしょうか？」というご質問です。

篠原：実証の中では、安定していたかなと思う一方で、いわゆるランタイムライブラリのような、実行環境に依存するライブラリが検出できなかったりっていうところもあったので、そういった意味だと、必ずしもずっと安定するとは言いきれないかなと思います。

渡邊：なるほど、そういうことですね。あとは、ツールを提供している側の話でいくと、ツールによっては1回解析して、誤検知でした。それをチューニング、正しい情報に修正するかたちで、違ったバーションで出ているものを新しいバージョンに書き換えた場合。

その次にまた同じものを解析すると、今度はちゃんとチューニングした後の正しい情報で出してくれるので、ツールの中でそういったチューニング、調整ができるようにはなっています。

そういう意味では、同じ環境で同じツールで同じことをやった時に、安定して同じ結果はたぶん出ると思いますし、あとそれをチューニングした結果も、以降の解析には反映されます。

渡邊：では、次ですね。「OSSなど無償のツールでSBOMを生成する場合、NTIAの最小構成を満たさないSBOM出力になってしまう場合があり、困っています。どのような改善アプローチが考えられますでしょうか？」という質問です。

篠原：これはツールによるかなと思うんですが、ツール自体がNTIAが指定している最小要素のデータフィールドを出力できない場合には、そのツールを使っていても最小要素を満たさないかたちになるので、別のツールを使うのがよいかなと思います。

一方で、我々も実証で悩んだ部分で、設定云々によっては実は出力できるところが多々あると思うので、そういったところは調べてもらう、ドキュメントを見てもらうのが必要かなと思います。

それでもちょっとわからないっていう場合には、代理店というか、そういったSBOMに関するコンサルティングをやっている会社などに聞いてもらうのがよいかなと考えています。

渡邊：なるほど、ありがとうございます。そういうことですね。今はけっこうこのNTIAさんの最小構成が1つの指標になっているので、それを満たすものが作りたいとなった時、隠れ設定みたいなものがあったりするかとか、知っている人に聞くっていうのも、けっこう実はいいアプローチかなと思います。

渡邊：次、これもちょっとおもしろい質問なんですが、「SBOMの改ざんについては、SBOMのハッシュ値を共有するというのでは駄目なんでしょうか？」と。「なんで、電子署名とかブロックチェーンとかが要るんですか？」っていうご質問なのかなと思うんですけど、これはいかがでしょうか？

篠原：これ、たぶんSBOM自体のハッシュ値っていうことだと思うんですけども、それを用いて共有する、改ざん防止にそれを使うっていうのも一案かなと思っています。

ブロックチェーンとかの話が出ているのって、やはりサプライチェーン構造がかなり複雑で、サプライチェーン構造全体でSBOMを共有する時は、そういったスケールメリットがあるようなかたちでやり取りをする必要があるので、ある種、壮大なビジョンとして分散型台帳を用いたSBOM共有がビジョンとして語られているような状況ではありますね。

なので、駄目というわけではないかなと考えています。

渡邊：なるほど、ありがとうございます。1対1のやり取りだと、たぶんそれでぜんぜん大丈夫っていうのもあったりするかなと思うんですけど、1対1対さらにその先っていうような感じの長いサプライチェーンというか受け渡しになってくる時には、例えば間で変えられていないかとか、そういった意味でもブロックチェーンを使うといいかなと理解しました。

渡邊：次の質問ですね。「多くの有償ツールでも、OSSのEOLは自動識別できない認識なのですが、OSSのEOLを自動で判別できるツールがあれば教えてください」という質問です。これはどっちかというと私がお答えする感じの質問ですかね（笑）？

篠原：そうですね。

渡邊：はい、ありがとうございます。ご認識のとおりOSSのEOLって難しいんですよ、正直なところ。EOLの表示の仕方っていうのがきちんとフォーマットが決まっていなくて、それぞれのコミュニティさんでぜんぜん違うかたちで情報を出してきたりするし、あと、EOLになっていても、脆弱性対応とかでいきなりそれが撤回されて、パッチを出して、というようなこともあったりするので。

膨大にあるOSSの情報を機械的に収集して、EOLの情報を抽出して、それをユーザーさんにお知らせするのは、かなり情報の揺れがありすぎて難しいというものなので。

今少なくとも私の知る限りで、EOLの情報を完璧に自動で判別できてその情報をお伝えできるツールは、市場には存在していない認識です。

ではどうするかというと、自分が使っている特定のOSSについて、例えばもう決めて、それを調べてくれるような感じのサービスとか、それを決めて、そのかたちに沿って情報をどんどん自動で収集するようなアプローチはできるかと思うんですけど、広く一般、全部のOSSについてEOLを識別するのは、今現在難しいです、というのが答えです。

渡邊：それでは、次ですね。こちらもいい質問ですね。「本日は、ご説明ありがとうございました。ツール選定の観点や生成・共有方法などが大変よくわかりました。ツールを使用してSBOMを出力したことがあるのですが、各フィールドの項目がNO ASSERTIONばかりでした。このあたりを手動で対応する必要があると思うのですが、なにかコツがあれば教えてください」という質問です。こちらはいかがでしょうか？

篠原：そうですね。コツというよりかは、さまざまなアプローチがあるかなと思っていて、1つは、やはりログの出力結果とかを見て、なぜNO ASSERTIONになっているのかを確認するのが一番いいかなと思っています。

もしそれが誤りの場合には、ツールの設定をあらためて見てもらって、きちんとした設定や、きちんとした環境でSBOMが生成されているのかを確認する必要があるかなと考えています。

渡邊：なるほど。

篠原：これは、ツールに依存する部分なので、このNO ASSERTIONがどういった背景で出ているのかは、そのツールによるかと思います。

先ほど渡邊さんが紹介した解析方法も大きく関わってくるので、解析方法を確認した上で、もう一度レビューしてもらうのも1つの手かなと考えています。

渡邊：なるほど、ありがとうございます。

渡邊：あとはもう1つぐらい時間的にもお答えできるかなと思うので。これ、いきましょうかね。「脆弱性の把握も考慮する場合、内包コンポーネントをどの程度まで洗い出すかは重要な課題と思いますが、そのあたりの指針があれば教えてください」。いわゆる、入れ子構造になっているやつの再帰的な利用部品のところですね。

「逆にSBOMツールでは、1つ、2つのファイルだけがマッチしたコンポーネントも内包コンポーネントとして候補が表示されてしまって、そのコンポーネントの脆弱性情報を自分には関係ないものが表示されてしまうといった不具合もあり困っています」というご質問です。こちらはいかがでしょうか？

篠原：現状だと明確な指針がないかなと思っていますし、SBOMの深さの問題は、かなり国際的にも議論になっているところです。

一方で、EUではサイバーレジリエンス法の草案が発表されていて、あれだと、トップディペンデンス、最上位のコンポーネントについて洗い出すところが規定されて、それがいずれ法律になる可能性が高いです。

そういった法律で求められると、まず少なくとも最上位のコンポーネントが、自ずと決まってくるのかなと考えています。

渡邊：なるほど、ありがとうございます。けっこう、そうなんですよね。ただ、下側のコンポーネントらへんにLog4jとかが入っていたりするという問題もあったりするので、けっこう難しい問題ですね。深さのところはまだ検討中というところで、今後、いろいろな情報をまた気にする必要があるということですね。

ちょっとまだまだお答えできていない質問をたくさんお寄せいただいているんですけれども、ちょっと時間の関係でここまでとさせていただきます。申し訳ないです。

では最後に、ぜひ締めというかたちで篠原さんに一言、みなさんに対して、産業界のみなさんにメッセージというかたちになるかと思いますが、一言いただけますでしょうか？お願いします。

篠原：はい。あらためまして、みなさん、お忙しいところ参加いただきましてありがとうございます。昨日お話ししたんですけれども、我々が、経産省さんの事業に参画していた当初は、SBOMが何なのかが知れ渡ったぐらいで、今日ご質問を受けていると、かなり具体的な質問が増えてきたなと考えているので、SBOMの浸透度がさらに高まったかなと考えています。そこで、手引がみなさんの一助になれば非常に幸いだなと思っていますので、使っていただけると非常にありがたいです。

その一方で、このSBOMの分野ですとかソフトウェアサプライチェーンの分野は、かなり進化が早いといいますか、いろいろ変わっている状況かなと考えているので、適宜アップデートしつつ、また内容についていろいろご指摘とかもあるかなと思うので、そういった忌憚なきご意見はぜひいただけると幸いです。

本日あらためて、お忙しいところご参加いただきましてありがとうございます。

渡邊：本日はご講演ありがとうございました。いろいろなお話を聞かせていただいて、私も楽しかったです。それでは以上で講演者の三菱総研の篠原さまに、ご登壇ありがとうございましたということで、締めたいと思います。どうもありがとうございました。

篠原：ありがとうございました。