サプライチェーン攻撃とSBOM｜依存関係・脆弱性管理・署名検証を解説

2025年12月23日作成

コラム

SBOM（Software Bill of Materials：ソフトウェア部品表）は、サプライチェーン攻撃対策の基盤となる技術です。ソフトウェアに含まれるコンポーネント（依存ライブラリ、OSSパッケージ等）を一覧化することで、脆弱性が発見された際に影響範囲を迅速に特定できます。米国では大統領令により政府調達でのSBOM提供が義務化され、日本でも経済産業省がガイドラインを策定するなど、SBOMの重要性は高まっています。この記事では、SBOMの作成方法、脆弱性管理への活用、署名検証との組み合わせまで、実践的なSBOM活用方法を解説します。

SBOMとは

SBOM（Software Bill of Materials：ソフトウェア部品表）とは、ソフトウェアを構成するすべてのコンポーネントを一覧化した文書です。製造業で使われる部品表（BOM：Bill of Materials）をソフトウェアに適用した概念で、「ソフトウェアの成分表」とも呼ばれます。

製造業のBOMが、製品に使用されている部品、材料、それらの供給元を記録しているのと同様に、SBOMはソフトウェアに含まれるライブラリ、フレームワーク、OSSパッケージなどの情報を記録します。現代のソフトウェアは多数の外部コンポーネントに依存しており、その把握はサプライチェーン攻撃対策の第一歩となります。

SBOMに含まれる情報	説明	例
コンポーネント名	パッケージやライブラリの名称	lodash、react、log4j
バージョン	使用しているバージョン番号	4.17.21、18.2.0、2.14.1
供給元	パッケージの提供元・配布元	npm、Maven Central、PyPI
ライセンス	適用されるライセンス	MIT、Apache-2.0、GPL-3.0
依存関係	他のコンポーネントとの依存関係	直接依存、推移的依存
ハッシュ値	改ざん検知用のハッシュ	SHA-256ハッシュ値

SBOMを適切に管理することで、自社のソフトウェアが「何で構成されているか」を正確に把握できます。これは情報漏洩の原因特定や、マルウェア感染経路の追跡にも役立ちます。

SBOMがサプライチェーン攻撃対策になる理由

SBOMがサプライチェーン攻撃対策として有効な理由は、依存関係の可視化と脆弱性発見時の迅速な対応を可能にするからです。

依存関係の可視化

現代のソフトウェア開発では、直接利用するライブラリ（直接依存）だけでなく、それらが内部で利用しているライブラリ（推移的依存・間接依存）まで含めると、依存関係は非常に複雑になります。一般的なWebアプリケーションでは、数百から数千のコンポーネントに依存していることも珍しくありません。

直接依存: 開発者が明示的に利用を宣言したパッケージ。package.jsonやpom.xmlに記載されている。
推移的依存（間接依存）: 直接依存するパッケージが内部で利用しているパッケージ。開発者が意識していないことが多い。

SBOMを作成することで、これら全ての依存関係が可視化されます。「知らないうちに危険なパッケージに依存していた」という状況を防ぐことができます。依存関係の脆弱性は、攻撃者にとって格好の侵入経路となるため、その把握は極めて重要です。

脆弱性発見時の迅速な対応

Log4Shell脆弱性（CVE-2021-44228）が発見された2021年12月を思い出してください。Apache Log4jという広く使われているJavaライブラリに深刻な脆弱性が発見され、世界中の組織が緊急対応に追われました。

Log4Shell脆弱性は、CVSSスコア10.0（最高）の深刻な脆弱性であり、遠隔からの任意コード実行を可能にするものでした。
— 出典：IPA「Apache Log4jの脆弱性対策について」

この時、SBOMを持っていた組織と持っていなかった組織では、対応速度に大きな差が生まれました。SBOMがあれば、「自社のどのシステムにLog4jが含まれているか」を即座に検索できます。一方、SBOMがない組織は、システムを一つ一つ調査する必要があり、対応が遅れました。

ランサムウェア攻撃者は、このような脆弱性情報が公開されてから数時間で攻撃を開始することがあります。SBOMによる迅速な影響範囲特定は、被害を防ぐ上で決定的な差となります。

SBOMの作成方法

SBOMを実際に作成する方法を解説します。SBOMの作成には、フォーマットの選択、ツールの利用、作成タイミングの決定が必要です。

SBOMフォーマット

SBOMには複数の標準フォーマットがあります。主要なフォーマットの特徴を理解し、自社の環境に適したものを選択することが重要です。

