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)も実務に役立ちます。