脅威インテリジェンス

Cyber Intelligence

Intelligence

Log4j

SBOMとは？　日本でも重要な理由と作り方、活用方法

Tamura

2022.11.22

2022年に入ってから、日本のセキュリティ業界でも「SBOM」という言葉を頻繁に聞くようになりました。「そもそもSBOMとは何か」「なぜ注目されているのか」「日本でも必要なのか」「SBOMの作成を求められたら、どうすればいいのか」。今回の記事では、そうしたSBOMをめぐる問いに答えていきます。

この記事の要点

・SBOMとは、ソフトウェアを構成する各部品や、部品同士の関係を一覧にした技術的資料のこと。2021年の米国大統領令や脆弱性「Log4Shell」をめぐる騒動などをきっかけに、米国をはじめ、日本国内でも注目されている。

・日本では、自動車・医療業界の一部企業が実際にSBOMの活用を始めている。経済産業省も、SBOMの有効性や課題を評価するための実証に向けて議論を進めている。少なくとも現時点では、こうした政府や業界の動向を注視していくことが必要。

・SBOMを作る主体は「ソフトウェアやソフトウェアシステムを作成、修正、一括販売、納入する、すべての組織」。作成には工数がかかるので、マシンリーダブルなフォーマットや自動化ツールを用いながら、効率的に作るのが一般的。

・SBOMの目的は完成させることではなく、コンプライアンスリスクへの対処や、脆弱性の特定や評価に活用すること。脆弱性管理にSBOMを活用するなら、SBOMとは別に脆弱性データベースも必要。

[開く][閉じる]

SBOMの基礎知識

そもそもSBOMとは？

SBOM（Software Bill of Materials）とは、ソフトウェアを構成する各部品や、部品同士の関係を一覧にした技術的資料のことです。読み方は「エスボム」で、「ソフトウェア部品表」などと訳されます。

ソフトウェア開発では、開発者が自ら書いたプログラムだけでなく、他の誰かが開発したプログラムを部品として取り入れることが当たり前になってきています。これには、無償で誰でも利用可能なオープンソースソフトウェア（OSS）やプロプライエタリソフトウェアなどがあります。

他人の開発した部品を借用するメリットとしては、ソフトウェアのすべてを自分で一から開発する必要がなくなり、ソフトウェア開発の効率を上げられるという点が挙げられます。一方で、デメリットもあります。例えば、無償で使えるOSSにも、さまざまな約束事＝ライセンスが存在し、意図せずライセンス違反を犯してしまうリスクがつきまといます。また、OSSに脆弱性（＝情報セキュリティを脅かす欠陥）が見つかってソフトウェア全体にリスクが及ぶ場合があります。これらのリスクを軽減するために、ソフトウェアの部品を把握・管理するためのリストであるSBOMが活用されます。

なおSBOMは、ソフトウェア開発者がリスクを特定するために利用できるほか、選定・購入する側がリスクを評価するためにも活用できます。

表1：SBOMから読み取れる情報のイメージ（米NTIAの資料（p16）[*1]より筆者作成）

SBOMが注目される理由

2022年に入ってから、日本のセキュリティ業界でもSBOMという言葉を聞く頻度が増えてきたように思います。SBOMが注目される主な要因には、次の2つが挙げられます。

①2021年5月：米国の大統領令

バイデン米大統領は2021年5月12日、サイバーセキュリティ強化のための大統領令に署名しました。この大統領令の中の「ソフトウェア供給網（サプライチェーン）のセキュリティ改善」（Section 4）という項でSBOMが言及されたことが、注目を浴びたきっかけの一つです。

翌年の2022年9月14日には、米行政管理予算局（OMB）が、連邦政府機関の調達するソフトウェアのセキュリティ要件を定めるガイダンスを発表しました。このガイダンスは上記の大統領令に基づいて作成されたものです。ガイダンスのもと、各政府機関は調達するソフトウェアを公募するにあたって、応募要件としてSBOMに関する詳細の提出を求めることができます。このように、大統領令による米国政府のソフトウェア納入業者への影響が現実的なものとなってきています。

②2021年12月：脆弱性「Log4Shell」をめぐる騒動

2021年末、オープンソースライブラリのApache Log4jに重大な脆弱性（CVE-2021-44228、通称「Log4Shell」）が存在することが発覚し、世界中のセキュリティ関係者の間に激震が走りました。激震の理由としては、

①この脆弱性が重大なセキュリティリスクにつながるものだった

②この脆弱性が簡単に悪用できるものだった

③Apache Log4jは、非常に多くのソフトウェアの部品として利用されていた

