SBOM導入で企業にはどんなメリットがあるか？　経産省発行「導入に関する手引ver 2.0」の解説

経産省がまとめたSBOMの資料を読み解く

鈴木康弘氏：初めまして。yamoryのプロダクト責任者をしております。Software ISACのOSS委員会でも、オープンソースやSBOMに関連する普及活動にも取り組んでいます。

大勢の方にお集まりいただきまして、誠にありがとうございます。今日は経産省が新しく出した「SBOMの導入に関する手引ver 2.0」に関する解説セミナーです。

こちらは、1ヶ月ぐらい前に出されたものになっていますが、端的に言うと、経産省がSBOMを普及させていくためのポイントがまとめられている資料です。



最近、さまざまなサイバーセキュリティレギュレーションの中でSBOM対応が非常に求められる時代の流れになってきていまして、実は国内のレギュレーションの中でも、こちらの資料が参照先になっています。

国内唯一のSBOMに関連する公的なドキュメントになっております。基本的なところから応用まで、ver 2.0で幅広く捉えられるようになった印象です。

全体を通して167ページという大作資料になっていまして、これをすべて読み込むのは、普通の方にとってはかなり難しい分量だと思います。

概要を私から説明しますので、みなさんには概要を理解して、今後取り掛かる上で「こういうポイントがあるんだな」と押さえていただくセミナーになればいいなと思っていますので、ぜひともご視聴いただければと思っております。

今日の資料は、経産省のページから引用しました。8月29日に改訂を行って、ver 2.0が出ました。関連資料に、本家本元のPDFファイルや概要資料、チェックリストが載せられていますので、大本を参照したい場合はこれらの資料を見ていただければと思います。

では、さっそくアジェンダに入っていきます。まず、この「導入に関する手引」ですが、どういう背景、どういう目的で、出されているものなのか。ver 1.0、ver 2.0の位置付けを押さえます。


次に、1年前から出ているver 1.0は簡単におさらいしますが、ver 2.0で新しく追加されているところが今日の本題になります。

ver 2.0は応用編というか、実際に出てくる課題に対するプラクティスが多いセクションになっていますので、高度な内容になるケースだと思います。最後に簡単に「yamory」の紹介もさせていただきます。

脆弱性管理にSBOMが注目を集めている

では、さっそく導入のドキュメントの目的・背景から説明していきます。

SBOMに関連するところで言うと、ソフトウェアのサプライチェーンが複雑化してきていまして、オープンソースも一般的に普及しています。ソフトウェアにおいてのリスク管理、脆弱性、ライセンスの管理が重要性が高まってきておりまして、その一つの手法としてSBOMが注目を集めてきています。

実はこのドキュメントが作られる前に、各産業分野において実証実験されていまして、その成果も確認できたのでドキュメントが作られた背景になっています。

経産省はセキュアなソフトウェアの流通を促進するために、1年前にver 1.0を作りました。そういった位置付けで始まっています。

ver 1.0とver 2.0で何が違うのか、本家資料の目次の部分を比較すればわかります。ver 1.0は、6章に分けて目的や概要が書かれています。ver 1.0では基本的なSBOMに関する情報や、導入に関するフェーズごとのポイントがまとめられています。


ver 2.0では7章以降が書かれているかたちです。付録がボリューミーなんですけど、7〜9章が追記されている内容になっています。ソフトウェアの脆弱性管理の時の具体的な考え方やプラクティスをまとめていきます。

後ほど出てきますが、SBOM自体が単独の企業で活用するよりは、サプライチェーンの中で相互運用されるところが一つの目的になっていますので、その際の対応や取引のモデリングまで踏み込んで言及されているのが、アップデートされた内容になっています。

このドキュメントに関する対象者は、基本的にはソフトウェアパッケージの開発や運用をしたり、組込みのソフトウェアなどのソフトウェアサプライヤーの方々が基本的な対象者として書かれています。ソフトウェア開発や設計の部門、製品セキュリティの担当であるPSIRTなどの部門、それらの上位組織である経営層も対象です。法務や知財部門にも関係があるので、対象読者に設定されています。

ver 1.0の振り返りについて

では、簡単ではありますが、ver 1.0と（ver2.0）のアップデート内容を簡単にまとめさせていただいております。ボリュームがありますので、ver 1.0の内容のおさらいから入っていきたいなと思います。こちらのスライドの内容は、経産省がホームページで出している概要ドキュメントになります。こちらを見ると、ver 1.0の内容が包括されている印象です。


