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

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

渡邊：4章ですね。環境構築と体制整備フェーズにおける実施事項と、認識しておくべきポイントです。まず一番初めがSBOMの適用範囲の明確化というところで、これは手引き書もこういった構成になっていて、実際にこのフェーズでやるべき事柄と、それによって認識しておくべきポイントがまとまっています。

文言的にはサマライズしてあるので少し短くなっているかもしれないんですが、項目の数としては揃えてあります。例えば対象のものを明確にしましょうとか、正確な構成図を作ってみましょうとか、契約形態を確認しましょう、SBOMの規制とか要求事項とかを確認しましょう、組織内の制約を確認しましょう。そして5W1H、SBOMの適用範囲を明確にしましょう、こういったことが書かれています。

補足の情報としていくつかありますが、例えば対象ソフトウェアに関する情報の整理というところで、例えば何かこの製品に関してSBOMを作ろうとなった時に、そのソフトウェアが例えばどういう言語で書かれているとか、どういうコンポーネントだよとか、そういったことを確認しましょうというものがあります。

ここもちょっと篠原さんに聞きたいなと思うところなんですが、けっこういっぱいこういう項目がありまして、これは全部把握しないといけないんですか？例えばこの動作環境とかは本当に関係あるの？みたいな。SBOMを作るのに関係あるの？みたいなところもちょっとご意見としてはあったりするかもしれないんですが、このあたりの情報の整理、例えば絶対にここだけは…みたいなところとか、これはまぁ別にいいかなとかですね。

逆にここの項目をわかっていくとこういうメリットがあるよとか、なんかそういったところってあったりしますか？ふんわりとした質問で申し訳ないです。

篠原：まぁ、備考のところに書いていただいているとおり、開発言語とコンポーネントの形態というところは最低限把握することが必要かなと考えています。手引きの中でも書いているんですけれども、その下にある構成を可視化することが特に重要かなと考えているので、そういった開発言語とコンポーネントの形態を整理しつつ、ソフトウェアの構成を可視化できれば、他の情報はある種オプショナルになるかなというふうには考えています。

ただ、そのオプション情報うんぬんによって利用できるSBOMツールが変わってくるので、やはりこういった情報が整理できるのであれば整理するに越したことはないかなと考えています。

渡邊：なるほど。例えばそのツールのサポートしている対象の環境とか言語とか、そういったものを見極めるために、というところですか？

篠原：そうですね。あとはその開発環境ツールとか構成管理ツールがうまく連携できるようにするSBOMツールもあるので、そういったものが連携できるのであれば効率的だと思いますし、そういったところでうまく情報を扱えるかなと考えています。

渡邊：なるほど。例えばですが、何かツールが脆弱性の情報を引き当ててきた時に、それが例えば「JIRA」でチケット化される、といったところの連携ができるといいよねとか、そういう目的で他のツールとかとの親和性も確認するといいよね、というお話なわけですね。

篠原：そうですね。

渡邊：そこは大事ですね。開発者にあまり負担がなく、かつそのSBOMを使うことによるメリットが開発者にもないと、うまくいかないところもあるので、そういう意味では既存のプロセスとか環境にピタッとはまるようなものを選ぶ。そういった意味でもいろいろな情報を整理しておくべきなのかなと理解しました。

渡邊：あとはこちらが実証の中で例として挙げている、歯科用CTのシステム構成図なんですが。この適用範囲を明確にしましょうという項目で、例えばこんなふうに整理をしますという例の図です。

けっこうこれが詳細な図なので「あれ、こんなに詳しくやらなきゃいけないのかな？」と心配になる方もいるんじゃないかなと思うんですけれども。篠原さん、これはシステム構成図を作ることで例えば何がわかるのかとか、どんな役に立つのかをあらためて教えていただけますか？

