SBOM（ソフトウェア部品表）とは何か、なぜセキュリティや法規制への対応に必要なのかを解説

要点

• 本記事は、ソフトウェアの構成部品を一覧化した「SBOM（ソフトウェア部品表）」の概要と、現代のシステム開発において重要とされる背景を解説する。
• SBOMは、ソフトウェア内に含まれるすべてのライブラリやパッケージなどの依存関係を網羅した、機械読み取り可能な目録である。
• 脆弱性の発生時に影響範囲を数分で特定し、インシデントへの迅速な対応を可能にする。
• 米国の大統領令や欧州のサイバーレジリエンス法（EU CRA）など、国内外のセキュリティ規制により、ソフトウェア調達時の必須要件になりつつある。
• 暗号署名や来歴保証（プロベナンス）と組み合わせることで、開発からデプロイまでのサプライチェーン全体の安全性を検証できる。

導入

近年、ソフトウェア開発におけるセキュリティ対策として「SBOM（Software Bill of Materials：ソフトウェア部品表）」への注目が高まっています。コンテナやオープンソースソフトウェア（OSS）の普及に伴い、アプリケーションの内部構造は複雑化しており、セキュリティリスクを把握するための可視化が急務となっています。本記事では、SBOMの基本的な定義から、そこに含まれるメタデータ、そしてなぜ現代のソフトウェアサプライチェーンにおいて不可欠なものとなっているのかを整理して解説します。

SBOMとは何か

あらゆるソフトウェアは、さまざまな依存関係（動作に必要な外部のライブラリやパッケージ）を含んだ状態で出荷されます。たとえば、Alpine Linuxをベースにしたコンテナイメージには数十のシステムパッケージが含まれ、さらにその上に構築されるアプリケーション層には、開発者が直接選択していない間接的な依存関係（推移的依存関係）も加わります。このように複雑化したソフトウェアの内部に「実際に何が動いているのか」を明らかにするのがSBOMです。

SBOMは、ソフトウェアアーティファクト（コンテナイメージなどの成果物）の内部にあるすべてのコンポーネントを網羅した、構造化された機械読み取り可能な目録です。一般的なパッケージマニフェスト（requirements.txtなど）が開発時に「宣言された依存関係」を記述するのに対し、SBOMはビルドされた後に「解決された依存関係ツリー」全体をキャプチャします。これには、間接的な依存関係やシステムレベルのパッケージ、ライセンス情報、オリジン（起源）などが含まれ、「ソフトウェアの栄養成分表示」のような役割を果たします。

SBOMに含まれる情報

標準的なSBOMには、各コンポーネントに関する以下のメタデータが含まれています。

• コンポーネントの識別情報：パッケージ名、バージョン、および供給元（例：「OpenSSL Project」が提供する「openssl 3.1.4」など）。
• ライセンス情報：再配布や使用を規定するライセンスの種類（MIT、Apache 2.0、GPLなど）。
• 依存関係の相関関係：直接の依存関係および推移的依存関係がどのように絡み合っているかの情報。
• 一意の識別子：脆弱性データベースと照合するためのPackage URL（purl）やSWIDタグ。
• チェックサムとダイジェスト：改ざんされていないかを検証するための暗号ハッシュ値。

これらのデータは、異なるツールや組織間で相互運用できるよう、主に「SPDX」または「CycloneDX」といったオープンな標準規格を用いて構造化されます。

なぜSBOMがセキュリティ上重要なのか

SBOMの価値は、セキュリティ上の問題が発生した瞬間に発揮されます。

迅速なインシデント対応

2021年12月に深刻な脆弱性「Log4Shell」が公表された際、最新のSBOMを保有していた組織は、影響を受けるイメージを数分で特定できました。一方で、SBOMを持たない組織は、複数のレジストリ（イメージの保管庫）やデプロイ用の定義ファイルから対象を手作業で追跡するのに数日を費やしました。

また、Sonatype社の調査によると、オープンソースのCVE（共通脆弱性識別子）の約65%には、NVD（アメリカ国家脆弱性データベース）によるCVSS（共通脆弱性評価システム）スコアが割り当てられていません。しかし、これらを個別に評価したところ、そのうちの46%が「高」または「緊急（クリティカル）」に相当する脆弱性でした。SBOMが存在しない場合、こうした評価スコアのない脆弱性は見えなくなってしまいます。

SBOMを継続的な脆弱性スキャンと組み合わせることで、新しい脆弱性が検出された際に自動で影響範囲を特定し、速やかに対処することができます。実際、ビデオストリーミングプラットフォームを提供するJWP社では、400以上のリポジトリでスキャンを自動化し、スキャンパイプラインにSBOMを供給することで、数千件の脆弱性を修正しつつ、不要な警告を排除することに成功しています。

規制や法制度への準拠

SBOMは、単なるベストプラクティスから「法的な義務」へと移行しつつあります。米国では大統領令14028号によって連邦政府へ調達するソフトウェアへのSBOM要件が設定され、CISA（サイバーセキュリティ・インフラセキュリティ庁）が「2025年最小要素（Minimum Elements）」ガイダンスを公開して詳細を規定しました。欧州でも「EUサイバーレジリエンス法（EU CRA）」により、欧州市場で販売される製品に同様の要件が拡大されています。金融や医療、防衛といった規制の厳しい業界において、SBOMの提示は不可欠な基準となっています。

能動的な検証プロセスの確立

SBOMは、ソフトウェアの安全性を「信頼する」のではなく「検証する」仕組みへと転換させます。CI（継続的インテグレーション：ビルドやテストの自動化プロセス）において、承認されていない供給元のパッケージが混入していないか、サポート終了（EOL）を迎えたコンポーネントが残っていないかといったポリシーチェックを自動実行できます。これを暗号署名や来歴保証（プロベナンス）と組み合わせることで、開発からデプロイに至るまでの信頼性の高いチェーンを構築可能です。

補足

現在、業界では「SPDX」と「CycloneDX」という2つのオープン規格が主流となっています。