の3点が挙げられます。さらに③に関連して、脆弱なApache Log4jがそもそも自社製品に含まれているのかどうかが、分からないベンダーが多かったことも大きな問題でした。2021年11月30日に最初に公表されてから数か月経ってもなお、自社ソフトウェアに関するアドバイザリや修正プログラムの公表を続けるベンダーが後を絶ちませんでした。

このように、Log4Shellをめぐる騒動をきっかけに、OSSの利用に伴うセキュリティリスクと、リスク管理の難しさが広く認識されるようになりました。

SBOMをめぐる日本国内の動き

上の①で触れた米大統領令の影響を受けるのは、あくまで米国政府にソフトウェアを納入する事業者であり、日本企業には直接の影響がないようにも見えます。しかし、OSSの利用に伴うセキュリティリスクは、日本企業にも関係してくる話です。日本でも近年では、自動車・医療業界の一部企業が実際にSBOMの活用を始めています。また経済産業省は、SBOMの有効性や課題を評価するための実証に向けて議論を進めています[*2]。少なくとも現時点では、こうした政府や業界の動向を注視していくことが必要でしょう。

表2：国内の主な取り組み

2017年〜：OpenChain Japan WG（企業有志の取り組み）
OpenChainプロジェクトに参加する日本国内の企業が日本語で議論する場を作ることを目的に、2017年に設立。2022年3月現在、OpenChainに関する文書やSPDX仕様（後述）の翻訳、OSSの管理や透明性向上に向けたOSSマネジメントに関するスキル標準作成等の活動を実施中[*2]。
2019年〜：経済産業省など
2019年に経済産業省が、サイバー・フィジカル・セキュリティ確保に向けたソフトウェア管理手法等検討タスクフォースを設置[*3]。
同タスクフォースは2021年4月から、OSSの管理手法等に関して参考になる取組を実施している企業へのヒアリング等の結果を取りまとめた事例集を公開。2022年版も公開済みで、実際にSBOMを活用している日本企業の事例などが紹介されている。

SBOMの作り方

では、SBOMを作成するとは、具体的にはどんな作業なのでしょうか。以下、米大統領に対して電気通信と情報政策に関する助言を行う商務省電気通信情報局（NTIA）が公表した資料[*1][*4][*5]を主な参考資料としながら、解説していきます。

誰が、いつ作るのか？

NTIAは、「サプライヤー（supplier）」がSBOMを作成するとしています。「サプライヤー」としてみなされるのは、ソフトウェアやソフトウェアシステムを作成、修正、パッケージング（一括販売）、納入する、すべての組織です。

SBOMを作るタイミングとしては、ソフトウェア開発プロセスの中でソフトウェア⾃体と⼀緒にSBOMを作成することが最も効率的です。また、部品が新たにリリースされる度に、新しいSBOMを作成するのが望ましいとされています。部品自体に変更がなくても、部品に関する情報が変更・アップデートされたら、SBOMを作成・アップデートすべきということです。

どんな情報を盛り込むか

NTIAは、SBOMに盛り込むべき情報についても公表しています。とりわけ、以下の「Baseline Component Information」（基本部品情報）と呼ばれる情報は、最低限必要とされています。その他、利用目的に応じて「部品のサポート終了日」「部品が実装もしくは対応しているテクノロジー」などの情報が必要になる場合もあります。

表3：Baseline Component Information（NTIA, “SBOM at a Glance”より筆者作成）

Author Name
作成者名＝SBOMに情報を記載した人の名前
Supplier Name
サプライヤー名＝部品を供給する者の名称
Component Name
コンポーネント名
Version String
バージョン
Component Hash
コンポーネントのハッシュ値
Unique Identifier
識別⼦
Relationship
関係

NTIAは、Baseline Component InformationをはじめとするSBOMの概要をまとめた資料「SBOM at a Glance」（一目でわかるSBOM）を公表しています。この資料については、JPCERT/CCによる日本語訳版[*4]も公開されています。

主なフォーマットは3種類

SBOMの主なフォーマットには、「SPDX」「Cyclone DX」「SWIDタグ」の3つがあります。いずれも、マシンリーダブルな（機械によって容易に処理できる）フォーマットであり、NTIAの調査結果（既存のSBOMフォーマット・規格に関する調査結果（2021版）[*5]）の中では「幅広く利用されているフォーマット」として取り上げられています。ちなみに、弊社が提供する脆弱性インテリジェンスツールVulnDB（後述）は、Cyclone DXに対応しています。

画像1：SBOMのイメージ。以下はCyclone DXを使ったSBOMの一例（出典：Cyclone DX）