篠原：そうですね。これを作るメリットというのはけっこうあるかなと思っていて、当然作るのは大変なんですけれども。まず実証で一番思ったのは、どこにそのSBOMを適用するのかというのは、けっこう空中戦になってしまって、関係者の中で「ここはSBOMを適用するの？　適用しないの？」というところで、こういったのがないとなんかフワッとした議論になってしまって、結局そのSBOMのメリットを享受できないことにつながるかなという懸念があると考えています。

さらに言うと、最終的にそのSBOMを適用してリスク管理や脆弱性の管理を行っていくんですが、こういったところが整理されていないと、そのリスク管理の漏れがあって、結果的にそこを起点に何か攻撃の影響を受けるということも無きにしも非ずなので、効率性という観点や関係者の間で、共通言語的に使うこともあります。

最終的にSBOMを作ったあとにその適用範囲が妥当か、きちんとリスク管理ができているかというところのリスク低減効果という意味でも、かなり効果が大きいかなと考えています。

渡邊：なるほど。例えば「うちの製品のSBOMを作りましょう」となった時にも、独自開発部分だけのことを言っている人もいれば、フレームワークとかを全部含めた部分のことを言っている人もいたりして、ちょっと認識のズレみたいなものを解消する意味でもこういった構成図があると空中戦にならずに済むということですね。

あとは実証の時にこの図を作られた方がいて、これを作るのはすごく大変だったなというのを肌感覚で思っていたんですけれども（笑）。やはりここまで詳細なものが必要なんですかね？

篠原：んー（笑）。まぁ、あるに越したことはないかなと思っています。私も実際に協力いただいた会社さんに作っていただいて、かなり時間をかけて作った部分ではあるんですが。これが作られたことによって先ほど申し上げたとおり、共通理解が進んだというところにはなるので、可能な限り、SBOMを適用する範囲のコンポーネントが明らかになったこういった構成図があると、みなさまの導入がしやすいのかなとは考えています。

渡邊：例えば自社開発のこのCT撮影ソフトというのがあったりしますが、ここについてのSBOMを今回は作りましょうとか、そんな感じでこの塊ごとにSBOMを作っていくような感じのイメージかなと思っています。

一方でこの図の中の青い部分。例えばA社開発とか、B社開発、あとはサードパーティ製みたいなことが書いてある四角があります。こういうところの、実は自分たちの会社じゃないところが作っているモジュールとか製品のSBOMは、どうすればいいんでしょうか？

篠原：そうですね。それは理想的な世界を言うと、そのコンポーネントを使った方がSBOMを作って、それをうまくサプライチェーン上で共有するところが望ましいです。けれどもなかなか今は、足元ではそうなっていなくて、それに達するにはけっこう時間がかかるかなと考えています。

そういった意味で、今回の実証の中でも関係者というか、A社さん、B社さんですとか、サードパーティが作ったソフトウェアについても、まずは実証に協力いただいた方で、外部でSBOMを作るところを実施していました。現状はまだSBOMがある種黎明期というところもあり、そういった対応をするしかないかなと考えています。

渡邊：なるほど。そういうことですね。やはりSBOMをもらえる・もらえない問題もあったりすると思うんですよね。いただけない時に、じゃあどうするかというのとかも、またあとから出てくる取引慣行の話とかもあったりしますが、やはりこういった手引きがあることによって、やるべき話だよとか、お互いにメリットがありますよみたいなことも理解しながら協力していただける世界になるといいなと思いますね。

渡邊：あとは取引慣行のお話ですね。こちらは契約形態とか取引慣行の情報の整理もしましょうということが書かれています。例えば契約形態として委託して作っているものであれば、その情報をたくさんいただけるようになっているかもしれませんし、逆に買ってきたものとかだと契約形態によっては情報を出してもらえないこともあります、という時にどうしますか？　というお話です。

あとはちょっとポイントになるのが、この部分。改変の有無かなと思っていまして、例えばサードパーティから提供されたソフトウェアをそのままAs Isで使用している場合であれば、そのサードパーティさんからもらったSBOMはそのまま使えます。けれどもそうじゃなくて、自分たちが改変しているとなった場合には、もらったSBOMはそのままでは使えないということになってくるので、「じゃあ、どうしようか」と。そういった議論にもなってくるかなと思います。

