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

イベント概要

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

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

スピーカー

熊ケ谷 リナ 氏 Linux系 VTuber

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

セミナー内容

渡邊歩（以下、渡邊）：本日は「Linux系エンジニアが実際にSBOMを作ってみて気になったポイント5選」ということで、Linux系のVtuberでいらっしゃいます、熊ケ谷リナ様にご登壇をいただきます。それでは熊ケ谷さんご準備いかがでしょうか？大丈夫ですか？

熊ケ谷リナ氏（以下、熊ケ谷）：はい、大丈夫です。

渡邊：はい、ありがとうございます。それでは画面の共有とご講演を、どうぞよろしくお願いいたします。

熊ケ谷：はい、皆さん改めまして、はじめまして。私Linux系Vtuberをやっております、熊ケ谷リナと申します。最初に簡単に自己紹介させていただきます。

熊ケ谷：名前としては先ほど言ったように「熊ケ谷リナ」という名前で、Linux系Vtuberとして活動しております。Vtuber以外で、リアルで普通にお仕事もしてまして、勤め先は、某Linux屋さんに勤めています。数年前までは、普通にエンジニアをやっていたんですけれども、今は企画職をやっております。Linuxどれぐらい使ったことあるかなっていうところなんですけど、多分8年から9年、10年近く触ってるんじゃないかなと思います。

もともと新卒で入った会社がWindows使うのに例外許可申請が必要なぐらい、なかなか尖った会社だったので、そこからLinuxを使っているといった経緯があります。今その経験でLinux系Vtuberをやっているという感じですね。推してるディストリビューションがありまして、ネットワーク系の、国産で作られているMIRACLE LINUXというディストリビューションを推しております。このMIRACLE LINUXに関係することや今回のSBOMとかLinux全般の話を動画としてYouTubeに投稿しておりますので、是非チャンネル登録お願いします。またツイッターもやってますので、こちらのフォローも是非よろしくお願いします。

熊ケ谷：こんなことをやっている私が、なんで今日この大きな場に登壇しているのか、疑問というか、興味を持たれている方もいらっしゃるんじゃないかなと思います。もともと私がこのVtuberの活動を始めて最初の頃に、MIRACLE LINUXをDockerのコンテナにして、そのSBOMを作って署名して検証、アテステーションをするという動画をアップロードしました。これをたまたま、SBOMとかSPDXとかの取り組みをしているOpenChainプロジェクトのJapanチームの方に見つけていただきまして、そのままTooling-SGという分科会から是非話してくださいということでお呼びいただきました。その中で、OpenChainに参加されている日立ソリューションズさんから「今回のセミナーに登壇しませんか？」という風にお誘いいただいたという経緯になります。もともとこのSBOMというキーワードに対してはちょっと取り組んでいたよ、というところですね。

熊ケ谷：今回の本題ですね。SBOMについてということで、今回私はLinuxに関してサーバー寄りの立場で参加しています。SBOMというと、どちらかというと今は組み込みとか製造業系で活発に議論がされているのかなという印象を持っているんですけども、今回私はいわゆるITシステム、サービス、サーバー寄り、エンドユーザー寄りのポジションで、SBOMを使ってみた感想をお話ししたいと思っています。

そういう意味で、今回お話しするポイント5つ挙げております。1つが、SBOMを自分のITシステムにどう使えるか、SBOMって自分のITシステムにどう嬉しいんだ、ということを最初にお話しします。次に、実際にエンドユーザー側の視点から見ると、SBOMは自分で作るよりも「提供されたものを活用するもの」になってくると思いますので、この「提供されるSBOM」をどう活用するかといった話をいたします。また実際にSBOMを自分のシステム上でどう運用していくのかというのをちょっと考えてみましたので、その話もいたします。そして、SBOMの運用に関して、運用自体にどういったリスクが出てくるんだろうね、というところを少し考えてみたので、この話もいたします。最後に、SBOMをエンドユーザー寄りで使っていくにあたって、どうすれば幸せになれるのかなと、まとめ的にお話ししようと思っております。

