ソフトウェアを外部の攻撃から守るために　SBOMを使った脆弱性管理の方法1章～3章までを解説

SBOM導入手引きの前半の1章から3章までを解説

渡邊歩氏（以下、渡邊）：飯塚さん、ご講演をお願いいたします。

飯塚智氏（以下、飯塚）：みなさま、お忙しいところご参加いただきましてありがとうございます。あらためまして、私、経済産業省サイバーセキュリティ課の飯塚と申します。

本日、経産省から公表しているSBOM導入手引きの前半の1章から3章について、解説を含めて説明いたします。

さっそくですが、こちらが本日のアジェンダになっています。全部で3つありまして、1つ目の「はじめに」のところでは、経済産業省から出しているSBOMの導入手引きについて簡単に紹介いたします。

2つ目の『ソフトウェア管理に向けたSBOM導入に関する手引』のところでは、1から3章の中身について、主に細かい部分というよりは、どちらかというと概要や目的を中心に、全体感の話として紹介いたします。

そして3つ目は、「ソフトウェアタスクフォースにおける取組」ということで、最新の経産省の取り組み、その後のSBOMの取り組みなどの実証を行っているので、そのへんを紹介いたします。

『ソフトウェア管理に向けたSBOMの導入に関する手引』1.0版

飯塚：さっそく1の「はじめに」についてです。2023年の7月に、経産省が『ソフトウェア管理に向けたSBOMの導入に関する手引』の1.0版を公表しています。

こちらの画面の右下のURLからダウンロード可能ですし、また「Google」などの検索エンジンで「経産省（スペース）SBOM導入手引き」といったキーワードを検索してもらえるとすぐに見つかると思います。

本日参加していただいている方の中には、読んだことがあるよという方もたくさんいるかと思いますが、まだ読んだことがないという方は、ぜひこのセミナーの後でもよいので、ダウンロードして手元で一読していただけますと幸いです。

続きまして、こちらはSBOMの導入手引きの中身の構成を表しています。導入手引きは全体で7章から構成されており、本講演では、1章の「背景と目的」、2章の「SBOMの概要」、それから3章の「SBOM導入に関する基本方針・全体像」を中心に説明いたします。

手引きの主な対象読者は、ソフトウェアサプライヤーにおける開発、あるいは設計部門の方や、製品セキュリティの担当部門の方。そういったソフトウェアのセキュリティに関わるような部門の方々に加えて、セキュリティというのは経営層の方にも認識していただくことが、最近特に重要になってきていますので、経営層の方もご一読いただく読者として想定しています。

また、本手引きの内容はライセンス管理などに関わる部分もあるので、組織の法務・知財部門においても活用してもらえると考えています。全般的な内容については、ソフトウェアを調達する利用企業においても、一部活用してもらうことが可能と考えています。

1章「背景と目的」

飯塚：ここからさっそくSBOMの導入手引きの中身である1章から3章について、それぞれ章ごとに簡単に説明いたします。

まず、1章「背景と目的」ですが、最初にSBOMの中身に触れる前に、セキュリティの事故やインシデント事例について少し触れたいと思います。

こちらは有名なインシデント事例にはなりますけども、2021年の12月頃、Javaベースのオープンソースログ出力ライブラリ「Apache Log4j」における任意コード実行の脆弱性が発表されました。

Log4jが、動作するアプリケーションに対して外部から任意のコードを実行可能になってしまっていて、それによって、情報漏洩やマルウェア感染の被害につながるおそれがあるということでした。

これを受けて、当初はNISCから重要インフラ事業者などへの注意喚起が発出されていて、また、一般向けにも注意喚起が公開されていました。

また、IPAやJPCERTのような専門機関からも、Log4jのバージョンアップ、あるいは回避策を講じることで脆弱性に対処するよう注意喚起もなされていた事例です。

2つ目は、こちらもご存じの方が多いとは思いますが、SolarWindsにおける「Orion Platform」のアップデートを悪用した攻撃がされた事例です。

