近年、「SBOMを提出してほしい」と取引先から求められるケースが急増しています。とくに製品にソフトウェアを組み込んで納品・販売する企業では、対応できないと取引条件を満たせないことも。SBOMの基礎と初動を整理します。
SBOMとは
SBOM（Software Bill of Materials＝ソフトウェア部品表）は、あるソフトウェアがどんな部品（OSS・ライブラリ）で構成されているかの一覧です。製造業の「部品表（BOM）」のソフトウェア版にあたります。
代表的な標準フォーマットは2つ：
| フォーマット | 主な特徴 |
|---|---|
| SPDX | Linux Foundation 由来。ライセンス情報に強い。ISO/IEC 5962 として国際標準化 |
| CycloneDX | OWASP 由来。セキュリティ・脆弱性管理に強い |
なぜ今、求められるのか
- サプライチェーンセキュリティ：使っているOSSに脆弱性が出たとき、影響範囲を即座に特定するため
- ライセンスコンプライアンス：どのライセンスのOSSが含まれるかを把握するため
- 規制対応：米国大統領令14028、EU CRA（サイバーレジリエンス法）など、SBOMを前提とする規制が拡大
取引先から求められたら——初動5ステップ
- どの製品・どの粒度で求められているか確認（依存パッケージ単位か、ソース全体か）
- 依存関係（package.json / requirements.txt / go.mod 等）を棚卸し
- ツールでSBOMを生成（SPDX または CycloneDX）
- 含まれるOSSのライセンスを確認し、配布上のリスクを洗い出す
- 提出フォーマット・更新頻度を取引先とすり合わせ
SBOMは「作って終わり」ではない
SBOMは出した瞬間に、含まれるOSSのライセンス義務（表示・ソース提供）や脆弱性が可視化されます。つまり「SBOMを作る」と「コンプライアンス対応」はセットです。SBOMを出したら、そこに GPL/AGPL のような注意すべきライセンスが無いか、配布して問題ないかまで点検するのが本来の対応です。
当社では、依存マニフェスト／SBOMをお預かりし、含まれるOSSのライセンス義務と配布可否の判断までを1枚のレポートにまとめてご提供しています。