【VTuber×日立ソリューションズ】Linux系エンジニアがSBOMを実際に作ってみて気になったポイント5選 セミナーレポート（2/2）

イベント概要

オープンソース・ソフトウェア（OSS）は、現在多くの産業で使われていますが、脆弱性やコンプライアンス面で、さまざまなリスクも存在しています。そんな中で注目されているのが、ソフトウェアを構成する要素を一覧できるリスト「SBOM（エスボム）」です。欧米の公的機関などでもSBOMの必要性が指摘されており、今後は国内のさまざまな企業・組織でも対応が求められる可能性があります。

本記事では、株式会社日立ソリューションズ主催「SBOMを語る3日間！OSSマネジメントフォーラム2022」より、Linux系VTuberの熊ケ谷リナ氏の講演をお届けします。

スピーカー

熊ケ谷 リナ 氏 Linux系 VTuber

渡邊 歩（モデレーター） 株式会社日立ソリューションズ

セミナー内容

熊ケ谷：こういった形でSBOMの情報を外部から受け取るなり、あるいは自分たちで作っていけば、システムのSBOMを完璧に揃えられるかなと思われるかもしれないです。ですが、ITシステムで動いているLinuxの場合、Linuxが提供するパッケージ数だけで実は6000パッケージ以上あります。これはすべてのリポジトリに含まれているパッケージ数なので、実際にサーバにインストールされるパッケージ数はこれより少なくなる可能性はありますが、それでも数百から数千というパッケージが存在するはずで、それら一つひとつのSBOMを果たして作れるのか？という話があります。

やはりITシステムを使うユーザー側の視点から見ると、これらのパッケージについて自分たちでSBOMを作ることは現実的ではないと思います。実際にはコミュニティや製品ベンダが提供してくれるSBOMをちゃんと受け取って、それを自分たちで活用するという方向を考えるべきですし、もしSBOMがなければ、ベンダーなどソフトウェア提供側にSBOMの提供を依頼していくべきでしょう。

ただ現状としてはSBOMを提供しているコミュニティや製品というのは非常に少ないので、用意できないというのであれば手動で書くか、あるいはツールのようなものがあるのでそれを使って自作していくしかありません。この自作も正直、商用ソフトウェアに関してはソースコードの開示が行われていない場合もありますので、現状としてはかなり難しいところではあると思います。数多くあるソフトウェアパッケージに対してすべてSBOMを作るとなると、エンドユーザーからすると土台無理ですので、コミュニティおよび製品側の対応を切実にお願いしているというのが、実際の状況となっています。

熊ケ谷：ただ一方で、SBOMも提供し始めている流れもあります。製造業系では既に提供が進んでいるのかなと思いつつ、私はサーバー寄りの人なのでサーバー寄りではどんなところがSBOMを提供しているのかなと簡単に調べてみました。例えばLinuxのディストリビューターであれば、ディストリビューションとしてはAlmaLinuxなどがSBOMの提供を行っています。またサイバートラスト社が出している商用製品なんですけども、MIRACLE Vul Hammerという脆弱性管理の製品でもSBOMの提供を行っています。Vul HammerというのはSBOMを使った脆弱性管理を実現するソフトウェアということで、自分が使うから自分のSBOMを提供するということで公開しているようです。このような情報を今後はエンドユーザー側として活用して、システムの管理に役立てていく形になるかと思います。

熊ケ谷：実際にサンプルとしてAlmaLinuxのSBOM CLIという、AlmaLinuxがSBOMを提供する仕組みを試してみました。色々と書いてあるんですけれども、要点としては、AlmaLinux自体が今ビルドシステムを公開しているのもありまして、そのビルドシステム上でビルドされた特定パッケージのSBOMを入手することができるツールになってます。出力フォーマットとしては現状CycloneDXのみなのですが、将来的にはSPDXにも対応するということです。

熊ケ谷：実際の使い方としてはこちらですね。バックグラウンドで、CASというシステムを使っていますので、まずこちらのAPIキーを無料で登録してログインする必要があります。