SPDX（Software Package Data Exchange）: Linux Foundationが策定した国際標準（ISO/IEC 5962:2021）。ライセンスコンプライアンスに強みがあり、法務部門との連携が必要な場合に適している。JSON、XML、RDF、Tag-Value形式をサポート。
CycloneDX: OWASP（Open Web Application Security Project）が策定したフォーマット。セキュリティユースケースに最適化されており、脆弱性管理との連携が容易。JSON、XML形式をサポート。軽量で扱いやすい。
SWID（Software Identification）: ISO/IEC 19770-2で定義された規格。ソフトウェア資産管理（SAM）での利用を想定。インストール済みソフトウェアの識別に強みがある。

フォーマット	標準化団体	主な用途	特徴
SPDX	Linux Foundation	ライセンス管理	ISO標準、包括的
CycloneDX	OWASP	セキュリティ	軽量、脆弱性連携
SWID	ISO	資産管理	インストール時生成

セキュリティ対策が主目的であればCycloneDX、ライセンスコンプライアンスも重視するならSPDXが適しています。

SBOM作成ツール

SBOMを手作業で作成するのは現実的ではありません。以下のようなツールを活用して自動生成します。

Syft: Anchore社が開発したオープンソースのSBOM生成ツール。コンテナイメージ、ファイルシステム、アーカイブからSBOMを生成可能。SPDX、CycloneDX両方に対応。
Trivy: Aqua Security社が開発した脆弱性スキャナー。SBOM生成機能も備え、生成と同時に脆弱性スキャンが可能。CI/CDパイプラインへの組み込みが容易。
OWASP Dependency-Track: SBOMを取り込み、継続的にリスク分析を行うプラットフォーム。複数プロジェクトのSBOMを一元管理し、脆弱性の継続的モニタリングが可能。
GitHub Dependency Graph: GitHubリポジトリの依存関係を自動検出。Dependabotと連携して脆弱性アラートを自動生成。SBOM形式でのエクスポートも可能。

これらのツールをCI/CDパイプラインに組み込むことで、ビルドごとに最新のSBOMを自動生成できます。

SBOM作成のタイミング

SBOMはいつ作成すべきでしょうか。最も効果的なのは、以下の3つのタイミングでの作成と更新です。

ビルド時：CI/CDパイプラインでビルドを実行するたびにSBOMを生成。最新の依存関係を常に反映。
リリース時：製品やサービスをリリースする際に、そのバージョンに対応するSBOMを確定。顧客への提供やコンプライアンス対応に使用。
継続的な更新：脆弱性データベースの更新に合わせて、既存SBOMと照合。新たに発見された脆弱性の影響を確認。

SBOMを活用した脆弱性管理

SBOMは作成して終わりではありません。脆弱性管理に活用することで、サプライチェーン攻撃対策としての真価を発揮します。

脆弱性データベースとの照合

SBOMに記載されたコンポーネント情報を、脆弱性データベースと照合することで、既知の脆弱性を持つコンポーネントを特定できます。

CVE（Common Vulnerabilities and Exposures）: MITRE社が管理する脆弱性の共通識別子。CVE-2021-44228（Log4Shell）のように一意のIDが付与される。
NVD（National Vulnerability Database）: 米国NISTが運営する脆弱性データベース。CVEに詳細情報（CVSSスコア等）を付加して提供。
JVN（Japan Vulnerability Notes）: IPAとJPCERT/CCが共同運営する日本の脆弱性情報データベース。日本語での情報提供と、国内製品固有の脆弱性も収録。

OWASP Dependency-TrackやTrivy、Snykなどのツールは、SBOMとこれらのデータベースを自動照合し、脆弱性を検出します。

継続的なモニタリング

脆弱性は日々新しく発見されます。今日は安全なコンポーネントでも、明日には深刻な脆弱性が公開される可能性があります。SBOMを活用した継続的なモニタリングが重要です。

脆弱性データベースの日次更新に合わせた自動スキャン
新規脆弱性発見時のアラート通知（Slack、メール等）
CVSSスコアや悪用可能性に基づく優先順位付け
標的型攻撃（APT）で悪用されている脆弱性の優先対応

影響範囲の特定

脆弱性が発見された際、SBOMを検索することで影響を受けるシステムを即座に特定できます。これはインシデント対応において極めて重要です。

「Log4jのバージョン2.0〜2.14.1を使用しているシステムはどれか」という問いに、SBOMがあれば数秒で回答できます。SBOMがなければ、すべてのシステムを個別に調査する必要があり、数日から数週間を要する可能性があります。