熊ケ谷：早速本題に入っていこうと思うんですが、本日参加いただいている方はSBOMについて散々あちこちで伺っているかなと思いますので、SBOM自体の話は簡単にご紹介しようと思います。SBOMはSoftware Bill of Materialsの略で、ソフトウェア部品表と言われていて、ソフトウェアを構成する部品を一覧化したものという風に定義されています。ソフトウェアを構成する部品ということで、ミニマムにはソースコードだったりとか、ライブラリだったりとか、バイナリとか、ちょっと広げればドキュメントとか、そういったものを一覧化したものですという風に書かれています。

一方で、ITシステム全体で考えてみると、ソースコードやライブラリっていうのは本当に一番下のレイヤーに存在するもので、このようなレベルのものは非常に見えづらいんじゃないかなと思ってます。実際に、既存のシステムなんかを見てみても、例えば仕様書とか、システムサービスの構成図とかあったりすると思うんですけれども、実際にそこに書かれている内容としてはソフトウェアレベルまでで、ソフトウェアのインストールするソフトウェアのバージョンであったりとか、そういったレベルの内容しか殆ど書かれていないと思います。内製ツールなんかは細かく仕様があるかなと思うんですが、それこそ商用のソフトウェアを使ってる場合、当然ソースコードなどは開示されていないですし、使用者に対しても機能とかそういったレベルの情報しか書かれていないかと思います。

しかもシステム全体で見たときに、サーバーは複数が稼働していたりするものですから、こういったものの仕様書だったり構成書、それらの個数やバリエーション、バージョンというのも非常に多くなってきます。またこれらが分散していたり、書かれている情報の粒度とかレベル感がバラバラな状態だったり、そのような形でシステムが動いているわけです。これが実際に問題として表面化したのは、これも散々言われている話かなと思いますが、Log4jの問題のときかなと思います。特定のソフトウェアではなく、そのソフトウェアが使っているオープンソースのライブラリに脆弱性が出たときに、当然そのシステム屋から見ると、覚えているソフトウェアのバージョンまでは把握できているけど、そのソフトウェアがどんなライブラリ作っているかまではさすがに把握できていないですよね。商用ソフトウェアなんかは裏で何が動いているか分からないですし、オープンソースのミドルウェアなども、見ようと思えば見れると思うんですけれども、そこまで把握するのは正直、一般のシステムではかなり難しいかなと思います。現実でも、これらがどこにどれだけ使われているのか把握するだけでも非常に大変だったということで、大きな問題になりました。この対応も、該当するライブラリのバージョンを上げてしまえばいいだけなんですけれども、上げるにあたっての調査に非常に手間がかかったという印象です。

SBOMの中には、ライセンスやバージョン、そのソフトウェアで使われている構成要素のバージョンも含めて書かれているので、これを上手く使うことで先ほどのLog4jで起きたような問題に対応できます。巨大なITシステムの中で、小さな一つのパーツに問題があった時の影響把握に上手く使えるんじゃないかなと思っています。実際に、SPDXやCycloneDXと言われるフォーマットが、世の中では一般的に使われ始めてきていています。先ほど私が話したような問題が世の中的に認知されて、これらの活用や採用が急速に進んでいる現状があるかなと思っています。

熊ケ谷：ITシステム全体における問題対処の影響把握をするときの困難さについて、ここでは非常に簡略化されたシンプルな構成図で説明をいたします。何かwebサービスを提供する際のシステムを例としています。

webサーバーの中でApacheとかNginxとかサーバソフトが動いています。またそれが提供するサイト実体つぉいてJavaScript、HTMLのソースコードなどがあり、その中で使っているライブラリ、プラグインがあります。一方バックエンド側では、APIを提供するサーバが動いていたりとか、システムのヘルスチェックをするソフトウェアが動いていたりとか、あるいは何かコンテナが動いていて何らかの機能を提供したりするかもしれません。データベースサーバも別にあって、それぞれのデータを保管しているかもしれません。一般的なシステムとしてよくある構成だと思います。