こちらは2020年の12月頃にSolarWinds社が、同社のネットワーク監視ソフトであるOrion Platformに、正規アップデートを通じてマルウェアが仕込まれたことを公表しました。

こちらは当初、米政府機関などを含む最大約1万8,000の組織が影響を受けたとされていて、大きな影響がありました。

また、攻撃者が関心のある標的に対しては、2段階のマルウェアが投入されていて、資格情報を奪った上で、米政府内、あるいは米政府の政府間のやり取りを傍受していた可能性も、当時は指摘されていた事例です。

さらに、米国の動向ということで、1つ簡単に紹介いたします。米国では2021年の5月に、国家のサイバーセキュリティ改善に係る大統領令ということで、大統領の署名が行われました。

この中で、官民での脅威情報の共有やソフトウェア・サプライチェーンセキュリティ対策の強化、あるいはゼロトラストアーキテクチャへの移行、そういったものを通して連邦政府機関のサイバーセキュリティ対応能力の向上を図っています。

こちらのスライドの左側のほうにある、大統領令における主な指示事項のところの3つ目に、ソフトウェア・サプライチェーンセキュリティの向上があります。

この中では、特にNISTを通じて、政府が調達するソフトウェアの開発に関するSBOMの開示などを含むセキュリティの基準の確立を掲げていて、特に重要なソフトウェアに対して一定の対策を義務づけるということです。

ソフトウェアのサプライチェーンの確保に向けては、NISTが中心になってガイドを策定することを指示していて、ガイドには製品の購入者に対するSBOMの提供に関するような項目も含まれています。

また、将来的にはこういった要求事項に基づいて連邦政府のソフトウェア調達に関する規則が改定される予定です。

経済産業省における取り組み

飯塚：一方で、経済産業省における取り組みも紹介したいと思います。もともと経産省においてSBOMやソフトウェアのセキュリティをどういう体制で、どういう建て付けで検討してきたかについて説明いたします。

そもそもサイバーセキュリティについては産業サイバーセキュリティ研究会WG1の下サイバー・フィジカル・セキュリティ対策フレームワーク、いわゆるCPSFと呼んでいるものですが、こちらを2019年に策定しました。

それに基づいて、セキュリティ対策の具体化あるいは実装を、分野ごとのサブワーキンググループと、分野によらない分野横断のサブワーキンググループにおいて、それぞれ検討している状況です。

この中で、SBOMを含むソフトウェアの脆弱性などの管理手法については、この右図の赤枠で囲ったところですが、分野横断のサブワーキンググループの1つとして、ソフトウェアタスクフォースを立ち上げていて、その中でSBOMに関わるような課題の整理や実証あるいは検討といったことを実施しています。

先ほど、CPSFというキーワードをお話ししましたが、補足すると、Society 5.0の社会において、どのようなサイバーセキュリティを対策していく必要があるのかについて、CPSFというフレームワークを策定しています。

データの流通や活用によってサプライチェーンというものが柔軟で動的なものになると、サイバー攻撃の起点が拡散して、サイバー空間からフィジカル空間への影響が増大してくるので、リスクも増大していきますので、それに対する対策が必要になってきます。

CPSFではサイバー空間、サイバー空間とフィジカル空間のつながり、フィジカル空間の3つの層と、左下にある「ソシキ」「ヒト」「モノ」「データ」「プロシージャ」「システム」、こういった6つの構成要素に分けまして、それぞれの観点からどういうセキュリティ対策が必要なのかを整理して、CPSFというかたちで策定しています。

SBOM手引きの目的と活用方法

飯塚：話をSBOMに戻して、ここではSBOMの手引きの目的と活用方法について簡単に紹介します。

まず目的ですが、1つ目がソフトウェアの管理に向けたSBOMの作成・共有・運用・管理に関するさまざまな課題があるので、それを解決するために、SBOMの概要や導入のメリット、あとはSBOMに関する基本的な情報を提供することです。

2つ目が主にサプライヤー向けにはなりますが、SBOM作成に向けた環境構築や体制整備、あるいは作成・共有・運用・管理に関わるような一連のSBOM導入に向けたプロセスを提示することです。