熊ケ谷：それをやった後、CLIのインストールをします。Pythonを用意したうえで、GitHub上からSBOM CLIをダウンロードしてきてPythonスクリプトのインストールを行います。これで特定のビルドIDに対してSBOMを生成するという操作を行うことができます。

熊ケ谷：実際に生成されたSBOMを見てみると、一般的なCycloneDXのフォーマットでしっかりと書かれていました。バージョンは私の確認したタイミングでは1.4でした。

熊ケ谷：下を見て行きますと、最初にCycloneDXはSBOM自体に関する情報が書いてあるんですけども、SBOM生成に使ったツールなどの情報もしっかり書かれていました。

熊ケ谷：さらに読み進めていくと、componentということで、これだとビルドのサンプルなので4372と書いてありますが、ここでビルドしたものの情報というのが書かれていました。

熊ケ谷：このような形で、AlmaLinuxのようなLinuxベンダーやその製品のメーカーが提供したSBOMをたくさん受け取ることになると思います。そうするとITシステム上ではSBOMというのが大量に増えていくんじゃないかと予想されます。実際先ほどのシステム例に照らし合わせてみると、当然ソフトウェア毎にSBOMがあるはずで、その下にぶら下がっているソースコードとかライブラリ、こういった情報が記載されることになるでしょう。これをシステムの運用に落とし込んでいくことを考える必要があります。例えば個々のSBOMというのは当然更新されていきます。アップデートがあれば、その裏で使っているライブラリとか、当然ソフトウェアのバージョンも上がりますし、それに伴ってSBOMのバージョンも上がっていくでしょう。そしてSBOM自体がたくさん増えてくると、今度はこのSBOM自体に改ざんされるリスクも出てくるでしょう。当然ですが、たくさんあるSBOMをひとまとめに統合する方法というのを考えなければいけません。

熊ケ谷：それを解決するのに、こういったことが今のCycloneDXだとありますよという話を紹介します。例えばSBOMの更新情報という意味では、古いバージョンがどんどん溜まっていくイメージではなく、SBOMの中に更新情報を記載して表現できます。CycloneDXの場合ですと、「血統」といわれるセクションがありまして、その中にSBOM自体やSBOMのコンポーネントに対する更新履歴を書くことができます。

熊ケ谷：これもいろいろあります。例えば更新内容が修正なのか機能改善なのか、パッチなのか何なのかとか、またパッチを当てた際に差分もちゃんと明記できるようになっていて、そういったところを表現することができます。そういう意味だとSBOMがいわゆるLinuxだとchangelogを読むような感じで、いつどのような修正が行われたソフトウェアかをSBOMで見ることもできます。SBOM自体のファイルサイズは多分膨れていくと思うんですが、SBOMの数がその更新の度に増えていくことはなく、ちゃんとバージョンニングの仕組みもあるように見えました。

熊ケ谷：今度はSBOMをシステムごとに、あるいはそのもうちょっと大きい組織とかサービスごとにひとまとめにしたいという話が当然出てくると思います。方法としては、例えばCycloneDXなんですが、コンポーネントをネストするという表記がCycloneDXではできます。アプリケーションの中に別のアプリケーションを内包しているような状況であれば、SBOMのcomponentsの中にネストして裏側で使っているアプリケーションの内容を書くことができ、システムのtreeを表現できます。このコンポーネント間の依存関係については、別途依存関係を記載するセクションがありますので、そこに記載することもできます。

また一つのアプリケーションの中でネストしているコンポーネントの開発元が違うとかそういった話もありますので、それを個々に記載したりできます。あるいはそのコンポーネントを開発したベンダーとかメーカーが、そこにデジタル署名を表記することも可能です。知らない誰かが存在しないコンポーネントを追加したりとか、存在するはずなのにそのコンポーネントを消したりとか、そういったところをデジタル署名で検証することができるというような構造にもなっています。

熊ケ谷：ただ、受け取ったSBOMを1個1個エディタで開いて一つにまとめていくのも大変なので、これをまとめるツールというのも世の中にあります。sbom-combinerという、これはLockheed Martinの人が開発しているものだったかと思いますが、複数のSBOMを結合して一つのSBOMにすることができます。これもGitHub上でツールが公開されています。