この中の特定のライブラリに脆弱性が発見された場合、先ほども話したように影響範囲を特定するというのが最初の対応フローなるかと思います。これがまず至難ですよね。実際にはソフトウェアの開発ベンダーやメーカーに対して仕様をチェックするところから始めていくのかなと思いますが、大きなシステムになると膨大な数になります。しかもこれらのライブラリがオープンソースだった場合は、「どこをチェックすればいいのか？」とか、そういった問題も出てきます。またちょっと組織的な話になりますけれども、大きいシステムだとそのサーバー管理している部署が社内的に分かれていたりしますよね。これによって情報の共有や連絡というのも結構困難がつきまといます。ある程度利用範囲が見えてきて、どこで該当のライブラリが使われているかがわかってきたら、この影響範囲を評定しなければいけません。

これもなかなか至難の業です。脆弱性が発見された時の対応方法として、シンプルにアップデートをかけてしまうというのがあると思うのですが、これが難しいサービスやサーバーもあります。依存関係の問題でアップデートすると他のミドルウェアがうまく動きませんとか、内製ツールがバージョン固定で開発されているのでアップデートできませんとか、そういった問題が沢山出てくる。これらを総合的に判断して脆弱性の危険度や対応の工数を諸々総合的に評価して、評定を行って決定する必要があります。ここまでかなり大変かなと。あとは方針さえ決まってしまえば、パッチを当てるなり、ワークアラウンドの対処をするなりとなります。ですので、1番2番が非常に大変で、3番が苦しくて、4番は粛々、という感じになってくるかなと思います。

その中で、SBOMがあったらどれだけ嬉しいかなというところです。まず1番2番ついて、特に1番は該当ライブラリの利用調査という意味では非常に楽になりますよね。システムの中でSBOMが完備されていれば、どこで何を使っているのかは容易に検索することができますし、また依存関係もそのSBOMの中には表記される場合がありますので、これもちゃんと書かれていれば、どこにどれだけ影響を受けるのか、ホットポイントはどこなのかというところの評定も容易になってきます。

また修正パッチを当てるといった実作業の面において、パッチの入手先はOSSのディストリビューターなのか、あるいはそのOSSのコミュニティなのか、あるいはメーカーベンダーなのか、などの情報もSBOMに記載することができます。これらがちゃんと書かれていれば、先ほど話した対応フローが非常に楽になるんじゃないかと考えています。

熊ケ谷：その他にも、脆弱性だけではなくてOSSライセンスの問題が出てきた時に上手く使えるんじゃないかなと考えています。サーバー側でOSSライセンスが問題になることは少ないかなと思うんですが、例えば自社で開発したITシステムにOSSを使っていて、そのシステムを他社さんに横展開しましょうみたいな話もあるかと思うんですが、これはオープンソースの再配布にあたるケースになりますので、当然OSSのライセンスについてはどこで何が使われているかは把握しておく必要があります。これを調査するのもなかなか大変な作業になりますので、その時にもSBOMは使えるでしょう。

またwebサービスの場合、最近だとJavaScriptをたくさん使っているかなと思うんですけれども、そのJavaScript自体は実際閲覧するユーザーのブラウザに対してソースコードを配布していることになるので、そういった意味ではこのOSSライセンスは気を付けなければいけないものです。実際ソースの配布はウェブサーバがやっていて、問題はライセンスの表示になってくるかと思います。通常はそのJavaScriptのソースコードの中にライセンス表記がされているんですけれども、OSSだとライセンスが時々変わったりするっていうものもあるので注意が必要です。最近だと例えばMongoDBがAGPLからSSPLというライセンスに変更されましたが、このように途中でライセンスが変わるといった問題もあるので、そうなったら表記を変えなければいけません。けれども、自社のwebサービスのどこでそのようなJavaScriptを使っているのか調査することも大変な困難がつきまとうでしょう。そういった意味で、SBOM中にライセンスが適切に記載されていればこの調査が楽になるでしょうし、実際の運用が容易になるというメリットがありそうです。

