SBOMとは？　ソフトウェアの脆弱性管理に欠かせない部品表

2024年8月に経済産業省は「ソフトウェア管理に向けたSBOM（エスボム：Software Bill of Materials）の導入に関する手引きver2.0」を公開している。前年に発表している同資料の改訂版だ。

SBOMまたはソフトウェア部品構成表とは、アプリケーションソフトウェアを構成するモジュールやライブラリ、コンポーネントの一覧表のことだ。現在の商業ソフトウェアは、すべての機能をスクラッチで開発することはしない。データベースへのアクセス、インターネットへの接続、GUIのライブラリ、Webブラウザ機能などは、市販のパッケージやオープンソースを利用する。Web上のサービスや機能と連携しているソフトウェアも珍しくない。

ひとつのシステム、ひとつのアプリケーションを構成する、これらのソフトウェアコンポーネントすべての一覧をSBOMという。

なぜ、このようなソフトウェア部品表が必要なのだろうか。製品の部品表は製造や発注のベースとなる。資産管理や製品保守のために必要な情報でもある。

SBOMはソフトウェア開発や資産管理だけでなく、セキュリティ対策の基本的な情報としての意味も持つため、改訂版ではその点も重要視されている。

主な改訂ポイントは、

同資料ver1.0では、SBOMの考え方や導入に向けた作業手順、項目を詳細に解説していた。Ver1.0は、体制構築から運用管理までに必要なプロセスを3つのフェーズに分けてまとめている。各フェーズは「導入プロセスの解説資料」、「SBOMとは」、「SBOMの作り方の手引書」という位置づけとなる。

改訂版では、導入後の具体的な運用管理プロセスや適用場面の整理に関する情報を追加した。管理プロセスでは、脆弱性の発見から対応までを4つのフェーズに分けて解説するなどSBOMの業務での使い方を示す、より実践的な内容となっている。

サイバー攻撃のうち、深刻な被害をもたらしているものにランサムウェアがあるが、現在は二重脅迫型（暗号化＋データ暴露）が主流となって、身代金やシステム復旧など被害額も増えている。ランサムウェアの攻撃を許してしまう要因はいくつかあるが、システムの脆弱性が最終的な攻撃を成功させるかどうかの鍵といってよい。

警察庁の調査によれば、国内ランサムウェア被害のうちおよそ8割がVPN装置およびリモートデスクトップからの侵入としている。どちらもソフトウェアの脆弱性を利用して内部ネットワークに侵入し、ファイルを暗号化したり、複製を外部サーバーに送ったりしている。

また、攻撃者は、どのデータを暗号化すれば脅迫効果が高まるのか、機密データ、個人情報はどこにあるのか、システムのどの部分に利用できる脆弱性があるのか、といった情報を侵入したシステムからも集めている。侵入後のハッキングにもソフトウェアの脆弱性が利用される。

ランサムウェア攻撃の入り口は、フィッシングメールやウイルスメールだが、システムに脆弱性があると暗号化やデータ窃取まで許してしまうことになる。脆弱性対策が重要と言われるのはこのためだ。

SBOMは、ここのコンポーネントから構成されるシステムが、現在どんな脆弱性を抱えているのかを可視化できる。JVNや企業などから出される脆弱性情報のうち、どれが自分のシステムに関係ある（＝パッチを当てたり緩和先を実行したりする必要がある）のかが判断できる。別の言い方をすれば、システムを構成するすべてのソフトウェアの銘柄、バージョンを把握していないと、脆弱性をつぶすことはできない。

前述手引書には、具体的なSBOMに含める情報（項目）の例として以下のようなものを挙げている。

必要ならば、コンポーネントやモジュールのハッシュ値、必要なビルド環境や開発環境の情報、関連する脆弱性情報などの欄を作ってもよい。これらを押さえていれば、脆弱性情報やパッチ情報が出たときに、影響範囲や対策の必要性、緊急度を判断できる。

ただし、これはあくまで一例である。SBOM管理のツールやソリューションを提供しているベンダー、システムごとに項目やフォーマットは異なる。SBOMやシステム構成表は、設計や製造管理でも使うので、業界ごとの標準的なフォーマットやベンダーツールに特化したフォーマットなどが存在する。

