背景と具体例から学ぶSBOM
Software Bill of Materials (SBOM) という言葉を見聞きしたことはあるでしょうか。日本語では「ソフトウェア構成表」とも呼ばれ、あるソフトウェアがどのようなソフトウェアの組み合わせによって作られているかを正確に把握するための仕組みです。
この記事では、SBOM が重要視されるようになってきた背景をはじめ、国内外の状況や、実際に SBOM を出力するためのフォーマットについて解説します。
SBOM が注目されている背景
まず、SBOM が注目を集めるようになった背景を説明します。
私たちソフトウェアエンジニアがプロダクトを作り上げていく際に、全てを自前で書き上げるよいうようなことはせずに、オープンソースソフトウェア (OSS) を部品として利用することは当たり前に行われています。 その一方、プロダクト自体の複雑度が上がっていくにしたがって、どのような「部品」を利用しているか把握することが次第に困難になっていきます。
この困難さは「依存関係の複雑さ」と「レイヤにまたがる網羅性」の 2 点に由来していると言えるでしょう。
依存関係の複雑さ
「依存関係の複雑さ」については npm などパッケージマネージャを利用してパッケージをインストールしたことがある方なら体験したことがあるはずです。図1 を見ると明らかですが、たった 1 つのパッケージをインストールしただけでも莫大な数の依存パッケージがインストールされる場合があるように、 ソフトウェア内で部品として利用するパッケージには直接依存しているパッケージだけでなく、そのパッケージがさらに依存している推移依存のパッケージも含まれています。
図1 ある npm パッケージの依存パッケージを yamory を使ってツリー表示させた様子
通常の資産管理の場合、自分達のプロダクトが直接依存しているパッケージに関してだけ管理対象に置くことが多いでしょう。 しかし、こうした推移依存のパッケージが管理対象から漏れてしまい、そうしたパッケージに既知の脆弱性が存在したとしても、そのリスクに気づくことができなくなってしまいます。
また、複雑なサプライチェーンの中で、他社が製造したソフトウェアや、それがプリインストールされたハードウェアを自社製品に組み込んで利用する際に、そのソフトウェアがどのような部品から作られているか把握することも困難であり、それに伴うリスク管理も難しくなってしまっている現状があります。
レイヤにまたがる網羅性
私たちが開発しているプロダクトは、実際に書いたコードを動かすために、それをビルドしたバイナリやスクリプトだけでなく、Linux をはじめとする OS そのものや Nginx, MySQL などのミドルウェアを組み合わせて利用します。 すなわち、リスクを管理するためには、アプリケーションのレイヤだけでなく、OS やミドルウェアのレイヤでもどのようなソフトウェアが利用されているのか把握しておく必要があります。
2021 年に界隈を騒がせた「Log4shell」は Apache Log4j の脆弱性で、これはアプリケーションレイヤの脆弱性ですし、2014 年に話題になった「Shell Shock」は OS レイヤの脆弱性となります。 各レイヤで利用しているソフトウェアの一覧が把握できていないと、こうした危険な脆弱性を見逃してしまうことにつながります。
また、Docker などコンテナ技術の発展により、OS・ミドルウェア・アプリケーションを丸ごと含んだパッケージとして共通のアプリケーションを利用できるようになりました。 こうした技術は利用側にとって便利な一方、その中でどのようなソフトウェアがインストールされているのか、その全てを正確に把握することは難しいことです。
SBOM の価値
こうしたサプライチェーン上にあるソフトウェアの資産管理を実施し、その一覧表に基づいてセキュリティ上のリスクや、ライセンスなどのリスクについて評価を行うことが SBOM の役割となります。
SBOM を整備した上でサービスや製品を販売すると、内部に抱えるリスクを適切にハンドリングすることができ、リスクとなりうるものを事前に対処したり、後から判明した場合でも迅速に対応できるようになります。
したがって、SBOM を継続的にメンテナンスしていくことは、こうしたリスクマネジメントにおいて大きな価値を発揮します。
脆弱性による被害の現状と SBOM
以下の表は、IPA が毎年公開している「情報セキュリティ10大脅威」の 2022 年度版で、組織に対する脅威を抜粋したものです。この表で、太字で示したものがソフトウェアの脆弱性を利用した攻撃であり、SBOM が整備されていれば事前に防ぐことができたり、対処が容易であった可能性が高い攻撃手法でもあります。
表1 IPA「情報セキュリティ10大脅威 2022」を元に作成（太字は筆者による）
順位 |
内容 |
|---|---|
1位 |
ランサムウェアによる被害 |
2位 |
標的型攻撃による機密情報の窃取 |
3位 |
サプライチェーンの弱点を悪用した攻撃 |
4位 |
テレワーク等のニューノーマルな働き方を狙った攻撃 |
5位 |
内部不正による情報漏えい |
6位 |
脆弱性対策情報の公開に伴う悪用増加 |
7位 |
修正プログラムの公開前を狙う攻撃（ゼロデイ攻撃） |
8位 |
ビジネスメール詐欺による金銭被害 |
9位 |
予期せぬIT基盤の障害に伴う業務停止 |
10位 |
不注意による情報漏えい等の被害 |
特にゼロデイ攻撃を抑えて 6 位にランクインしている「脆弱性対策情報の公開に伴う悪用増加」とは、まさに既知の脆弱性を利用した攻撃のことを指摘しており、SBOM を利用して現在利用されているソフトウェアやそのバージョンが管理できていれば、事前に被害を抑えられたものであると言えるでしょう。
SBOM を取り巻く国内外の状況
米国大統領令における SBOM の位置付け
これまでに説明してきたような既知の脆弱性に対する攻撃に対処するため、米国では 2021 年 5 月に SBOM に関する大統領令が発令されました。この中には、米国国立標準技術研究所（NIST）と米国商務省電気通信情報局（NTIA）が協力して SBOM の最小構成要素を定めること、NIST がソフトウェアサプライチェーンを明確にするためのガイドラインを策定すること、また製品購入者への SBOM 提供に関する項目も含まれています。
さらに、ここで検討された内容をもとに政府におけるソフトウェア調達基準も見直され、これに合致しないソフトウェアは将来的に納品できなくなることにもなっています。このような背景から、米国でも利用されるソフトウェアを開発する場合、 SBOM の整備は待ったなしの課題であるとも言えます。
日本国内の状況
日本国内では、経済産業省を中心に SBOM を利活用するための実証実験が行われています。特に整備効果が高いとされる医療機器・自動車・ソフトウェアの分野に絞って実施されており、SBOM を整備するためのコストがどの程度かかるのか、SBOM を整備することでどの程度の効果が得られるのか、他分野への応用がどのようになされるべきか、検討が進んでいる段階です。
したがって、日本国内のソフトウェア分野においても将来的に SBOM の整備が求められるようになっていくことが予想され、今の段階で検討を始めておくことが戦略的に有利になるでしょう。
SBOM のファイルフォーマット
ここまでは SBOM の概要を説明してきました。ここからは実際に SBOM を出力する際にどのようなフォーマットが利用できるのか、具体例を交えて説明します。
ファイルフォーマットの種類
SBOM を出力する際のファイルフォーマットには複数の規格がありますが、主に以下の 3 つがよく知られています。
- CycloneDX (OWASP)
- Software Package Data Exchange: SPDX (The Linux Foundation)
- Software Identification Tags: SWID
「CycloneDX」は OWASP によるプロジェクトで、特にセキュリティやサプライチェーンの分析に特化した軽量な仕様を目指したフォーマットです。「SPDX」は The Linux Foundation のプロジェクトで、ISO/IEC 5962:2021 で標準化されています。また、サブセットである SPDX-Lite も定義されていて、簡易な用途にも適用可能です。「SWID」は ISO/IEC 19770-2:2015 で標準化されている仕様ですが、やや古いこともあって、下火になりつつあるようです。
この記事では、国際標準化されたことで特にいま注目が集まっている SPDX について取り上げます。
SPDX について
SPDX は先にも紹介したとおり Linux Foundation 傘下のプロジェクトで、機械判読性だけでなく人にも読みやすいとされるフォーマットの提供もしている SBOM に関するファイルトーマットのひとつです。執筆時点（2022年8月10日）での最新バージョンは 2.2 となっています。その中には、図2 に示したように、対象とするパッケージそのものの情報だけでなく、ライセンス情報や、依存関係の情報も含んでいます。
図2 SPDX Version 2.2 が提供するリソースの一覧 (SPDX Specification Version 2.2 より引用; CC BY 3.0)
SPDX は公式のサンプルが GitHub 上で利用可能なので、こちらを利用して説明していきます。まずは単純な例として C 言語で書かれた Hello World を表示するプログラムの SPDX ファイルを提供している example1 を一部抜粋して見ていきます。
コード1 に示したものがその Hello World に関する SPDX フォーマットのファイルとなっています。yaml に近い形で書かれていますが、これは人間の可読性を高めたフォーマットとなっているためです。
コード1 SPDX のファイル例 (spdx-examples example1 より抜粋)
ファイルの上部はメタ情報となっていて、ドキュメント全体で一意になるように定められた SPDXID や、作者あるいは作成ツールといった情報を格納する Creator のセクションから成り立っています。
それに続く PackageName から始まるセクションが、提供しているパッケージに関する情報を集めたセクションです。同じく一意に定るように SPDXID を記述してから、パッケージのダウンロード先や、ハッシュ値、ライセンスの情報などを明記できるようになっています。
最後に Relations セクションを使って、各情報の紐付けを行います。Relationships で用いることができる関係を表すキーワードは公式ドキュメントに記載されています。DEPENDS_ON や CONTAINS など自然な英語になるようなキーワード群が制定されているようです。今回は DESCRIBES というキーワードを用いて、このドキュメントそのものが該当パッケージの説明を表しているという関係性を示します。
このように、パッケージの属性とその Relationships から SPDX によるドキュメントは成り立っていきます。
SPDX の課題点
SPDX 自体は国際標準化されており、非常に表現力の高いフォーマットです。その一方、どこまで整備すればいいか、その品質をどう測ればいいかという点については未だ決着をみません。
例えば Relationships では DEPENDS_ON と CONTAINS の両方の表現が使えますが、どちらを採用するかあるいは両方表記するかは作者の判断に委ねられますし、そのどこまでを依存関係であると認定するかは読み取る側のツールの作者の判断に委ねられてしまいます。さらに CONTAINED_BY という表現もあり、逆方向の表現を入れる・入れないという判断も作者に委ねられてしまっていると言えます。
そのため、SPDX を整備したとしても作成側と受領側で基準が異なるために、十分に活用できないというシチュエーションに陥ってしまう可能性もあります。業界全体として、SPDX の定量的な評価を行えるような環境整備が求められているのではないでしょうか。
おわりに
この記事では、SBOM が注目される背景について、依存関係管理の複雑さや、依存の中にある脆弱なパッケージを見逃してしまうことで発生しうるセキュリティ上のリスクを交えて説明しました。また、米国と日本における政府の方針から、将来的に SBOM への対応が重要になっていくであろうという予想が立てられました。最後に、代表的な SBOM のファイルフォーマットである SPDX について、その具体的な仕様や問題点について解説しました。
現時点で実際に SPDX ファイルを整備することは若干難易度が高い作業となってしまいますが、yamory では推移依存のパッケージも含めて脆弱性やライセンスのリスクを管理することができます。SBOM 管理の第一歩としてご活用いただければと思います。
