セキュリティ15分で読める

SBOM義務化が世界で加速——ソフトウェア供給網の透明化

セキュリティ開発ツールオープンソース
加木谷 直俊ソース記事を見る

「あなたのソフトウェアに含まれるコンポーネントの一覧を提出してください」——2026年、この要求は一部の政府調達だけの話ではなくなりました。米国の大統領令14028を皮切りに、EU Cyber Resilience Act（CRA）、そして日本の経済産業省ガイドラインと、世界中でSBOM（Software Bill of Materials：ソフトウェア部品表）の義務化が加速しています。

Synopsysの2026年Open Source Security and Risk Analysisレポートによると、現代のソフトウェアの平均77%がオープンソースコンポーネントで構成されています。そのうち49%のコードベースに既知の脆弱性が含まれており、SBOMなしではリスクの全容を把握することすらできません。

SBOMとは何か

SBOM（Software Bill of Materials）は、ソフトウェアに含まれるすべてのコンポーネント（ライブラリ、フレームワーク、ツール）の一覧表です。食品の「原材料表示」や製造業の「部品表（BOM）」のソフトウェア版と考えると分かりやすいでしょう。

この図は、SBOMによるソフトウェアサプライチェーン透明化の仕組みを示しています。

SBOMの仕組み——ソフトウェア製品のコンポーネント情報をSBOMとして構造化し、脆弱性管理やコンプライアンスに活用

SBOMに含まれる情報

  • コンポーネント名: 使用しているライブラリ・パッケージの名前（例: log4j、OpenSSL）
  • バージョン情報: 各コンポーネントの正確なバージョン番号
  • サプライヤー情報: コンポーネントの提供元・開発元
  • ライセンス情報: MIT、Apache 2.0、GPLなどのライセンス種別
  • 依存関係ツリー: 直接の依存と推移的（間接的）な依存関係
  • ハッシュ値: コンポーネントの完全性を検証するための暗号学的ハッシュ
  • VEX連携: 脆弱性が自社製品に実際に影響するかどうかの情報

なぜSBOMが必要なのか

Log4Shell事件の教訓（2021年）: Apache Log4jの脆弱性（CVE-2021-44228）が発見された際、多くの企業が「自社システムにLog4jが含まれているかどうか」を把握できませんでした。SBOMがあれば、影響範囲の特定が数時間で可能になります。

サプライチェーン攻撃の増加: SolarWinds（2020年）、Kaseya（2021年）、codecov（2021年）、3CX（2023年）と、ソフトウェアサプライチェーン攻撃は年々増加しています。SBOMは「信頼の連鎖」を可視化する基盤です。

オープンソース利用の拡大: 前述の通り、現代のソフトウェアの77%がオープンソースです。間接的な依存関係（推移的依存）まで含めると、一つのアプリケーションが300以上のコンポーネントに依存していることも珍しくありません。

世界のSBOM義務化動向

米国: 大統領令14028とその後

2021年5月にバイデン大統領が署名した大統領令14028は、連邦政府に納入するソフトウェアにSBOMの提出を求める画期的な政策でした。2026年時点での進捗は以下の通りです。

  • 連邦政府調達: 2024年度からSBOM提出が事実上必須化。FedRAMP（連邦政府クラウドセキュリティ認証）にもSBOM要件が追加
  • CISA: SBOMの標準フォーマットとしてSPDXとCycloneDXの両方を公式に推奨
  • 民間への波及: 連邦政府の調達要件が民間企業間の取引にも波及し、B2B契約でSBOM提出を求めるケースが増加

EU: Cyber Resilience Act（CRA）

2024年に成立したEU CRAは、EU域内で販売されるすべてのデジタル製品にサイバーセキュリティ要件を課す画期的な規制です。

  • SBOM義務化: デジタル製品の製造者にSBOMの作成・維持を義務付け
  • 脆弱性対応: 既知の脆弱性がない状態での出荷を要求。脆弱性発見時は24時間以内にENISA（欧州サイバーセキュリティ機関）に報告
  • 適用時期: 2027年後半から完全施行。ただし準備期間は2025年から推奨
  • 罰則: 最大1,500万ユーロまたは全世界売上高の2.5%