そして最後に、各フェーズにおける主な実施事項、あるいはSBOM導入に当たって認識しておくべきポイントの提示です。この3点を目的としてSBOM導入手引きを策定しました。

一方、右側には活用方法ということで、SBOMを導入する組織にはSBOMに関する基本情報を認識していただいて、SBOM導入に向けたプロセスを再確認していただければと思っています。

また各フェーズにおける主な実施事項、および導入に当たって認識してほしいポイントも再度確認していただいて、SBOM導入を進めていってもらえればと思います。

最後、SBOM導入手引きの中の付録の7.1では、SBOM導入の各フェーズにおける実施事項をチェックリスト形式としてまとめているので、ぜひそちらをご活用いただきながら、SBOMの導入をする時に参照していただければと考えています。

以上が、1章の背景・目的になっていまして、ここからはSBOMの概要について少し見ていければと思います。

2章「SBOMの概要」

飯塚：SBOMについてはご存じの方も非常に多いとは思うのですが、あらためて簡単に説明します。

SBOMはSoftware Bill of Materialsのことで、その名のとおり、ソフトウェアの部品構成表です。

左下の図は概念図を示していますが、例えばソフトウェアがどういう構成要素から成っているかとか、誰が作ったコンポーネントで、バージョンはいくつか、またそうしたコンポーネントの名称、バージョン、依存関係、そういう各要素を表現したものになっています。

すでに世の中によく出回っている考え方で例えると、食品成分表がイメージとして理解しやすいかなと思うのですが、それのソフトウェア版とよく例えられることがあります。

このSBOMによって、ソフトウェアの構成要素を可視化することが想定されていて、ただ一概にやればいいという話ではなく、他方でまだまだ課題というものも存在していて、SBOMの作成方法や共有のあり方などが主に課題の1つとして存在しています。

例えばですが、SBOMをある方が作って、それをほかの方にどう共有していくか、あるいは提供していくかだったり、サプライチェーン全体を通してどう共有していくかについてはまだまだ課題が存在すると考えています。

右側の図は、SBOMを使った場合にどういう効果があるのかを示しています。これまでのソフトウェアでは先ほどのように部品や要素が可視化されていない部分があることが多いと思います。

そういった場合、ある脆弱性が発覚した時、それが管理しているソフトウェアの中に含まれているのかどうかを手動や目視で確認していたところも多いのではないかと思っていまして、そういった場合には非常に確認作業に時間がかかるという課題があったのではないかと考えています。

この点については、SBOMを活用してあらかじめ部品や要素を可視化しておくことで、ある脆弱性が発覚した時にそれが部品に含まれているのかどうかが即座に認識できるようになります。結果として、脆弱性対応までの時間が短縮できるのが、効果としては大きいのでないかと考えています。

また、これ以外にも、あらかじめ構成を可視化しておくことで、どのようなソフトウェアが使われているかもある程度は可視化できるので、ライセンス管理の活用にもつながっていくのではないかと考えています。

SBOM導入の主なメリット一覧

飯塚：そのほかのメリットは、あらためてこちらに一覧として示していますが、代表的なメリットとしては脆弱性管理やライセンス管理、あるいは開発の生産性向上といったメリットが、大きいところで挙げられるかと思います。

1つ目の脆弱性管理のメリットとしては、脆弱性情報を収集して、SBOMの情報と突合して脆弱性を検出することで、ソフトウェアにおいて脆弱性が残留するようなリスクを低減できるというメリットがあります。

また、先ほど説明したとおり、SBOMを使うことによってある程度リアルタイムで脆弱性を検出して影響を判断できるというようになるので、初動の期間というのを短縮できるという効果もあります。あるいは自動管理をすることによって、手動でそのまま管理する場合と比べて管理コストそのものを低減できます。

また2つ目のライセンス管理のメリットとしては、1つ目がOSSの特定漏れによるライセンス違反のリスクを低減できるということ。2つ目がSBOMツールを用いた自動管理によって、こちらも手動の場合と比較して管理コストを低減できるということです。