出典元：経済産業省『ソフトウェア管理に向けたSBOMの導入に関する手引Ver2.0』

目的や導入のメリット、導入に向けたプロセス、各フェーズごとのポイントがまとまっていたのがver 1.0です。そこを細かくもう少し深掘りして、振り返りたいなと思います。

今日の参加者の方々は、すでにかなりSBOMの導入が進んでいる方々もいれば、SBOMの勉強から始めたい方々もいらっしゃると思います。「SBOMとは」からver 1.0のセクションを振り返らせていただきます。

SBOMとは、ソフトウェアコンポーネントの依存関係の情報を集めた機械処理可能な一覧リストです。部品表と言われることも多いですが、部品表かつ機械処理可能な一覧リストという認識を持っていただけるといいなと思います。


出典元：経済産業省『ソフトウェア管理に向けたSBOMの導入に関する手引Ver2.0』

ここに一例がありますが、例えばA社が、最終製品としての何かのアプリケーションを作っています。そのアプリケーションの中で、ソフトウェア部品として一つのプロトコルの実装やブラウザを使っています。

その中で、ブラウザのエンジンを使っている時に、この一つのアプリケーションは複数のソフトウェアのコンポーネント、部品を組み合わせて使いながら、成り立っています。そのソフトウェアの部品の構成表をSBOMというかたちで作って、ソフトウェアの利用者などに流通させています。

途中のサプライチェーンのサプライヤーのB社の方々も、A社に「このブラウザの中にはこういうものが入っている」と伝えるSBOMを作って、この最終製品の中に組み込んで納品するプロセスになります。

この部品表の簡単な概念のイメージも、ドキュメントの中に書かれていますが、サプライヤー名のところにA社があって、コンポーネント名というかソフトウェア名に「Application」やバージョンなどが書いてあります。

その下に部品表のリストがあって、B社が作った「Browser」もバージョンが入っていたり、Cさんが作ったものや「Community P」が作った「Protocol」があったりします。簡単に言うと、会社やソフトウェア名称、バージョン、どういったものを部品として使っているのかがしっかり書かれている部品表というイメージになります。

SBOMを食品表示の概念で理解する

このドキュメントの中では、いろいろ小難しいことばかり言っても飽きられてしまうので、おもしろい表現でコラムをまとめて書いてくれています。

一つおもしろい例があったので、持ってきています。「SBOMと食品表示のアナロジー」というコラムがありました。食品も、例えば原材料でどんなものを使っているのかがしっかり最終消費者に伝わるようなかたちの食品表示があります。


出典元：経済産業省『ソフトウェア管理に向けたSBOMの導入に関する手引Ver2.0』

この食品を食べる最終消費者の方がリスクを判断できるように、どういったものが入っているのかがわかるかたちで書かれています。アレルギーの方が食べられないものを認識できてリスクを避けることができます。

SBOMでも、同じようなことが言えまして、サプライチェーンがいろいろ複雑な場合に、混ざっているソフトウェア部品にリスクがあるのかなどの評価をしなければいけないので、SBOMをしっかり作っていく流れになってきております。

実はこのドキュメントの中には、これ以外にもたくさんのコラムがあるので、興味を持ってもらえると思います。

話を戻しますと、こういう概念的なSBOMのモデルのイメージであると伝わったかなと思います。

導入メリットは脆弱性のリスクが管理できること

導入するメリットが具体的に何なのかも、こちらに書かれています。まず一つは、リスク管理の側面で、脆弱性管理に活用できます。どんなコンポーネント、ソフトウェア部品に脆弱性のリスクがあるかを確認することができます。


出典元：経済産業省『ソフトウェア管理に向けたSBOMの導入に関する手引Ver2.0』

また、ライセンス管理のメリットですが、オープンソースが一般的に普及されてきていますが、オープンソースのライセンスを見ていくと、これはなかなか商用では使うことが難しいライセンスも存在しています。

ウイルスなどが入り込んできてしまっていないか、リスク管理も行えるメリットがあります。すごく重大なリスクが早期にわかって、開発生産性の向上のメリットもあると、説明されています。


出典元：経済産業省『ソフトウェア管理に向けたSBOMの導入に関する手引Ver2.0』

こういった観点で、リスク管理の側面で、脆弱性管理やライセンス管理のメリットもあります。そもそも、どんな部品が使われているのかがしっかり把握できるようになるメリットも、ベースとしてはもちろんあるかなと思います。

