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

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

渡邊歩（以下、渡邊）：昨日ご参加いただいた方はだいたい資料のイメージなんかもわかっているかもしれませんが、こちらの資料は、経産省の「ソフトウェア管理に向けたSBOMの導入に関する手引」の概要ということで、内容をサマライズして、さらにそこに少しだけ補足を加えたものです。それを見ながらお話をしていきます。今映しているのが、この手引書の目次です。

1章から7章までの構成になっていて、昨日は少し振り返りも兼ねて1章から4章の途中までをお話しして、今日は続きからですね。4章の後半、それから5章、6章と進めていきたいと思います

昨日のお話の中で、Q&Aで質問していただいていた方がいたんですが、ちょっとそこだけ補足したほうがいいかなと思ったので、まずは補足から入ります。

どういう内容かといいますと、昨日このSBOMの最小要素のページで、NTIAが定める最小要素の構成の話をしていたところで、データフィールドの中のその他の一意な識別子、この識別子の話をしていた時に「こういう識別子も使ったほうがいいと思っています」みたいなお話をしたんですが、「その時に言っていた識別子って何ですか？」というご質問をいただいていました。

確かに口頭でしかお話ししていなかったので、ちょっとわかりづらかったかなと思いますので、そこだけ補足します。

あの時私は、「CPEがあったらいいな」みたいなお話をしたかと思うのですが、そのCPEと言われるのは、この共通プラットフォーム一覧「Common Platform Enumeration」、CPEというもの。

これがいわゆる例えば、なにかハードウェアやソフトウェアなど、コンポーネントを識別するための共通のIDというか識別子です。この「CPE」のお話をしました。

もう1点、篠原さんからその時に「PURL、Package URLも使いますね」というお話もあったかと思いまして、この識別情報にCPEやPURLといったものを使うと、脆弱性の紐付けにすごく便利だよというお話をしました。

脆弱性の紐付けに何が便利かというと、ここの図ですが、SBOMの中では、コンポーネントは名称とバージョンという文字列で管理をするんですね。例えば「Apache Log4jのバージョン2.4.1」というかたちで、SBOMの中には書かれています。

一方、例えば脆弱性を調べるにあたって、このNVDと呼ばれる脆弱性のデータベースが使われることが一般的かと思うのですが、こういったデータベースの中では脆弱性にもIDが振られています。

例えばNVDというデータベースの中では、CVEのなんとかかんとかという識別子が振られています。そうすると、SBOMから脆弱性情報を紐付けしたいなと思った時には、この文字列情報からこの脆弱性のIDを紐付けしなければいけないんですね。

この右側に載っているのが、NVDの実際の内容ですが、じゃあ、このNVDってどんなかたちになっているかというと、例えば、このIDの脆弱性であれば、この赤字で囲ってあるところに「こういうコンポーネントの脆弱性ですよ」という説明があるわけなんですね。

そうすると、ここを見ていただくと、「Apache Log4jのバージョンのいくつからいくつまで」というように、こちらもやはり文字列情報になっていて、例えば、これとそれからこの内容を機械的に紐付けようと思うと、なかなか難しさが出てくるというわけです。

何が難しいかというと、例えば「Apache」の「A」が大文字小文字が違っていたらもう引き当てられないとか、そういった名寄せ問題であったり、文字の表記揺れみたいなものもあったりします。

例えばエンジニアは、Log4jっていう名前で呼んでいたりすると、SBOMにもLog4jと書いてしまうケースもあります。そうするともう、例えばこれと機械的に紐付けができなかったりするので、これをダイレクトにつなぐのが難しくなります。

その間をつなぐ役割をするのがCPEの識別子と言われているもので、これもまた長い識別子なんですが、このNVDの情報にこういった識別子を持っていまして、これで一意にコンポーネントとバージョンを紐付けることができます。この識別子をかませてあげることによって、機械的にSBOMの内容と、それから脆弱性の情報がマッピングできるようになる構成です。

ということで、例えばSBOMにこの名前だけじゃなくてこの識別子まで書いてあったら、ここの紐付けがすぐに機械的にできるという簡単さとか、あとは、正確に紐付けられるという正確性とか、そういったメリットがあります。

ということで、例えばこの一意の識別子のところには、先ほどのCPEとかPackage URLみたいな情報が書いてあると、脆弱性の管理にはすごく便利ですよね、というようなお話をしました。