開発の生産性向上のメリットでは、コンポーネントに関する問題をSBOMを使って早期に特定しておくことで、開発の遅延発生を防止したり、あるいは対応コストを低減したりすることにつながっていくのではないかということです。

また、使用するコンポーネントを選定する時には類似製品に関する過去のSBOMを参照しておくことによって、選定に関する工数を削減できるといった効果も期待できるのではないかと考えています。

SBOM「最小要素」の定義

飯塚：ここからは基本的な事項のひとつである最小要素について説明します。

2021年の7月に、NTIAから最小要素が公表されています。SBOMは、大きく3つのカテゴリに分類されていまして、1つ目がデータフィールド、2つ目が自動化のサポート、3つ目がプラクティスとプロセスです。

データフィールドのところについては、各コンポーネントに関する基本情報といったものを明確化すること。例えばサプライヤー名やコンポーネント名といったものです。

2つ目の自動化のサポートは、SBOMの自動生成や可読性の自動化をサポートすること。プラクティスとプロセスについてはSBOMの要求、生成、利用に関する運用方法をきちんと定義しておくことですね。具体的には、SBOMの利活用の組織というのは、SBOMの作成頻度ですとか、そのそこの共有などの運用方法を決めておくことといったことが触れられています。

SBOMの最小要素に規定されているとおりですが、SBOMのデータは、機械判読可能でかつサプライチェーン上を流れていくというものを想定しているので、相互運用可能なフォーマットが望ましいわけで、そういったものを作成して共有していくことが求められます。

共通的なフォーマットを用いることで組織内の管理が効率化されるほかにも、組織を越えてSBOMを共有する時の相互運用性が高まって、ひいてはソフトウェアのサプライチェーンの透明性の向上、そういったところに寄与します。

使用され得るSBOMのフォーマットの例として、有名なものですとSPDXやCycloneDX、あるいはソフトウェアIDタグ（SWIDタグ）、こういったものがあります。

こちらの右のところに特徴を書いていますが、ここでは詳細は割愛して、この後一つひとつ説明していきたいと思います。

SBOMを具体的にイメージするためのシナリオ

飯塚：その説明の前に、SBOMをもう少し具体的にイメージしていただくために、こちらはSBOM導入手引きの中にも書いてありますが、想定シナリオについて簡単に説明します。

まず左側の図を見てもらえればと思いますが、登場人物としては4人想定していて、A社とB社、それからC氏という者と、あとはコミュニティP、この4つのステークホルダを想定しています。

具体的なシナリオとして、A社はB社の「Browser」とコミュニティPの「Protocol」という2つのコンポーネントを使用していて、「Application」というソフトウェアを開発していると。

B社のBrowserは、C氏が開発した「Compression Engine」のコンポーネントを使用していて、B社は、Browserに関するSBOMを自社で作成してA社に共有している。ただし、C氏とコミュニティPのコンポーネントに関するSBOMの情報を取得できていなかったので、A社でC氏とコミュニティPのコンポーネントのSBOMを作成しているという状況になっています。

今度は右の図で見ていただければと思いますが、こちらは今のシナリオを概念的にSBOMのようなイメージで表現したような表です。

こちらは各コンポーネントについて、サプライヤーとかバージョン、コンポーネント間の依存関係やSBOMの作成者、そういったものを一覧化しているものです。

SBOMによって、各コンポーネントがいつ誰によって開発されているかとか、ほかのコンポーネントとどういう関係性があるかとか、当該コンポーネントに関するSBOMが誰によって作成されたか、そういったものを特定・管理することが可能です。

特定のコンポーネントの脆弱性が明らかになった時に、その脆弱性の影響を受けるコンポーネントが含まれているのかを、即座に認識できますし、それによって脆弱性に対する対応というのも迅速に行えます。

先ほど冒頭で説明したとおり、SBOMが組織を越えて相互運用、相互共有されることで、各コンポーネントに関する情報が可視化されますので、ソフトウェアサプライチェーンの透明性が向上することに寄与できるのではないかと思います。