署名検証との組み合わせ

SBOMの信頼性を高めるには、署名検証との組み合わせが効果的です。SBOMそのものが改ざんされていないことを保証し、ビルド成果物の完全性を確認できます。

SBOMの改ざん防止

攻撃者がビルドシステムに侵入した場合、SBOMを改ざんして悪意あるコンポーネントを隠蔽する可能性があります。SBOMに電子署名を施すことで、改ざんを検知できます。

署名の目的: SBOMが作成後に改ざんされていないことを保証する。署名者（組織）を特定し、出所を証明する。
署名の検証: SBOMを受け取った側が署名を検証することで、正規のSBOMであることを確認できる。

Sigstore/cosignの活用

Sigstoreは、ソフトウェアアーティファクトの署名と検証を簡素化するオープンソースプロジェクトです。特にcosignは、コンテナイメージやSBOMへの署名を簡単に行えるツールとして広く使われています。

Sigstoreの特徴はキーレス署名です。従来の署名では秘密鍵の管理が大きな負担でしたが、Sigstoreでは一時的な鍵を使用し、署名の証拠を公開ログ（Rekor）に記録します。これにより、鍵管理の負担なく署名を実現できます。

Sigstoreは、ソフトウェアサプライチェーンのセキュリティを向上させるため、Linux Foundation傘下で開発されているプロジェクトです。
— 出典：Linux Foundation「Sigstore」

CI/CDセキュリティと組み合わせることで、ビルドからデプロイまで一貫した完全性を保証できます。

SBOM導入の課題と対策

SBOMの導入には、いくつかの課題があります。これらを理解し、適切に対処することが重要です。

課題1：運用コスト（SBOMの維持・更新）: SBOMは一度作成して終わりではなく、継続的な更新が必要。ビルドごとの自動生成、脆弱性データベースとの継続的な照合など、運用の仕組みを構築する必要がある。
対策：CI/CDパイプラインへのツール組み込みで自動化。OWASP Dependency-Trackなどのプラットフォームで一元管理。
課題2：不完全なSBOM（依存関係の欠落）: 自動生成ツールでも、すべての依存関係を検出できないことがある。特にネイティブライブラリ、動的にロードされるコンポーネント、ビルドスクリプトで追加される依存関係は見落とされやすい。
対策：複数のツールを併用。手動での補完。定期的な監査で漏れを確認。
課題3：推移的依存関係の把握: 直接依存するパッケージの依存関係（推移的依存）は、非常に深いツリー構造になることがある。すべてを把握し管理することは困難。
対策：ツールによる自動解析。リスクの高い推移的依存のみ優先的に監視。OSSの安全な利用のベストプラクティスを適用。
課題4：ライセンスコンプライアンス: SBOMにはライセンス情報も含まれるが、OSSのライセンス条件を正しく理解し遵守することは容易ではない。特に推移的依存のライセンスは把握が困難。
対策：SPDXフォーマットでライセンス情報を管理。法務部門との連携。ライセンススキャンツールの活用。

SBOM義務化の動向

SBOMの重要性が認識される中、各国でSBOM義務化の動きが進んでいます。

米国大統領令（EO 14028）

2021年5月、バイデン大統領は「国家のサイバーセキュリティ向上に関する大統領令（Executive Order 14028）」に署名しました。この大統領令により、米国政府への納入ソフトウェアにはSBOMの提供が義務化されました。

政府機関へのソフトウェア納入時にSBOM提出が必要
SBOMは機械可読形式（SPDX、CycloneDX等）で提供
ソフトウェアベンダーのセキュリティ基準を強化

この動きは民間企業にも波及しており、サプライチェーン全体でSBOM対応が求められるようになっています。

経済産業省のSBOMガイドライン

日本でも、経済産業省が2023年に「ソフトウェア管理に向けたSBOM（Software Bill of Materials）の導入に関する手引」を公開しました。

ガイドラインの目的: 日本企業におけるSBOM導入を促進し、ソフトウェアサプライチェーンの透明性とセキュリティを向上させる。
対象読者: ソフトウェアを開発・利用する企業の経営層、IT部門、調達部門。

今後、日本国内でもSBOMへの対応が調達要件に含まれるケースが増えると予想されます。中小企業も、取引先からSBOM提供を求められる可能性があります。