ここでは各フォーマットの細かな違いには立ち入りませんが、各フォーマットはそれぞれ異なる背景のもと設計されたものです。NTIAは特定のフォーマットを推奨することはせず、ユーザーは各自のニーズに合うものを選ぶべきとしています。また、重要なのは「どれが一番優れたフォーマットか」ではなく、「どのフォーマットで作ったSBOMも役に立つ」ことです。NTIAによると、各フォーマットは相互運用の可能性を秘めているとのことです（下表）。

画像2：SPDX、Cyclone DX、SWIDタグの対応表。各フォーマットが「Baseline Component Information」をどのように表現しているかを示している。（出典：NTIA（p19）[*5]、赤字は筆者）

SBOM作成の自動化ツール

以上、SBOMに含めるべき情報と、SBOMのイメージをお伝えしました。SBOMは、手作業で作成することも可能です。ただし、1つのソフトウェアには多数の部品が含まれ、それら各部品に、さらに部品が含まれることがあります。これらすべてについて、Baseline Component Informationを盛り込むだけでも、相当な工数が必要です。まして、SBOMの目的は完成させることではなく、完成したものを使って脆弱性などの特定や対処の優先順位づけに利用することです。よって、SBOMの作成を手作業で行うのは現実的ではなく、一般的にはSCA（Software Composition Analysis）と呼ばれる自動化ツールが使われます。また自動化のためには、上記のマシンリーダブルなフォーマットに従う必要があります。

SBOMをセキュリティにどう活用するか？

図：SBOMをめぐる各工程と各種ツールの関係（筆者作成）

ここまでは、SBOMの作り方の話でした。ここからは情報セキュリティにおけるSBOMの活用方法についてです。

冒頭で述べたように、SBOMは脆弱性に関するリスクを特定するために活用できます。SBOMの中に脆弱性情報を盛り込んで、顧客に提供することは可能です。ただし、SBOMが特定の時点におけるソフトウェアの属性を反映したものであるのに対し、脆弱性データは時とともに変化します。こうした背景からNTIAは、基本的に「SBOM内の脆弱性データを完全かつ最新だと決めてかかってはならない」としています。また、「脆弱性データを、SBOMとは別のデータストラクチャ内で監視すること」を推奨しています[*6]。脆弱性管理にSBOMを活用するなら、SBOMとは別に脆弱性データベースも必要だということです。

脆弱性の情報ソースとしてよく用いられるものには、CVE（共通脆弱性識別子）やNVD（National Vulnerability Database）、CVSSスコアがあります。一方、CVEやNVDからは、サードパーティーライブラリ、OSS、レガシーソフトウェアに影響する脆弱性がかなり抜け落ちているほか、修正に必要な実用的な情報（メタデータ）が欠けていることが多々あるとの指摘もあります[*7]。

関連記事：CVEとNVDだけに頼った脆弱性管理に潜む問題

本当に使える脆弱性情報を得る上で力を発揮するのが、包括的な脆弱性データベースの「VulnDB」です。 VulnDBを使うことで、CVEが見落とす9万4千件余りの脆弱性を含む29万7千件超にアクセスでき、これらの脆弱性の対処に役立つメタデータも素早く把握できます。VulnDBは、弊社が提供する脅威インテリジェンスツールFlashpointの一つの機能として利用できます。

また、弊社の別のツールAnomaliと連携することで、VulnDB等で収集する情報を使った脅威への自動対応を行うことも可能です。

関連記事：
脅威インテリジェンスとは何か？　その種類と重要性
脅威インテリジェンスの活用方法、製品・ツールを比較する際のポイント
Anomaliにできること　活用事例

弊社サービスのご紹介

VulnDB（Flashpoint）

画像出典：Flashpoint

VulnDBは、「脆弱性の死角」をなくす「包括的な脆弱性データベース」です。豊富なエントリ数やメタデータをもとに、1つのウィンドウにリスクを可視化します。また、以下の画像に示したツールとのインテグレーションも可能です。

画像出典：Flashpoint

日本でのVulnDB（Flashpoint）に関するお問い合わせは、
弊社マキナレコードにて承っております。
また、マキナレコードではインテリジェンスツールの運用をお客様に代わって行う
「マネージドインテリジェンスサービス（MIS）」も提供しております。
詳しくは以下のフォームからお問い合わせください。

Anomali

VulnDBのような脅威インテリジェンスツールなど、さまざまなソースからの情報を1か所に集約します。集約した情報を自社のセキュリティシステム（SIEMやFWなど）と連携させて、脅威への自動対応を行うことも可能です。詳しい機能と活用事例については、関連記事（Anomaliにできること　活用事例）でご紹介しています。