SBOMの代表的なフォーマットには、SPDX（Software Package Data Exchange）、CycloneDX、SWIDタグ（Software Identification Tags）がある。SPDXはLinux Foundationのオープンソースプロジェクトで策定されたもの。CycloneDXは、OWASP（Open Worldwide Application Security Project）が管理主体であり、XML/JSONで記述される。SWID（タグはソフトウェア資産管理のためのID情報だが、SBOM管理にも使われることがある。

脆弱性を利用した攻撃の多くは、既知の脆弱性に対するものである。ハッカーが誰も発見していない脆弱性を自力で解析して攻撃を行うことはむしろ稀である。通常はCVE（Common Vulnerabilities and Exposures：共通脆弱性識別子）などの脆弱性情報が公開されてから、その脆弱性を狙うのがセオリーになっている。なぜなら、脆弱性情報とパッチが公開されても、多くの企業やユーザーはそれをすぐに適用しないからだ。

セキュリティアップデートが配布され、対策バージョンもリリースされたとしても、既知の脆弱性を狙った攻撃は、それなりの効果を挙げる。ということは、SBOMのようなソフトウェアの構成表にバージョン情報が記載された資料は、逆に攻撃者にとって有益な情報になりうるのではないか。

この疑問・懸念はもっともだが、SBOMは攻撃者にとっても有益という考え方は正確ではない。手引書でも米国商務省NTIAの論文をベースにSBOMの有効性を説いている。

確かに、高度な攻撃の中には、侵入先のOSのバージョンやシステムのバージョンを調べて、発動させるマルウェアを切り替えるものがある。また、APT（Advanced Packaging Tool）など特定の相手に狙いを絞った攻撃では、事前に標的のシステム構成に合わせた手法、マルウェアをアレンジすることがある。

だが、前述のように、多くの脆弱性攻撃は不特定多数に行い、対策を行っていないところにヒットすればいいというアプローチをとっている。標的のシステム構成やバージョンを調べる方法は、SBOMを参照しなくてもよい。システム管理ツールや開発ツールを使ったOSINT ( Open-Source Intelligence）でかなりの情報が得られる。

SBOMの作成と管理は、脆弱性対応の自動化や効率化に貢献する。SBOMツールの出力とCVEなどの脆弱性情報を機械的に結び付けて、やみくもに自動化することはできないが、ツールをうまく使えば、散財したソフトウェア関連の情報をその都度集める必要はなくなる。本来対応する必要があるソフトウェアの脆弱性情報を見落とすことも防げる。

脆弱性管理は簡単ではないが、SBOMがあればその精度をあげ、効率アップにも貢献してくれるはずだ。

参考文献・URL：
サイバー攻撃への備えを！「SBOM」（ソフトウェア部品構成表）を活用してソフトウェアの脆弱性を管理する具体的手法についての改訂手引を策定しました（経済産業省）
https://www.meti.go.jp/press/2024/08/20240829001/20240829001.html
ソフトウェア管理に向けたSBOM（Software Bill of Materials）の導入に関する手引ver2.0
https://www.meti.go.jp/press/2024/08/20240829001/20240829001-1r.pdf
ソフトウェア管理に向けたSBOM（Software Bill of Materials）の導入に関する手引ver2.0概要資料
https://www.meti.go.jp/press/2024/08/20240829001/20240829001-2.pdf
ソフトウェア管理に向けたSBOM（Software Bill of Materials）の導入に関する手引ver2.0付録チェックリスト
https://www.meti.go.jp/press/2024/08/20240829001/20240829001-3.xlsx
令和５年におけるサイバー空間をめぐる脅威の情勢等について（警察庁 サイバー企画課）
https://www.npa.go.jp/publications/statistics/cybersecurity/data/R5/R05_cyber_jousei.pdf
SBOMのフォーマット ～どれがデファクト？～
https://sciencepark.co.jp/professional_service/post/sbom_report_03/
SBOM Myths vs. Facts（NTIA）
https://www.ntia.gov/sites/default/files/publications/sbom_myths_vs_facts_nov2021_0.pdf