ここまでが、昨日の補足です。ご質問いただいた方、ありがとうございます。今ので回答になっているとよいのですが。

渡邊：それでは、続きにいきたいと思います。このページは、再度の掲載ですが、導入の手引の中では、SBOMの導入プロセスということで、それぞれフェーズを切ってあります。それぞれのフェーズの中でどういったステップのことをやっていくのか、その時の注意事項は何なのかが詳細に書かれているのが、この手引書の中身です。

昨日はSBOMツールの選定、このあたりまでいったかなと思いますので、この続きから今日はいきたいと思います。

まず昨日の4.2のところでは、実際にSBOMのツールの選定のところでこういった選定のやり方がありますよ、というお話をしました。

そもそもこのツールを使わなきゃいけないのかという話ですが、もちろん、SBOMを作成する時は、手動で作ることもできますし、「Excel」とか「スプレッドシート」のようなものに、わかっている内容を書き込むのでもSBOMは作成できます。

ただ、さすがに何百、何千使われているコンポーネントの内容を手書きでSBOMのかたちに表現していくのはなかなか難しいよね、ということもありまして、ツールを用いたSBOMの作成とか管理を行うことが現実的だろう、というようなことで、手引書の中でもSBOMツールの活用を前提とした記載になっています。

ということで、ステップとしてもSBOMのツールを選んで、ツールを導入して、というかたちです。

SBOMツールには有償も無償もあり、このスライドでは、有償のSBOMツールのメリット・デメリット、無償のSBOMツールのメリット・デメリットということが表現されています。

この下、ちょっと字が小さいのでなかなか読みづらいかなと思いますが、こちらは有償ツールの例、それから無償ツールの例ということで。

実際、手引書の中にもきちんと説明付きで、7章にこの有償ツールとか無償ツール、SBOMツールの代表的なものの例が挙げられていますので、もし有償ツールを使いたい、それから無償ツールを使いたいならば、手引書の7章のところを見ていただいて、それぞれ具体的にどんなものなのかというところを学んでください。

簡単にですが、有償ツールのメリットとしては、使いやすいというところがあります。UIとか機能も充実していたり、サポートもあります。ただ、ライセンス費用がかかりまして、モノによってはけっこう高額になるので、お金の問題が発生するのが有償ツールのデメリット。

それに対して無償のツールは、やはりライセンス費用がかからなくて、購入の手続きとかが不要なので、すぐに導入できるというところで、導入がしやすいところです。あとは、スモールスタート、お試しで使ってみることがやりやすいのが無償のツール。

一方、ちょっと気をつけてほしいのが、やはり無償のツールというところで、サポートがなかったり、情報不足で工数がかかるっていうことがあったりします。このあたりが、無償ツールを使う時の注意事項になるのかなと思います。。

こういった無償のツールではありますが、例えば我々日立ソリューションズのような、オープンソースのSBOMツールを導入する時のサポートを提供している会社もありますので、そういったところの支援を受けられるのも、1つの案かなと思います。

渡邊：次がSBOMツールの選定の観点というところで、手引書ではここ、すごくページを割いて詳細に書いてあるんですが、1ページにまとめてサマライズして書いてみたというのがこちらです。

SBOMツールの選定の観点というのは、すごくたくさんありまして、それぞれいろいろなことがポイントとして書かれています。

篠原さん、ここでお話ししたいところがあるんですけれども、14個あって、それぞれ大事なポイントではあるかと思うのですが、実際に例えばご自身で一番初めに重要と挙げられるとするならば、どこになるでしょうか？

篠原巧氏（以下、篠原）：そうですね。当然ツールなので、機能とか性能とかが一番重要になってくるかなと考えています。

一方で実証ですと、今回けっこう大手の企業さんではなくて、中小規模の事業者にご協力いただいて、SBOMツールを使ってSBOMを作っていくところを試していきました。

そういった状況を振り返ると、やはりサポート体制や日本語対応しているかどうかがけっこう重要だったのではないかなと考えています。

昨日の質問でも少し寄せられてはいましたが、やはりそういった事業者だと、なかなかセキュリティ専任とかが立てにくくて、そもそもソフトウェアに関する知識があんまりない方がSBOMを作るってなった時に、自分たちだけで作るっていうのはかなり大変で、本当に日立ソリューションズが協力して、今回SBOMを作ることができたっていうところなので。