あとこれですね。4.1のSBOM適用範囲の明確化というところで、5W1H。観点と、それから実際の適用項目、検討項目、選択肢。こういったものが書いてありますけれども、これに従って、どんなSBOMを作って、どんなふうに管理をしたいのか。あとは自分たちの環境は何なのか。そういったことを踏まえて整理をしながら、SBOMの適用範囲について考えていきます。

ここで整理した内容が、また次のフェーズで活きてくるというところになるかと思います。あと4.1で書かれているのは、規制と要求事項の確認ということで、例えばアメリカのお話、あとはEUのサイバー・レジリエンス・アクト、医療機器分野のガイダンス。こういったものに関していろいろ要求事項が出ていますので、こういったところに関しても、随時情報収集をして要求事項を整理しておく必要があると書かれています。

渡邊：次の4.2というセクションは、SBOMツールの選定についてです。ここは先ほど整理した内容によって、ちゃんとしたツールを選んでいきましょうという内容です。

例えば先ほど費用対効果みたいな話も出ましたが、やはり1つの製品にたくさんのモジュール、たくさんのコンポーネントが使われているケースがあるので、手動で全部を管理しようと思うとなかなか難しいので、ツールを使ったSBOMの作成とか管理を行うことが現実的です。手動でやるのはけっこう難しいというようなことが手引き書の中にも書いてあって、手引き書のほうでは例えば脆弱性の管理とか、SBOMの作成みたいなところもツールを活用した前提の記載になっています。

なので明日は、このSBOMのツールの選定の部分から見ていきます。ポイントとしてはいろいろありまして、例えば複数のツールの使い分けはやはりちょっと難しいよねとか、1個に決めたほうがいいんじゃないかみたいなお話があったりとか。今は無償のツールがたくさん出ていますので、無償ツールだとちょっと勉強が難しいなみたいなところがあったりします。

では、今日はここまでにして、続きはまた明日見ていきたいと思います。このあとは、今までお話ししてきた内容についての質問タイムになります。

渡邊：それではお待ちかねの質問タイムです。たくさんご質問をありがとうございます。では順番にお答えしていきたいと思います。

1個目ですね。「『既知の未知』とはどのような運用でしょうか？　脆弱性があるかもしれないということに対して、脆弱性の監視を行うということでしょうか？」と。ちょっともうなんか既知の未知というのはそもそも何のことだという状態なんですけど、英語だとknown unknownかな？日本語にすると既知の未知となります。これについて教えていただけますか？

篠原：はい。SBOMの最小要素でNTIAが出している最小要素にあった用語ではあるんですが、known unknownというところで、「わからないことをわかっているのであれば、それをきちんと明記してね」という意味です。ご質問いただいたとおり、脆弱性があるかもしれないという時に、その「あるかもしれない」という状態に留めていくわけではなくて、「あるかもしれない」ということをきちんとSBOMなりに記載しておくというところが、最小要素として含まれています。

対象は脆弱性だけではなくて、例えば依存関係がわからないというところもわかっていれば、それは既知の未知というところで管理してね、というところがNTIAの文書でも推奨されています。

渡邊：なるほど。少なくとも「ここまでは絶対に明らかですよ、この先はちょっとわからなかったです」という、その境界線をはっきりしましょうということですかね。

篠原：そうですね。

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

渡邊：では次の質問です。「Microsoft社が『GitHub』上で提供しているSBOM作成ツールを使ったことがあります。この時にソフトウェアコンポーネントごとにUIDが振られていました。このUIDは全世界で共通の一意性を持っている値なのでしょうか？　その他のSBOM作成ツールでも一意性のあるUIDが用いられているのでしょうか？」という質問です。お願いします。

