近年、Log4Shell（Log4j脆弱性）やSolarWinds事件など、ソフトウェアサプライチェーンを狙った攻撃が深刻な経営リスクとなっています。こうした背景から、米国大統領令14028や経済産業省のガイドラインで導入が推進されているのが SBOM（Software Bill of Materials：ソフトウェア部品表） です。本記事ではSBOMの基本から導入手順、サプライチェーンリスク管理への活用までを実務目線で解説します。
SBOMとは何か
SBOMは、ソフトウェア製品に含まれるすべてのコンポーネント（ライブラリ・OSS・依存パッケージ）を機械可読な形式でリスト化した「部品表」です。製造業のBOM（部品表）のソフトウェア版と考えると分かりやすいでしょう。
SBOMが解決する課題
- 脆弱性の即時可視化：新たなCVEが公表された際、影響を受ける製品・バージョンを瞬時に特定
- サプライチェーンリスクの透明化：第三者OSS・委託先製品のコンポーネント構成を把握
- 規制・契約要件への対応：米国政府調達・EU CRA・経産省ソフトウェア管理ガイドラインへの準拠
主要なSBOMフォーマット3種
フォーマット | 策定団体 | 特徴 | 主な用途 |
|---|---|---|---|
SPDX | Linux Foundation | ISO/IEC 5962:2021認証、ライセンス情報に強い | OSSライセンス管理・コンプライアンス |
CycloneDX | OWASP | セキュリティ用途特化、VEX対応 | 脆弱性管理・AppSec統合 |
SWID | NIST/ISO | 資産管理に強い、タグベース | ソフトウェア資産・構成管理 |
SBOM導入の5ステップ
- 対象範囲の決定：社内開発製品・調達品・OSSのどこから着手するかを優先度付け
- SBOM生成ツール選定：Syft、CycloneDX CLI、Trivy、Microsoft SBOM Toolなど
- ビルドパイプラインへの組み込み：CI/CDで自動生成・成果物として保存
- 脆弱性スキャンとの連携：Grype、Dependency-Track、Snykと統合し継続監視
- VEX（脆弱性影響評価）の運用：検出された脆弱性が実際に悪用可能か判断・伝達
SBOM運用でつまずきやすい3つのポイント
1. 誤検知への対応
SCA（Software Composition Analysis）ツールは高頻度で誤検知を生みます。VEX文書で「該当製品では悪用不可」と明示する運用が現実解です。
2. 委託先からのSBOM取得
外注ベンダーへのSBOM提出義務化は契約条項に明記する必要があります。経産省ガイドラインの参考契約条項を活用しましょう。
3. SBOMの保管と共有
製品の全ライフサイクル（販売終了後も）SBOMを保管する必要があるため、ストレージ戦略と共有ポリシーが重要です。
規制動向：2026年時点のポイント
- 米国：大統領令14028により連邦政府調達ソフトウェアへSBOM提出が義務化
- EU：CRA（Cyber Resilience Act）でデジタル製品全般にSBOM相当の文書化を要求
- 日本：経産省「ソフトウェア管理に向けたSBOMの導入に関する手引」第2版を公表、医療機器・自動車業界で先行義務化
まとめ：SBOMは「準備するもの」から「使うもの」へ
SBOMは単に生成して保管するだけでは価値が出ません。脆弱性管理・契約管理・インシデント対応プロセスと連携させて初めて、サプライチェーンリスクを劇的に削減できます。AEVUSではSBOM導入支援から脆弱性管理プロセスの構築まで、お客様のフェーズに合わせて伴走します。
Log4Shellのような重大脆弱性が次に発生したとき、自社製品のどこに影響が出るかを5分以内に説明できる体制を作ることが、SBOM運用の最終目標です。