このサンプルだと、4つか3つぐらいのコンポーネントしか書かれていませんが、通常のソフトウェアを現在開発した場合、さまざまな数百個のソフトウェア部品に依存するみたいなことが普通に増えてきています。

そうなると、しっかり管理していないと訳がわからなくなってくるので、そもそもリストアップしていること自体が、資産管理側面で大切になってくるかなと思います。

データフィールドの必要性

このドキュメントの中には、メリットの次に最小要素の説明も書かれています。かなり有名なものになりますけども、大統領令があった後に、米国のNTIAという省庁がSBOMの最小要素を定義して公表しました。


出典元：経済産業省『ソフトウェア管理に向けたSBOMの導入に関する手引Ver2.0』

その最小要素の中で言われているのは、データフィールドが必要ということです。こういうデータがないといけないということ、自動化のサポートがないといけないこと。データを相互運用するので、機械読み込み可能なフォーマットじゃないとSBOMとは言えないと定義しています。あとは、プラクティスやプロセスをしっかり構築していくべきと言われています。

具体的なデータフィールドに必要な情報は、会社名、サプライヤー名、コンポーネント名、コンポーネントのバージョン、一意の識別子、依存関係です。依存関係は、この下でこのソフトウェアが使われている情報ですね。他に必要なのはSBOMの作成者と、いつSBOMが作られたかのタイムスタンプですね。


出典元：経済産業省『ソフトウェア管理に向けたSBOMの導入に関する手引Ver2.0』

こういった最小要素が定義された上で、SBOMのフォーマットもいくつか出てきています。その代表例3つをこのドキュメントの中で共有しています。

先ほどの例だとここがありますが、一つはSPDXというフォーマットがあります。SPDXにはいろいろな形式があるんですが、例となっているのが、Tag-Value形式という、TagとValueが一体になっている形式です。そのほか、XMLの形式やJSON形式も書かれています。


出典元：経済産業省『ソフトウェア管理に向けたSBOMの導入に関する手引Ver2.0』

もう一つ、有名なのがCycloneDXです。XML形式でサンプルとして書かれています。


出典元：経済産業省『ソフトウェア管理に向けたSBOMの導入に関する手引Ver2.0』

人の目からはこのXMLやJSONにすると読みにくいかもしれませんが、機械読み込みが可能なところが重要なポイントなので、こういったフォーマットもあると理解していただければと思います。

もう一つ、Software Identificationタグという形式もあります。この3つが、国際的によく評価される標準フォーマットになりつつありますけど、有名なのがSPDXとCycloneDXになるかなと思います。

このドキュメントの中でフォーマットに関する誤解が書かれていました。SBOMフォーマットとして、SPDX、CycloneDX、SWIDタグがありますが、そのフォーマット以外のSBOMは認められなかったり、誤解もあったりします。

ただ、これらに則していなくても、最小要素など、自動化がサポートされているものがあればSBOMとして認められますので、一つ誤解があるポイントかなと考えました。ここだけピックアップさせていただきました。

SBOM導入には3つのフェーズがある

SBOMを初めて聞いた方向けに、この概要の部分も共有させていただきましたが、この後にSBOMの導入に向けたフェーズのポイントがver 1.0のセクションでは共有されています。

ただ、分量が多いので、個別に説明していくとかなり時間が限られてしまうので、このサマライズされたものをベースに、共有させていただきます。

出典元：経済産業省『ソフトウェア管理に向けたSBOMの導入に関する手引Ver2.0』

SBOMの導入を検討する時に、1、2、3というフェーズに分かれます。フェーズ1では、まず環境構築や体制を整備していきます。フェーズ2では、SBOMを作成して共有していきます。フェーズ3では、実際に定期的にSBOMを運用と管理していきます。

この各フェーズごとにしっかり考えていかなければいけないポイントがあります。導入の手引として、フェーズごとのポイントが定義されて紹介されているのがver 1.0のセクションになっています。

フェーズ1ではSBOMの適用範囲を明確にしていきます。ソフトウェアもいろいろ幅広いものがあると思いますので、すべてをいきなりやることは難しいです。

SBOMのツール選定で大切なこと

レギュレーションの中でも、まずここだけしっかりやると明確化されている場合は、そこがどういうところなのかと見るべきです。まず自分たちのソフトウェアについてはどこが当たるのか、要求事項をしっかり見ていきます。