もちろんコストに余裕があれば、という前提条件はありますが、こういったところが1つ、ツールを使っていく上では重要になってくるかなと感じたところですね。

渡邊：なるほど、ありがとうございます。後から出てくるんですが、ツールを使った後の注意ポイントっていうんですかね。エラーが出ていないかどうかとか、ツールの出てきた結果が正しいかどうかとか、そういったところの話もあります。

特に実証の時、エラーのハンドリングというか、「ちょっとツールが止まっちゃっているんですけど、これ、解析できていますかね？」とか、あと、エラーが出ていてちょっと正確に結果が出ていなかったんだけれど、それに気づかずにそのまま進めてしまっていたりとか、そういったケースも実証の中ではあったと思いますので、そういったところも気にしておくべきポイントです。

もしそういったことが、体制がなくてできなそうであれば、外部にそのサポートを求めるところも、検討するポイントなのかなと思ったりもします。

私が個人的に気になるのは、この対応言語のところと、あと解析方法のところですかね。

選定のところにけっこう関わってくるんですが、今回実証でも、ちょっと特殊な環境というか、特殊な言語と特殊なフレームワークを使って開発されていたプロジェクトがありました。

それが、最初にチョイスしたツールだと、サポートしていなくて、次に別のツールを使って実証実験をやったんですね。

そういった感じで、ちょっと特殊な開発をされているような方ですと、実際に使おうと思っているツールがサポートしきれていないケースもあったりするので、そこはけっこう注意ポイントなのかなと思ったりします。

けっこうたくさんあるので、全部気にしておくべきポイントではあるかと思うんですが、少なくとも今挙げたような機能と性能のところとか、あとサポートのところ、日本語対応のところ、こういったところは、まず一番初めに気にされるところかなと思います。

渡邊：実際ここのポイントを踏まえて使うツールを選んだ時に、その後、このSBOMツールを導入していくところで、実際にセットアップするところになってきますが、その部分についての実施事項と注意ポイントです。

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

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

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

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

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

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

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

篠原さん、ここでいくと、陥りがちな課題とか、あとは難しそうなところっていうのは、どれかあったりしますか？　特に注意していただきたいところ。

篠原：そうですね。当たり前と言えば当たり前なんですが、やはり実証で明らかになったところは、試行錯誤的な対応が必要だよねっていうところで、すぐに導入ができたわけじゃなくて、SBOMを作る環境を作るのにもけっこう大変だったことが実証でも明らかになった部分なので、そこはご認識いただけるとよいかなと考えています。

渡邊：なるほど、ありがとうございます。そう、なんか、インストール失敗しちゃった系の話もけっこうあるかなと（笑）。

私も会社の環境にいろんなSBOMツール、無償のツールでも有償のツールでもインストールして環境を作って、SBOMを作ってっていうことをいろいろやっているんですが。

例えば、うちの会社はすごくネットワークの周りが厳しい会社でして、プロキシの設定をどうするのかとか、そういったところでけっこうつまずくことが多くて、そういったところがやはり試行錯誤的な対応をしなきゃいけなくなってしまうところだったりもします。

というところで、そういった、「ちょっとうちの会社、ネットワーク絡みで厳しいんだよね」っていうような会社とかは、やはりプロキシの越え方みたいなところとか、けっこう困ることが多いですよというようなことも補足情報としてお話をしておきます。はい、ありがとうございます。

渡邊：じゃあ、次ですね。実際に環境構築ができました。それから、セットアップもできてってなった時の話なんですが、じゃあ、ツールに関する学習、使い方の話になりますよね。

実施事項に関しては、ここは同じですかね、トリセツ、READMEなどを確認して使い方を習得をしましょう。1人がしっかり試行錯誤をして、例えばノウハウを溜められたのであれば、それはちゃんと組織の中で共有することによって、セカンドランナーが楽になるっていうこともあると思うので、共有もしましょうね、ということが書かれています。

認識しておくべきポイントのところでは、先ほどと同じで、サポートを提供している人もたくさんいるので、場合によってはそういったサポートを受けることで、効率的に学習できますよ、というところもあります。