日本: 経済産業省ガイドライン

日本では法的義務化こそ進んでいませんが、経済産業省が段階的にSBOM活用を推進しています。

  • 2023年: 「ソフトウェア管理に向けたSBOM（Software Bill of Materials）の導入に関する手引」を公開
  • 2025年: 政府調達のソフトウェアセキュリティ基準にSBOM項目を追加
  • 2026年度: 重要インフラ分野（電力、金融、通信）でのSBOM作成・提出を推奨から実質義務化へ移行する方針

SBOM標準フォーマット比較

項目SPDXCycloneDX
管理団体Linux FoundationOWASP
ISO標準ISO/IEC 5962:2021ISO/IEC 標準化進行中
フォーマットRDF, JSON, YAML, Tag-ValueJSON, XML, Protocol Buffers
主な焦点ライセンスコンプライアンスセキュリティ
VEX対応SPDX 3.0で対応ネイティブ対応
サポートツール広範急速に拡大中
学習コストやや高い中程度
推奨ユースケースライセンス管理重視セキュリティ重視

どちらを選ぶべきか？: セキュリティ重視ならCycloneDX、ライセンスコンプライアンス重視ならSPDXが適しています。ただし、多くのツールが両方のフォーマットに対応しているため、将来の柔軟性を確保する意味でも両対応のツールを選ぶことを推奨します。

ツールチェーン

この図は、SBOM生成・管理の代表的なツールとCI/CDパイプラインへの統合フローを示しています。

SBOM生成・管理ツールチェーン——コード、ビルド、スキャン、署名、配布の5段階と主要ツール比較

SBOM生成ツール

Syft（Anchore）: コンテナイメージやファイルシステムからSBOMを自動生成するOSSツール。Dockerコンテナのビルド時に syft コマンドを組み込むだけで、SPDX/CycloneDX形式のSBOMが自動生成されます。

Trivy（Aqua Security）: SBOM生成と脆弱性スキャンを統合した万能ツール。コンテナ、ファイルシステム、Gitリポジトリ、IaCファイルに対応。CI/CDパイプラインとの統合が容易です。

GitHub Dependency Graph + SBOM Export: GitHubのDependency Graph機能を使えば、リポジトリの依存関係を可視化し、SPDX形式のSBOMをエクスポートできます。Dependabotと連携することで脆弱な依存関係の自動更新も可能です。

脆弱性スキャン

Grype（Anchore）: Syftで生成したSBOMを入力として、NVD（National Vulnerability Database）やGitHub Advisory Databaseと照合し、既知の脆弱性を検出します。

OSV-Scanner（Google）: GoogleのOpen Source Vulnerabilities（OSV）データベースと照合するOSSツール。Go、npm、PyPI、crates.io、Maven等のエコシステムに対応。

CI/CDパイプラインへの統合

# GitHub Actionsでの統合例のフロー
1. コードチェックアウト
2. アプリケーションビルド
3. Syft で SBOM 生成（CycloneDX形式）
4. Grype で脆弱性スキャン（重大な脆弱性があればビルド失敗）
5. cosign で SBOM に署名
6. SBOM をアーティファクトとして保存・配布

実践的な導入ステップ

Phase 1: 現状把握（1-2週間）

  1. 主要プロダクトのリポジトリで syft または trivy を実行し、SBOM を試験生成
  2. 含まれるコンポーネント数、既知の脆弱性の数を把握
  3. ライセンス構成を確認（GPL系ライセンスの有無は特に重要）

Phase 2: パイプライン統合（2-4週間）

  1. CI/CDパイプラインにSBOM生成ステップを追加
  2. 脆弱性スキャンをゲートチェックとして設定（Critical/Highがあればビルド失敗）
  3. SBOM のアーティファクト保存を自動化

