SBOMとは

この記事は約 2 分で読めます

SBOM (Software Bill of Materials) とは、ソフトウェアを構成するすべてのコンポーネント (ライブラリ、フレームワーク、依存パッケージなど) を一覧化した「部品表」です。製造業における BOM (部品表) の概念をソフトウェアに適用したもので、どのバージョンのどのライブラリが使われているかを機械可読な形式で記録します。 2021 年のサプライチェーン攻撃の急増と Log4Shell 事件を契機に、ソフトウェアの透明性を確保する手段として世界的に注目が高まっています。

歴史的背景と法制化

SBOM の概念自体は 2010 年代前半から議論されていましたが、転換点となったのは 2021 年 5 月に米国バイデン大統領が署名した大統領令 14028 (Executive Order 14028) です。この大統領令は、連邦政府に納入するソフトウェアに SBOM の提供を義務付け、ソフトウェアサプライチェーンの透明性を国家レベルで要求しました。同年 12 月に発覚した Log4Shell (CVE-2021-44228) は、この方針の正しさを劇的に証明しました。世界中の組織が「自社のシステムに Log4j が含まれているか」を緊急調査しましたが、 SBOM を整備していた組織は数時間で影響範囲を特定できた一方、未整備の組織は数週間を費やしました。

2 大フォーマット

どちらを選ぶかは用途次第です。ライセンスコンプライアンスが主目的なら SPDX 、セキュリティ管理が主目的なら CycloneDX が適しています。実務では両方を生成して用途に応じて使い分ける組織も増えています。

SBOM の生成フロー

自動生成ツール

SBOM を手動で作成するのは非現実的です。現代のソフトウェアは数百から数千の依存関係を持つため、自動生成ツールの活用が前提になります。代表的なツールとして、 Anchore 社の Syft はコンテナイメージとファイルシステムの両方から SBOM を生成でき、 CI/CD パイプラインへの組み込みが容易です。 Aqua Security の Trivy は脆弱性スキャンと SBOM 生成を 1 つのツールで実行でき、CVE データベースとの照合まで一気通貫で行えます。 GitHub の Dependency Graph や GitLab の Dependency Scanning も SBOM 生成機能を内蔵しており、リポジトリ単位での管理が可能です。

よくある誤解

「SBOM を作れば安全」という誤解がありますが、 SBOM はあくまで可視化のためのツールであり、それ自体がセキュリティを向上させるわけではありません。重要なのは SBOM を継続的に更新し、新たに公開された脆弱性と照合してパッチ管理につなげる運用プロセスです。また、 SBOM は直接の依存関係だけでなく、推移的依存 (依存先がさらに依存しているライブラリ) まで含める必要があります。 Log4Shell のケースでも、多くの組織は Log4j を直接使っていなくても、利用しているフレームワークが内部的に Log4j に依存していたために影響を受けました。

現場での使用例

「Log4Shell が公開された翌朝、 SBOM を整備していた私たちのチームは 2 時間で影響を受ける 12 のサービスを特定し、午前中にはすべてのパッチ適用を完了しました。一方、 SBOM 未整備の部署は 2 週間かけて手動調査を行い、その間もリスクにさらされ続けていました。」

サプライチェーンセキュリティの全体像はサプライチェーン攻撃の記事で、オープンソースの安全な利用方法はオープンソースセキュリティ監査の記事で詳しく解説しています。組織のセキュリティ基盤づくりにはスタートアップのセキュリティチェックリストも参考になります。サプライチェーンセキュリティの関連書籍 (Amazon)も実務に役立ちます。