コマンドラインツールですので、先ほどのAlmaLinuxのSBOM CLIのように手動で実行することもできますし、API連携によってCI的な仕組みの中でこのcombinerを動かすこともできます。SBOMの更新があったタイミングで、統合された一つのSBOMに合わせるといった仕組みも考えられそうです。

熊ケ谷：先ほどちょっと触れましたが、SBOM自体を改ざんされるリスクというのもあります。SBOMの（コンポーネントの）表記を1個消すことによってあるはずのコンポーネントを隠すとか、逆にSBOMの表記を追加して存在しないものをあたかも存在するかのようにSBOM上で見せかけるとか、そういった攻撃が今後出てくることが予想されます。これを防ぐためにSBOM自体にデジタル署名を記載するという、これもCycloneDXの話なのですが、こちらに書いてあるようにsignatureセクションで署名を記入することができます。

また、ここまでサーバー上で動いているパッケージの話をしてきましたが、例えばコンテナに対してどうするんだという話もあります。コンテナに対してはSPDXもCycloneDXも、イメージ自体にSBOMを作ってそれに対してデジタル署名をするという仕組みがあったりします。実態としてはsigstoreが出しているcosignという署名ツールがあります。冒頭にお話したように私自身もこのsigstoreなどを使ってコンテナイメージのSBOMを作って署名して検証するというようなことを動画で解説したりしています。こちらも見ていただければと思います。

熊ケ谷：最後ですが、ここまで話したことはかなり手探り感のあるお話だったと思います。実際SBOMを使うことで、ITシステム、要はサーバー寄りのエンドユーザーの人にも大きなメリットがあると思います。一方で、現状提供されているSBOMが圧倒的に少ないので、それを手書きするかどうかという話もあります。また提供されるSBOM自体、表記されている内容がオプションで、（定義されている）仕様がすべて書かれているSBOMというのはほとんどありません。必要なものだけ書かれているケースがほとんどです。その提供されたSBOMの表記内容が、自分の求めている情報がちゃんと書いているのかどうかというチェックも必要になってしまうでしょう。フォーマット自体も、SPDXとかCycloneDXとか、将来的にこれを統合しようという動きもあるようですが、現状は二つに分かれているので、どちらを採用するのか、混在できるのかというところが、実際には今後検討していかなければいけない課題です。

先ほど管理方法の検討ということで、SBOMの統合やデジタル署名など色々な方法をご紹介しましたが、まだまだベストプラクティスが無いのも現状です。これらについてはコミュニティ側で議論が行われている状況ですが、これにはユーザー側の発信も重要です。実際に使ってみてここが使いづらいとか、実際に採用するにはこういった要素がないとダメとか、そういった発言をユーザー側からどんどん発信して、コミュニティにキャッチアップしてもらうのが、ユーザー側が幸せになる為に必要なんじゃないかと思っています。例えばオンプレの環境だけじゃなくて、マルチクラウドだとどうなんだろうかとか。システム構成とか開発モデルによってはどう違うんだとか、そういった課題を発信することも重要かなと思っています。実際、今回私もユーザー側として発信したことによって、この場に立っていることもありますし、是非皆さんもこういった情報をどんどん発信していただければと思います。

熊ケ谷：最後まとめとして、各セクションの課題をこちらにまとめております。それぞれ「現状」の話になってしまうので、どれもベストな解決法があるというものではありませんでしたが、先ほど申し上げたようにSBOMはこれからの領域ですので、是非皆さんも自社のITシステムにどう活用できるのかというところから検討いただければと思います。

はい、ちょっと長くなっちゃいましたが、私のセクションは以上で終わりにします。ご清聴いただきましてありがとうございました。

渡邊歩：はい、どうもありがとうございます。色々と為になるお話を聞かせていただきました。特にフワっとしたスライドと内容のゴリゴリさ加減がグっと来てですね、私個人的には非常に楽しませて頂きました。どうもありがとうございます。

それでは「Linux系エンジニアがSBOMを実際に作ってみて気になったポイント5選」ということで、Linux系Vtuberの熊ケ谷リナ様にご講演いただきました。どうもありがとうございました。