篠原：はい。一意のIDが付与されてはいますが、それが全世界で共通かというと、それがまた悩ましいところで、かつ2023年の実証として取り組んでいる部分でもあります。多くのSBOMツールは、先ほども話に出たPURL、Package URLというところで脆弱性のIDが付与されていますが、一方で米国のNVD、National Vulnerability Databaseとかは、ほとんどCPEというIDを付与していて、そこの相手のマッチングがなかなか取りづらいと。

言い換えると、質問にちょっと戻ると、ID自体は共通の一意性を持っているが、全世界でそれが広く使われているという状態にはまだ達していないような状況かなと考えています。

渡邊：次の質問もちょっと今のお話に関連しているので、ここも一緒にお答えいただきたいんですが。「NTIAの最小要件にあるデータフィールドの多くは、どのようなデータが入るかだいたいイメージが湧くのですが、それでも識別子というものだけが具体的なデータのイメージが湧きません。識別子というのはどのようなデータで、誰が決めるのでしょうか？　教えていただけると幸いです」という質問です。これも先ほどちょっと出ましたが、やはりPURLとかそういったところとかがイメージされますかね？

篠原：そうですね。イメージはそれに近いかなと思います。ただ、NTIAの最小要素では「それにしなければならない」とは書いていないので、誰が決めるかというとSBOMの作成者が決めるかたちにはなります。最終的な脆弱性の管理とかを考えると、そういったPackage URLですとかCPEというような、いわゆるその部品のIDを付与すると良いかなと考えています。

渡邊：なるほど。やはりここは次に何をしたいかというところも関係すると思うんですよね。SBOM作成の目的が、例えば脆弱性の管理ということであれば、やはりその特定したコンポーネントを脆弱性の引き当てに使えたほうがよくて、やはりNVDとかで使われているような、CPEの識別子とかを使ってみたりとか。そういった、その次に何をしたいかという話で考えるのもいいのかなと思っています。

渡邊：では次の質問です。これはけっこうみなさんが聞きたいところだと思うんですが。「SBOMのレビュー手法としてはどのようなものをお考えでしょうか？　ざっくりとでもいいので、おうかがいしたいです」というところ。先ほどツールが100点取れませんよというところに関連した質問なのかなと思うんですが。レビューのやり方ですね。お願いします。

篠原：そうですね。本当にざっくりと申し上げてしまうと、人の目で見るしか現状はないかなと思っています。一方で実証の中で明らかになったレビューのポイントというか観点は何点かその手引きの中にも書いていますし、どことどう比べることでそのレビューを行うかについても手引きに書いています。

これはもしかしたらメインは明日のテーマかもしれませんが、そういったSBOMを作って、解析してどうするのかを明日お話できればなと考えています。

渡邊：はい、ありがとうございます。ご質問いただいた方、明日もぜひ聞いてください（笑）。お願いします。では次の質問です。「ソースコードは構成管理ツールで管理していると思いますが、構成管理ツールからソースコードのリストを出力することで、コンポーネントを特定できませんか？」という質問です。

篠原：構成管理ツールと連携している場合にはコンポーネントを特定できるので、SBOMを効率的に作れると考えています。一方で、たとえば最初に渡邊さんがおっしゃっていた自動車業界だと、ソースコードの授受はなくてバイナリファイルだけ送ってもらうとなると、それでSBOMを作るというケースもありますので、バイナリファイルに関する解析を行う必要性が出てくるかなと考えています。

言い換えると、完全に構成管理ツールだけでSBOMを作れる状況は、けっこう稀有な状況かなと考えています。

渡邊：なるほど。最近はGitHubからもSBOMを出力できる機能があったりしますし、例えばそんな感じのイメージでもいいのかなとは思いつつも、やはり例えばそこに全部のソースコードがあるかどうかとか、そこに十分な情報があるかどうかみたいなところで、特定できる情報の粒度とか正確性も変わってくるところもあったりします。それも明日のテーマですかね？

篠原：そうですね（笑）。