また、サーバー運用的な話で見てみると、例えばソフトウェアのEOLの問題があります。OSSもコミュニティによってメンテナンスが終了されるものが出てきます。サポートがないということは脆弱性など問題が出たときに修正パッチが出てきません。使っているLinuxによっては、ディストリビューション側からパッケージの提供があったり、「終わります」といったアナウンスがあったりしますけれども、逆にSBOMの中にこういった情報がちゃんと記載されていれば、「来期にEOLを迎えるOSSのソフトウェアって何個あるんだっけ」というのを、事前に議論し始めるということもできるようになるかなと思います。

あとOSSのリスクという意味では、例えばマリシャスパッケージと呼ばれる、GitHubとかが攻撃を受けて悪意のあるコードが混入してしまうといったものがあります。当然コミュニティ側で修正して排除しましたとアナウンスになると思いますが、修正されるまでの間にパッケージをインストールしてしまっていないか、というところの調査にもSBOMは使えると思います。またコミュニティ側が一種のプロテストウェアとして、抗議の意味合いでソースコードに問題がある内容を書いてビルドして提供する場合があります。これもやはりコミュニティ側で修正されるまでの間にインストールしてしまったかどうかを調査するのにSBOMが使えそうです。

熊ケ谷：これらの情報がSBOMのどの部分に書かれているかという話ですが、ここではSPDXのバージョン2.2.1の構成要素を出しています。SPDX はSBOMの一つのフォーマットで、SBOMに記載されるべき情報は各セクションに分けて、その中にフィールドとして書くように設計されています。色々あるんですけれども、先ほど話したような内容はPackageセクションの中に書かれています。構成パッケージの名前だったり、バージョンだったり、ライセンスだったり、配布元の情報が書かれています。実際に今後SBOMを受け取って、これを使って先ほど話したような問題の解決をしていこうと考えた時には、SPDXであればこのPackageセクションをよく見ていくといいのかなと思います。

またSPDXですとRelationships between SPDX elementsというセクションもありまして、この中には依存関係の情報が含まれているということで、ここもちゃんと記載されていれば先ほど言ったホットポイントの評定などにも役立つんじゃないかなと思っています。

熊ケ谷：実際にどういうふうに書かれているかというところですが、SPDXですとSBOMのサンプルがGitHub上で公開されているので、今回これをご紹介していきます。中を見ていきますと、先ほどのPackageセクションの中に、PackageNameとかそういうものが書かれていて、これの場合はgo-1.15というパッケージ名ですと書かれています。その下を見ていくと、PackageFileNameでgo_6715.snapと書いてあるので、snapとして配布されているgoのコンポーネントだというのがわかります。バージョンも下に書いてあります。1.154ですね。

で、ここのセクションはその下もよく見ていくと、snapを提供している提供元の情報が詳しく書かれています。PackageSupplierとして、実際にこれを作った人の名前まで書いてあります。あくまでサンプルですけれど、サプライヤーのOrganizationのところにはCanonicalのMichaelさんが作ったものだよと。実際にこのgoの開発元がどこかというと、OrganizationのところにGoogleの名前が入っています。こういった情報がわかります。その下に、PackageLicenseのところもありまして、GolangのBSD-plusだと書かれています。

熊ケ谷：更にサンプルを読み進めていくと、今度はさっきのgo_6715.snap中に含まれているコンポーネントの情報も書かれています。これgoの実体ですかね。パッケージネームがgoで、バージョンは上と同じですが、1.15.4と書かれています。更にSPDX IDのところにはgo-compilerと書いてあるので、goはgoでもgoのコンパイラが含まれているんだなということまでわかります。下にRelationshipとして依存関係も記載されていて、このコンパイラがさっきの（SPDXIDに）godistと書いてますが、go_6715.snapと書かれているパッケージに依存して含まれてますということが書かれています。実際にSBOMってこんなものだよっていうのがちょっとわかったかなと思います。サンプルは誰でも見れますので、是非見てみていただければと思います。