あとは、サンプルのSBOMを通じて試行錯誤的にツールを使ってみて、最終的に使い方を習得するっていうこともできます。

ここは手引の中に書いてあることなんですが、特に有償のツールの場合だと、本当にいろんな機能があって細かい設定もいろいろできるので、機能がすごくたくさんあって、全部の機能をイチから十まで習得しようと思うとかなり大変です。

そこに対して時間がかかってしまうこともあるので、例えば、「自分たちの目的を達成するのに必要な機能はこれだ」っていうのをまず決めて、まずそこからやっていくみたいな、全部の機能を最初からがんばろうとしないっていうところとかも効果的ですよ、ということが手引書の中には書いてあります。ここも覚えておくとよいかなと思います。

渡邊：では、次ですね。5章にいきます。5章は、SBOMの作成・共有フェーズということで、実際にツールを入れて、じゃあ、SBOMを作ってみましょうというフェーズのお話です。具体的には、コンポーネントの解析をして、SBOMを作って、それを共有するという3つのフェーズが書かれています。

まず、コンポーネントの解析というフェーズですね。これはどういうイメージかというと、対象のSBOMを、作りたいプログラムとかモジュールなんかがあった時に、それをツールで解析をしてあげて、中がどういう状態になっているのか。

例えば、「こういうコンポーネントが入っていますよ」「こういうライブラリが入っていますよ」ということを見つけていくフェーズのお話です。

ここでは何をするかというと、ツールを用いてスキャンをします。これは解析とほぼ同義語だと思いますが、対象のソフトウェアをスキャンして、中の情報を解析をします。

2点目が、さっきお話ししたところなんですが、ツールの解析ログなんかが出ますけれども、それをちゃんと見ましょうと。エラーの発生や情報不足による解析の中断や省略がなく、解析が正しく実行されたかを確認する。ここはけっこう大事ですというお話です。

ちょっと変な話、例えばなんですけど、高機能のツールであればあるほど、いくつかの解析のパターンを一緒にやってくれるみたいなことがあります。

例えば1個の解析がこけてしまったとしても、ほかのができていれば、最終的になんとなくできたっぽい感じの結果が表示されます。しかし実はちょっと1個こけているのがあるので、正しい結果ができていませんでしたとか、そういったことも発生します。そういう場合は、解析ログをちゃんと見ましょうね。これは、SBOMツールだけの話じゃないのかもしれないんですが、そういったことも書かれています。

あとは、コンポーネントの解析結果について、誤検知や検出漏れがないかも確認しましょう。

このあたり、やはりツールを使うことのメリットが実証実験の中でも数値化されていて、具体的には、医療分野の歯科用CT、昨日の最後に図を見ていただいたやつですね。

例えば手動でSBOMを作ろうと思った時には、30人時間がかかると見積もられましたが、ツールで解析してあげれば、シュッと、0.15人時間でできましたということで、99パーセント以上の工数削減ができましたというような実証の結果が出ています。

これが本当に、どんな方にも当てはまるわけではないのかもしれませんが、少なくとも実証の中では、この工数削減の効果が見られました。

認識しておくべきポイントというのがたくさん書いてありますが、この次のページでお話しするので、いったんここでは飛ばします。すみません。

渡邊：次の、このページですね。ここはちょっと補足のスライドになっていまして、こちらもSBOM導入の手引自体にも書かれていない、今回のセミナー用の資料です。

いろいろなツール解析の手法の種類がたくさんあります。その例というのをこちらに挙げていまして、例えばファイルのマッチング、スニペットマッチング、ライセンスヘッダマッチング、依存関係解析といったかたちです。

1つのソフトウェア、ソースコードをスキャン、解析して、中の情報を取り出すことについても、いろいろなアプローチ方法があります。

例えばなのですが、もうバイナルファイルしかありません。昨日ちょっとお話がありましたけれども、ソースコードがなくてバイナルファイルしか手元になくて、そこからどうしてもSBOMを作りたいということであれば、このバイナリ解析っていうものができる機能、この機能を持っているツールを選ばなくてはいけません。

あとは例えば、オープンソースのソースコードをダウンロードしてきて、それを自分たちでいろいろ修正といいますか、変えて、使っているというようなケースであれば、そもそもAs-Isで使っていないので、ちょっと改変が関わっていると。