渡邊：明日を楽しみになさってください（笑）。

渡邊：では次ですね。「SBOMのフォーマットが複数あるとのことですが、統一化の動きのようなものはあるのでしょうか？」。これはけっこう気になる質問ですよね。お願いします。

篠原：個人的な意見を申し上げると統一化すべきだなとは思いますが、統一化の動きは少なくとも今はないかなと考えていますね。このSBOMの発案者である米国のアラン・フリードマン博士という方がいますが、その方もCycloneDXとかSPDXがそれぞれのコミュニティで発達しているので、そこの競争というか統一というところは、民間に任せているというような意見もあったので、なかなか政府として統一化する動きは、そこに動き出すというのはなかなか難しいかなというふうには考えています。

ただ、統一化したほうが絶対に事業者さんとしてはいいのではないかなとは思います。ある種の宗教論争ではないですが、そういったところで1つにまとまるというのは、なかなか難しいのかなと考えています。

渡邊：なるほど。そうですよね。これも明日出てくるお話にはなりますが、やはりフォーマットが複数あると、できるだけその両方に対応したツールが必要になるというところもあり、そこがなかなか難しいというのもあるので。

やはり統一してほしいなという思いはありつつも、ただそれぞれのフォーマットがとても実績があって、それがよく考えられていて、やはりそこにすごく特徴だったりとか重要な要素もあったりするので、それがすごくいいかたちで1個になるのかなとも思いつつ、それがあまりイメージできないというところがちょっとあるのかなと思います。

あとは先ほどご紹介したもので、SPDXとかCycloneDX、SWIDという、少なくとも2021年頃の推奨フォーマットというのが3種類ありました。けれども、なんかここに来てけっこういろいろと、先ほどのドイツでライセンスを入れてくれみたいな話とかがあったり、また新しいことを考えている団体さんとかがあったりとか。例えばSPDXも次のバージョン3.0を検討中だったり。CycloneDXも最近新しいバージョンが出ましたけれども、それぞれのフォーマットがどんどん良い方向に改善、更新されていくようになるかなと思っています。

なので統一化というよりは、どれにも対応できるようにということになってきてしまうのかなとも思ったりします。

渡邊：では次の質問です。これはちょっと難しい質問なんですけれども、「BOMとしてはSBOM以外に、例えばMBOMですとかEBOMですとか、いろんなものが存在しますね。SBOMは件数、更新頻度などの面で他のBOM以上に継続的な管理が難しい領域で、その解はまだ手探り状態と捉えています。

SBOMの管理は他のBOMとの管理の違いは何で、その管理の難しさは何で、それをいかに解決していくのかを各企業・現場でいかに取り組んでいけばいいのかを現時点のヒントをいただければ幸いです」ということです。

例えばハードのものですと、作って出荷した時の状態が表現されているBOMはそうそう変わらないですが、一方でソフトウェアはどんどんアップデートをしていくのが最近の主流ですので、そうするとやはりどんどんSBOMの内容も変わっていかなくちゃいけなくなってしまったりすると。そういう感じで他のBOMとの違いというのもあったりするのかなと思います。

なかなか解決方法というのも難しいかもしれないですけど、篠原さんは、管理の難しさについてお考えがありますか？

篠原：そうですね。他のBOMとの違いについては、今渡邊さんがおっしゃっていただいたとおりで、やはりSBOMだとソフトウェアが動的に変わるので、継続的にそのSBOMをアップデートしなければいけないところが一番大きいかなと考えています。手引きの中にも、SBOMは作って終わりではなくて、それを作っていかにそれを脆弱性の管理とか、あとはそのSBOM自体をいかに管理していくかにもフォーカスを当てているので、その管理の違いというところ。

かつどういったふうに取り組んでいくべきかという部分については、きちんとその脆弱性の管理ですとか、ライセンス管理というところの目的に対して、どういったSBOMを作っていくかを意識する必要があると考えています。方法論の面で言うと、やはりその実証で気づいた部分としては、SBOMツールを使って管理していくのが非常に効率的。

