背景と具体例から学ぶ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 Version2.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管理の第一歩としてご活用いただければと思います。