SPDXの詳細

飯塚：ここから一つひとつSBOMのフォーマットについて説明します。まずはSPDXの内容に関してです。

SPDXは、Linux Foundationの傘下のプロジェクトで開発されたSBOMフォーマットで、2021年の9月にはISO化され、国際標準化されています。

SPDXのSpecificationに従って作成されたコンポーネント、ライセンス、コピーライトなどの情報が記載されていて、Tag-Value形式など、さまざまな形式がサポートされています。

先ほど説明した簡易シナリオにおいて、Tag-Value形式のSPDXのフォーマットを用いて、A社がSBOMを作成した場合のSBOM作成例の概念図が、左下の図です。SBOMの作成例です。

左の図の中に、さまざまな色がありますが、SBOMの概念的なイメージと実際のSPDXフォーマットにおける項目との1対1の対応を表しています。

また、右側の表を見ていただければと思うのですが、SBOMの最小要素の各項目に対して、SPDXのフォーマットの各項目は対応可能であるということを示しています。

SPDXはOSSのライセンスコンプライアンスに関する情報を効果的に扱うために開発されたというのが、もともと発端でのフォーマットでして、ファイルのレベルまで構造化して、詳細な情報を表現できる点が特徴として挙げられるかと思います。

また、対象となるコンポーネントについてスニペット、ファイルとかだけではなくてパッケージ、コンテナ、OSディストリビューションまで拡張することが可能です。

SPDX-Liteの詳細

飯塚：続いてSPDX-Liteです。SPDXの仕様の一部としてWebサイトなどで公開されています。このSPDX-Liteは、SPDXの項目のうち必要最小限の項目のみを含んだ日本発のフォーマットです。今日は時間の関係上、こちらの詳細は割愛します。

CycloneDXの詳細

飯塚：続いてCycloneDXです。CycloneDXはセキュリティに特化したSBOMフォーマットの標準を開発するということを目標として、OWASPのコミュニティのプロジェクトによって開発されたSBOMフォーマットです。

CycloneDXフォーマットによるSBOMではコンポーネント、ライセンス、コピーライトなどの情報が記載されています。JSONやXMLやProtocol Buffersなどの形式がサポートされています。

先ほど説明した簡易シナリオにおいて、XML形式でCycloneDXフォーマットを用いてA社がSBOMを作成した場合の例を左側の図で示しています。

また右側の表は、SBOMの最小要素の各項目に対してCycloneDXフォーマットの項目も対応可能であることを示しています。

2022年にリリースされたCycloneDX Version 1.4では、オブジェクトモデルにVulnerabilitiesが追加されていて、SBOMに含まれるサードパーティソフトやOSSに存在する既知の脆弱性、脆弱性の悪用可能性を記述できるようなフォーマットになっています。

こちらもSPDX同様、ツールで自動処理をすることを目的にしているフォーマットです。

SWIDの詳細

飯塚：最後に、ソフトウェアIDタグ（SWID）の説明をします。こちらは組織が管理対象とするデバイスにインストールされたソフトを追跡することを目標として開発されたものです。2012年にIOSで定義されて、2015年にはそれが更新されました。

こちらのSBOMでは、ソフトウェアIDのタグに従って作成されたデバイスにインストールされたソフトウェア、あるいはソフトウェアに適用したパッチなどの情報が記載されて、XMLの形式がサポートされています。

先ほど説明した簡易シナリオにおいて、XML形式のソフトウェアIDタグを使ってA社がSBOMを作成した場合というのが、左側の図に示しているものです。

右の図は、SBOMの最小要素の各項目に対して対応できる内容です。ソフトウェアIDタグは、ソフトウェアの識別に関するフォーマットですが、コンポーネント、ライセンスの情報、パッチ、アップデートに関する情報、脆弱性、あるいは脅威に関する情報などセキュリティに関する情報も含めることができます。

SBOMに関する誤解と事実