手動でいろいろ管理していくというのはかなり大変なので、SBOMツールを使って管理をしていくところが一番最短の管理策になるというところが、まさに現時点でのヒントになるかなと考えています。

渡邊：次のご質問は、どちらかというと体制面のお話になるのかもしれないんですが、質問を読み上げます。「SBOMのツール選定やルールの策定、現場運用への適用が結局技術者任せにされてしまって、実業務のついでといったような取り組みにならないかを危惧しています。SBOMの運用が軌道に乗るまでは専任者を設けるべきでしょうか？」という質問です。こちらはいかがでしょうか？

篠原：なかなかその企業の規模や、対象のソフトウェアによって違うので、一概には言えないところではありますが、個人的にはその専任者を設けるところまではちょっと行き過ぎというか、コストがかかってしまうかなと考えていますね。個人的には、脆弱性管理ですとかライセンス管理を目的とした1つのツールがSBOMだと考えています。

なので、あくまでその観点でいうと、可能な限りコストは低いほうがいいかなと考えているので、いかにそのツールを効率的に作っていくのか、使っていくのかを意識すると、既存のリソースですとか、それも人だけではなくて文書などを活用しつつ、例えばそのPSIRTの中で管理していったり、もう少し効率的なやり方があるのではないかなと考えていますね。

ちょっとごめんなさい。ご質問者の企業の規模などがわからず回答しているところではありますが、個人的な意見としてはそういったところです。

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

渡邊：時間的にたぶんこれが最後のご質問になるかと思います。読み上げます。「ご説明ありがとうございました。OSSのライセンス要求にある著作権者情報、ライセンス情報のソフトウェア頒布先への伝達とSBOM提供は別物と考えるべきか、SBOM提供でも上記を満足できると考えて良いのかで迷っています。

手引き書ではそのあたりに触れていますでしょうか？　お二人の私見でもけっこうですので、ご意見をお聞かせください」というところです。ライセンスのお話ですね。こちらはいかがでしょうか？

篠原：そうですね。手引き書の中ではちょっとまだ触れられていないというところでして、こういった契約とか著作権の部分はまさに重要性が高まっているので、今後のその改訂の中である種の契約モデルではないですが、契約におけるSBOMの取り扱いというところが、いろいろと契約形態によって変わってきたり、OSSであってもどう使うのかが変わってくるので、そういったところでは整理が必要だよね、というところは経産省とも議論しているところです。

渡邊：私の個人的な考えは、やはりライセンスの話はSBOMと一緒にやってほしいなというのがあるかな。本当に私的な意見ですけれども。いろんなドキュメントを作ったりするのも、たぶんエンジニアの方とかも面倒くさくてやりたくないと思うんですよね。情報をもらった側も、煩雑になってしまうと思います。

せっかくSBOMの中にライセンスを書くフィールドもありますし、ソフトウェアとSBOMが一体となってサプライチェーンを流通していくうことを今みんなで目指しているので、ぜひその仕組みの中にライセンスの話も乗せていただいて、SBOMの中にライセンスの情報も入った状態で一体となって流通していくかたちを目指したいなと思っていますし、そうったかたちに私としては誘導と言いますか、議論もしていきたいなと考えています。

以上です。たくさんのご質問ありがとうございました。残念ながら、すべてをカバーしきれなかったので大変申し訳ないところではありますが、今日はすごく具体的なご質問が多いなという印象がありまして、実際にみなさん取り組んでいるのかな？　と思いつつ、また実務のところでお悩みなんかもあるんだろうなと思ったりします。

なので、今後の実証のお話ですとか、明日のお話の中でそのあたりをクリアにしていけたらなと考えています。どうもありがとうございます。それではここまでが本日のアジェンダになります。篠原さま、ご講演ありがとうございました。

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

渡邊：また明日もよろしくお願いいたします。

篠原：はい、よろしくお願いいたします。