Phase 3: 運用化（1-3ヶ月）

  1. 定期的なSBOMの更新と脆弱性モニタリングの仕組みを構築
  2. VEX（Vulnerability Exploitability eXchange）の活用を開始
  3. 取引先・顧客へのSBOM提供プロセスを確立

Phase 4: 高度化（3ヶ月〜）

  1. SBOM署名による改ざん防止
  2. SLSA（Supply chain Levels for Software Artifacts）フレームワークへの準拠
  3. 自動化されたライセンスコンプライアンスチェック

GitHub Copilotによる開発効率化

GitHub Copilotを活用することで、SBOM対応に必要なコード（依存関係の整理、セキュリティテストの追加、CI/CDパイプラインの設定）の生成を効率化できます。特にGitHub ActionsのワークフローファイルやDockerfileの最適化において、Copilotの支援は大きな時間短縮になります。

主要ソリューション比較

ツールSBOM生成脆弱性スキャンライセンス監査CI/CD統合料金
Syft + Grype高品質高精度基本的GitHub Actions, GitLab CI無料（OSS）
Trivy高品質高精度基本的広範な統合無料（OSS）
Snyk中程度高精度あり広範な統合無料〜$25/月〜
FOSSA中程度基本的高品質あり要問い合わせ
GitHub SBOM基本的Dependabot連携なしネイティブ無料
Anchore Enterprise高品質高精度あり広範な統合要問い合わせ

日本ではどうなるか

日本のSBOM対応は、政府の推進と産業界の実装の両面で進んでいます。

経産省の段階的アプローチ: 日本は法的義務化を急ぐのではなく、ガイドラインと実証事業で普及を促進するアプローチを取っています。2023年の「手引」公開後、自動車、医療機器、通信機器の3分野で実証事業が進行中です。

自動車業界の先行: JASPAR（Japan Automotive Software Platform and Architecture）がSBOM標準を策定中。自動車のECU（Electronic Control Unit）に含まれるソフトウェアのSBOM管理は、UN-R155（車両サイバーセキュリティ）規制の要件でもあり、日本の自動車メーカーは世界に先駆けて対応を進めています。

医療機器: PMDAの認可プロセスにおいて、2026年度からSBOMの提出が推奨事項となる見込みです。FDAの同様の要件（2023年施行）に続く動きです。

SIer/開発会社への影響: 受託開発を行うSIerや開発会社は、納品物にSBOMを添付する要求が増えています。特に政府系プロジェクトや金融機関向けの開発では、SBOM対応が入札条件に含まれるケースが出始めています。

人材育成: IPAが「SBOM活用ガイド」を2026年度に改定予定。OSSライセンスコンプライアンスとSBOMの基礎知識を備えたエンジニアの育成が急務です。

まとめ：今すぐ取るべき3つのアクション

SBOMは「あれば便利」から「なければ取引できない」時代に移行しつつあります。

  1. 主要プロダクトのSBOMを試験生成する: Dockerコンテナやリポジトリに対してTrivy/Syftを実行し、自社ソフトウェアのコンポーネント構成を把握する。既知の脆弱性の数とライセンス構成を確認し、リスクの全容を理解する
  2. CI/CDパイプラインにSBOM生成を組み込む: GitHub ActionsやGitLab CIにSBOM生成と脆弱性スキャンのステップを追加。Critical/Highの脆弱性がある場合はビルドを失敗させるゲートチェックを設定する
  3. 規制動向をウォッチし、準備を進める: EU CRA（2027年施行）と日本の経産省ガイドライン（2026年度改定）のタイムラインを把握し、自社の対応ロードマップを策定。特に海外取引がある企業はEU CRA対応を優先する

ソフトウェアサプライチェーンの透明性は、セキュリティだけでなく信頼性の問題です。「何が入っているか分からないソフトウェア」が許容される時代は終わりに向かっています。

この記事をシェア

XはてブLinkedIn

「セキュリティ」カテゴリの記事

「セキュリティ」の記事をもっと見る

関連記事

新着記事