攻撃手法	SBOMによる対策効果
ソフトウェアサプライチェーン攻撃	依存コンポーネントの把握で侵入経路を可視化
依存関係の脆弱性	脆弱性発見時の影響範囲を即座に特定
タイポスクワッティング	使用パッケージ一覧で不審なパッケージを検出
依存関係混乱攻撃	パッケージの供給元を明確化し不正を検知
ゼロデイ攻撃	脆弱性公開後の迅速な影響調査が可能
Nデイ攻撃	パッチ未適用コンポーネントの特定
標的型攻撃（APT）	侵入経路の調査・インシデント対応を支援

よくある質問

Q: SBOMは義務化されていますか？: A: 日本国内では現時点で法的な義務化はされていません。ただし、米国では政府調達においてSBOM提供が義務化されており、米国向けにソフトウェアを提供する企業は対応が必要です。経済産業省もガイドラインを公開しており、今後は取引先からSBOM提供を求められるケースが増えると予想されます。特に重要インフラや金融、医療など規制の厳しい業界では、早めの対応が推奨されます。
Q: 既存システムにSBOMを適用できますか？: A: はい、可能です。SyftやTrivyなどのツールを使用すれば、既存のコンテナイメージやファイルシステムからSBOMを生成できます。ただし、自動生成では検出できない依存関係もあるため、手動での補完が必要になることがあります。レガシーシステムの場合は、依存関係の把握自体が困難なこともありますが、段階的に可視化を進めることが重要です。
Q: SBOMはどのくらいの頻度で更新すべきですか？: A: 理想的にはビルドごとに更新することが推奨されます。CI/CDパイプラインにSBOM生成ツールを組み込むことで、自動的に最新の状態を維持できます。少なくとも、リリースごとにSBOMを更新し、そのバージョンに対応するSBOMを保管してください。また、脆弱性データベースとの照合は日次で行い、新たに発見された脆弱性の影響を継続的に確認することが重要です。
Q: SBOMの作成に特別なスキルは必要ですか？: A: 基本的なSBOMの作成には、特別なスキルは必要ありません。Syft、Trivy、GitHub Dependency Graphなどのツールを使用すれば、コマンド一つでSBOMを生成できます。ただし、SBOMを脆弱性管理に活用するには、セキュリティの基本知識（CVE、CVSSスコアの理解等）があると効果的です。CI/CDパイプラインへの組み込みには、DevOpsの知識が役立ちます。
Q: SBOMは外部に公開すべきですか？: A: SBOMを外部に公開するかどうかは、ビジネス上の判断が必要です。顧客や取引先から要求された場合は提供が必要ですが、攻撃者に使用コンポーネントの情報を与えるリスクもあります。公開する場合は、適切なアクセス制御を設け、必要な相手にのみ提供することが推奨されます。社内での活用が主目的であれば、外部公開は必須ではありません。

まとめ

本記事では、サプライチェーン攻撃対策としてのSBOMについて解説しました。主なポイントは以下の通りです。

SBOM（ソフトウェア部品表）は、ソフトウェアを構成するすべてのコンポーネントを一覧化した文書
SBOMにより**依存関係を可視化**し、脆弱性発見時の影響範囲を迅速に特定できる
主要なフォーマットは**SPDX**（ライセンス管理）と**CycloneDX**（セキュリティ）
Syft、Trivy、OWASP Dependency-Trackなどの**ツール**で自動生成・管理が可能
**Sigstore/cosign**との組み合わせで、SBOMの改ざん防止と完全性保証を実現
米国では政府調達で**SBOM義務化**、日本でも経済産業省がガイドラインを策定
運用コスト、不完全なSBOM、推移的依存関係の把握などの**課題**に対処が必要

SBOMはCI/CDパイプラインの保護と密接に関連しています。次のステップとして、サプライチェーン攻撃対策のCI/CD｜SLSA・署名・改ざん検知をご参照ください。

技術者向けカテゴリの全体像については、サプライチェーン攻撃の技術対策｜SBOM・CI/CD・OSS・EDIをご覧ください。

サプライチェーン攻撃の総合的な理解には、サプライチェーン攻撃とは｜仕組み・事例・対策を初心者にもわかりやすく解説もあわせてご参照ください。

重要なお知らせ

本記事は一般的な情報提供を目的としており、個別の状況に対する助言ではありません。
実際にサイバー攻撃の被害に遭われた場合は、警察（#9110）やIPA（03-5978-7509）などの公的機関にご相談ください。
法的な対応が必要な場合は、弁護士などの専門家にご相談ください。
記載内容は作成時点の情報であり、攻撃手法は日々進化している可能性があります。

サプライチェーン攻撃とSBOM｜依存関係・脆弱性管理・署名検証を解説