そうすると、例えばファイルマッチングっていう手法では、ファイルの内容が変わってしまったりしているので見つからないケースがあります。そういった時には、スニペットマッチングっていう機能を使わなければいけません。

というかたちで、ご自身の持っている対象のソフトウェアがどういうもので、どういうふうになっているのかという状態に合わせて必要な機能っていうのも変わってきますので、こういったところもちゃんと選びましょう。

ちょっと、実証の手引書のほうには、このあたり、この細かい解析のやり方っていうのが書いていなかったので、ちょっとここだけ補足を入れています。

渡邊：では次、この話で書いてあるのが、実証において明らかになった懸念ということで、実証実験で実際にツールを使って解析してみた時に、こんないろいろな課題が明らかになりましたよ、ということが手引書の中には書かれています。

ここをちょっと篠原さんと見ていこうかなと思いますが、このへん、ちょっとふんわりした振りで恐縮なんですけれども、どう思いますかというか（笑）。

私からすると、どれも「そりゃそうだろうな」みたいな感じの懸念点ではあったりしますが、このへん、例えば篠原さんが一番、今回見つかって気にしていたポイントとか、なんか、こんなことがあるんだなって思ったものとか、なにかお話しされたいこと、あったりしますか？

篠原：そうですね。「そりゃそうだろうな」と言われればそれまでではあるんですけども（笑）。

渡邊：（笑）。

篠原：総じて言えることとしては、やはりSBOMっていうのがまだまだ黎明期な部分でもあるので、SBOMツールも100パーセントではないというところが、実証で定量的に明らかになった部分かなと思っています。

渡邊：なるほど。

篠原：いろんなツールを試して結果が出たところで、例えばバイナリ解析の場合、1割程度しか検出されなかったっていうところがあるんですが、これもけっこうケースバイケースで、これだけちょっと読んでいただくと、「じゃあ、バイナリ解析、あんまり良くないよね」っていう印象を受ける方もいるかもしれません。

決してそうではなくて、バイナリファイルがあって、ソースコードももしあれば、バイナリのスキャンの精度というのは良くなって、補完するような役割にもなったりするので、SBOMツールの使い方や対象となるソフトウェアによってこういった課題も払拭されるようなケースもあるかなというふうには考えています。

渡邊：なるほど、確かにバイナリファイルしかないっていうような、バイナリはやはりアプローチ的にちょっと難しいところ、「そりゃそうだろうな」はあるんですけど、今のお話だと、バイナリ解析もするし、対象のソフトウェアの情報もあって、両方を合わせるとちゃんと精度が上がってくるみたいなやり方もあるっていうことですね。

渡邊：では、次ですね。SBOMを実際に作るというところです。先ほどのセクションで解析をして、中のコンポーネントにどういうものが入っているのかがわかりました。その次に、SBOMとして表現をするところをお話ししますね。

作成するSBOMの項目、昨日も言いましたが、最小要素だけでいいのかみたいな話とか、あとフォーマットとしてSPDX、CycloneDXなど、いろいろあります。

出力ファイル形式。例えばSPDXも、JSONだったりXMLだったりいろんなファイル形式があるので、どれにするかという話だったり。

あとは、それがツールを使ってすぐにシュッとSPDXのJSON形式ファイルが出力できると、とても工数が低減するので、それがちゃんとできるかどうか、そういったツールを使ってちゃんとできるかどうかだと思います。

ポイントとしては、正確な情報を書いてくださいねという話であったり、あとは、自分たちが作ったものじゃなくてサードパーティとかOSSのコミュニティさんが作られているものの場合は、そこからSBOMをもらうこともできますよ、ということがあります。

ここに、ちょっとポイントとして書いてありますが、受領後に改変している場合は、そのままは利用できないので注意と書かれています。どういうことかというと、ちょっとあんまりあるかわからないですが、サードパーティさんからなにかモジュールをもらいましたと。それにSBOMもくっついてきました。

これでよかったよかったと思っているかもしれませんが、例えばそのモジュールで、ちょっと修正を入れようとか、新しいライブラリを使おうとか、あと、バージョンアップしようとか、そんな感じで変えてしまったりしていると、もうそれは、その時のもらったSBOMと完全に一致する状態ではないので、そのSBOMはそのまま使えません。そういったことが、手引書の中でも注意事項として書かれています。そこもご注意ください。