飯塚：ここまでで、一つひとつSBOMのフォーマットについて見てきましたが、ここからはよくあるSBOMに関する誤解と事実について紹介します。手引きの中にも事例がたくさん載っていますが、ここでは時間の関係上、いくつかに絞って説明したいと思います。

こちらは、米国のNTIAなどが発表した文書や経産省の実証を踏まえて整理したものです。

例えば1つ目として、一番上に記載されている誤解は、対象ソフトウェアが直接利用しているコンポーネントのみをSBOMの管理対象とすればよい、という誤解です。

事実としては、対象ソフトが直接利用しているコンポーネントだけではなく、そのコンポーネントが再帰的に利用するコンポーネントについても把握しておく必要があり、そうしないと脆弱性対応が不十分であるという可能性があるということです。

どの階層のコンポーネントまでSBOMを作成するのかという、いわゆるSBOMの深さという点に関しては、まだ有識者による議論がされているというところが事実かなと思います。

2つ目の例として、これも一番上の記載に注目していただきたいのですが、「SBOMツールが出力したすべての脆弱性に対応する必要がある」という誤解があります。

事実は、SBOMツールが出力した脆弱性に関する結果を踏まえて脆弱性へのリスク対応を行う際、脆弱性の影響範囲やリスクの評価結果、対応するコストなどの優先度を踏まえた脆弱性対応が必要です。

この際、必ずしもすべての脆弱性が利用可能ではなくて、影響を受けないような脆弱性も存在し得るということにも留意する必要があります。

以上が2章の内容です。ここからは、3章の全体方針や基本方針について説明します。

3章「SBOM導入に関する基本方針・全体像」

飯塚：まず、基本方針を説明しますが、SBOM導入の目的に応じて、作成するべきSBOMの項目やフォーマット、作成範囲、共有範囲、SBOMの適用範囲は大きく異なります。

SBOMを導入する組織は、まずSBOM導入によってどういった課題を解決したいのかなど、ソフトウェアの管理に関する自社の課題をきちんと整理することが大事です。その上でSBOMの導入の目的を明確化し、作成・運用・管理していくことが求められます。

下側に例ということで記載していますが、例えば膨大な数のコンポーネントが存在するような大規模な製品においては、コンポーネントの依存関係を含めたSBOMを作成し共有するという目的があった場合に、有償のSBOMツールを使って作成・管理するというのも、1つとして想定され得ます。

あるいは別の例として、コンポーネントの数が膨大ではない小規模な製品について、最低限の項目のみ作業でコンポーネントのバージョンを管理したいという目的であれば、もう少し簡易なSPDX-Liteフォーマットを使ってSBOMを作成することも想定され得ます。

SBOM導入のプロセス

飯塚：続いて全体像ということで、こちらには導入に関するプロセスを記載しています。SBOM導入に関しては主に3つのフェーズに分けることができると考えています。

1つ目がフェーズ1の環境構築・体制整備です。1－1の「SBOM適用範囲の明確化」は、SBOMを作成する対象のソフトに関する情報を整理することが重要で、その結果を踏まえてSBOMの適用の範囲も明確化していきます。

1－2の「SBOMのツールの選定」は、選定する時の観点、それに基づいたツールの評価を行い、選定を行うということです。1－3の「SBOMツールの導入の設定」では、環境要件の確認や取扱説明書などがあれば確認して、導入や設定を行っていきます。

1－4の「ツールに関する学習」では、学習して得られたノウハウは、組織内でもきちんと共有していくことが大事です、ということが述べられています。

フェーズの2のSBOMの作成・共有フェーズについては、コンポーネントの解析やSBOMの作成、SBOMの共有について述べられています。

また、フェーズ3はSBOMの運用・管理フェーズで、SBOMに基づく脆弱性管理、ライセンス管理などの実施、あるいはSBOM情報の管理について述べています。

以上が、1章、2章、3章、導入の手引きの説明でした。最後に経済産業省が実施しているソフトウェアタスクフォースの取り組みとして、最新のSBOMの実証や検討状況について紹介します。

（後半につづく）