開発されているソフトウェアの言語や構成ですが、自社で開発されている場合は自社で作ればいいんですが、それを開発委託している場合があります。そうしたらSBOMを作ってもらわないといけなくなります。

そういった要求事項から自分たちが置かれている状況などを整理して、どういったところをまず適用範囲にしていくのか。バクッと全体というよりは、やる部分を明確化していくのは、フェーズ1の中の1項目ですね。

その適用範囲が明確になってくるとツール選定がやりやすくなります。ツールは、得意・不得意分野がある感じなんですよね。なので、この領域については、安いツールでいけるか、高いツールを買うかを考えなければいけません。その適用範囲の要件に基づいて、必要十分な機能群が揃っているかを判断します。

外資系のツールも多いので、インターフェイスがわかりにくかったり、サポートがすべて英語ということもありえます。サポート体制や日本語対応等の観点から見ていくといいと書かれているのがフェーズ2です。

ツールの候補がいくつか出てきたら、導入をテストしていくのが3番目ですね。要は検証なんですが、SBOMツールを導入可能な環境でテストしてみましょう。実際に設定してみたり、取扱説明書って書かれていますけど、ドキュメントを見て、ツールを具体的に動かしてみたりするのが3つ目です。

4つ目が、それが適用範囲に全体適用できるのかを判定したり、使い方を習得したり、組織に共有していくことですね。

SBOMを作成していくフェーズ2へ

このSBOM導入に向けたプロセス、ver 1.0のセクションについては、基本的にはツールを基本的には選定して、ツールを入れて導入していって、それに基づいて対応していくことが基本的に多い印象です。

もちろん、初めは手動でやってもいいんですよ。ですが、ツールを使うことが便利なのでツールの導入がプロセスになっています。

このようにフェーズ1が終わると、範囲が決まってだいたいツールの良し悪しもわかってくるかたちになって、フェーズ2に移ります。実際に適用範囲すべてに当てはめて作成していき、コンポーネントを解析してSBOMを作成していくフェーズに入ります。

その際にも、ツール等を使って、対象のソフトウェアのスキャンを行って、当初想定したコンポーネントが正しく検出できているかを判断する必要があります。

また、パッケージマネージャーという構成管理ツールを使うことで、SBOMツールが対応できるケースがありますので、必要であれば導入の検討もするといいと書かれています。

スキャンが終わると、SBOMが作成できる状態になっていますので、SBOMを実際に出力してみて、フォーマットや出力形式が要件に合うかを確認していきます。最後にサプライチェーンの下流の方々に向けて、情報提供して共有できるかを確認していきましょう。

フェーズ3はしっかりとしたSBOMの利活用

SBOMの運用フェーズであるフェーズ3です。SBOMは1回作って終わりではないですし、しっかり利活用しなければいけません。利活用するポイントとしては、先ほど言ったように脆弱性管理やライセンス管理、リスク管理の側面でも使っていくところです。

基本的にはツールを入れるとなると出力結果に脆弱性の検出結果も出てくるケースが多いので、そこがしっかり対応できるかどうかを判断したり、ツールによってはオープンソースのライセンスリスクも検出できるものもあったりしますので、そこも確認していきます。


出典元：経済産業省『ソフトウェア管理に向けたSBOMの導入に関する手引Ver2.0』

SBOM情報を定期的に管理していくところですが、SBOMはソフトウェア開発が1回で終わることはなかなかありません。アップデートを繰り返していきます。その中で構成部品もバージョンごとに変わっていきますので、どう管理していくのかを決めて対応していくことが問われます。

自動で脆弱性情報が通知される仕組みなども考えていきましょう。こういったことがフェーズ3に書かれている内容になっています。サマライズされた表をベースに、おさらいというかたちで各フェーズでやることをラップアップさせていただきました。

ver 1.0の内容については、導入のポイントを解説しているセクションになりますので、この1、2、3のフェーズに従ってポイントがあります。

SBOMをこれから導入するフェーズにいる企業さまの場合は、ver 1.0のセクションを参考にしながら、まずツール選定してみたり、実際に動かし始めてみたりしましょう

すべて一気にやるのはなかなか難しいので、適用範囲をまず絞って、やってみることから始めるといいと思います。その際にここのセクションをもう1度見て、ポイントをおさらいしておくといいと思います。ver 1.0のおさらいの部分はこちらで終わりにさせていただきます。