Software Trust Manager 06-10-2026

SBOM に必要なのは「提供」ではなく「証明」

ソフトウェア部品表（SBOM）の導入は加速しています。しかし、「SBOM を保有していること」と、その内容を信頼できることは同じではありません。顧客や監査担当者が求めているのは、出荷されたソフトウェアと文書化された内容が一致していることを示す証拠です。SBOM への署名は、単なるインベントリリストを検証可能な証明へと変える手段です。

デジサートのState of Software Supply Chain Security 2026 調査は、そのギャップを明確に示しています。現在、SBOM を積極的に提供している組織はわずか 11% です。そして、SBOM を提供している組織のうち、常に署名しているのは 17% に過ぎません。

監査対応の観点から見た SBOM とは

ソフトウェア部品表（SBOM）は、ソフトウェア成果物に含まれるコンポーネントの構造化された一覧です。通常、パッケージ名、バージョン、ライセンス、依存関係などが含まれます。

署名されていない SBOM は、証拠のない主張に過ぎません。

SBOM が後から編集できるのであれば、その来歴（Provenance）を証明することはできません。また、特定のビルドに紐付けられていなければ、リリースの完全性を証明することもできません。

なぜ SBOM は実運用で失敗するのか

SBOM は、本来であれば非常にシンプルな問いに答えるためのものです。「このソフトウェアリリースにはどのコンポーネントが含まれているのか？」という問いです。

しかし、多くのプログラムが苦戦しています。なぜなら、SBOM の課題は概念的なものではなく運用上の問題だからです。State of SSC Security レポートでは、主な阻害要因が明らかになっています。

これらは特殊なケースではありません。むしろ、「CycloneDX 形式でエクスポートできます」という最初のデモの後に SBOM プログラムが停滞する理由そのものです。

SBOM 署名：インベントリと完全性を結ぶ欠落したリンク

SBOM に関する議論の多くは可視性に焦点を当てています。一方で成熟したプログラムは、適用可能性（Enforceability）に焦点を当てています。

State of SSC Security レポートは、SBOM 署名への取り組みが一貫していないことを示しています。SBOM に常に署名している組織はわずか 17% であり、多くの組織は条件付きで署名するか、将来的な導入を計画している段階です。

攻撃者は最も強力な制御を狙うのではなく、最も弱い部分を狙います。署名されていない SBOM は、改ざんの隠蔽、ソフトウェア内容の偽装、侵害の発生源の隠蔽などのために変更される可能性があります。

これにより検証ギャップが生じます。受領者が SBOM の真正性を確認できなければ、暗号学的な証明ではなく信頼に依存せざるを得ません。

SBOM 署名は、このギャップを解消し、ソフトウェアの完全性を検証可能にします。

SBOM 署名が保証すべきこと

署名済み SBOM は、次の 3 つを提供するべきです。

真正性：SBOM が共有フォルダではなく、自社のパイプラインから生成されたことを証明する。
完全性：SBOM が生成後に変更されていないことを保証する。
追跡可能性：SBOM が特定の成果物、ビルド、およびリリースに対応していることを示す。

SBOM 署名をベストプラクティスではなく必須要件にする

レポートの戦略的提言は明確です。SBOM 署名をリリースプロセスにおける必須ステップにすることです。これが、「SBOM を作成できる」と「何を出荷したかを証明できる」の違いです。

拡張可能な現実的ポリシーは次のとおりです。

すべてのリリース成果物について、CI/CD 内で SBOM を生成する。
すべての SBOM に自動的に署名する。
すべての署名を保護された鍵で生成する。
すべての署名済み SBOM を監査用に保管し、取得可能にする。
すべての利用者が内容を信頼する前に署名を検証できるようにする。

CI/CD を遅延させない実践的な SBOM ワークフロー

SBOM をリリーススピードに対応させるには、手順の順序が重要です。

1. ビルド工程で SBOM を自動生成する。

SBOM 生成は、独立したコンプライアンス作業ではなく、ビルドプロセスの一部であるべきです。CI/CD においてデフォルトで自動生成しましょう。

2. SBOM を出荷する成果物に紐付ける。

リリース情報と関連付けられていない SBOM は検証が困難です。ダイジェストやビルドメタデータなどの不変識別子を使用して、SBOM を特定のイメージ、バイナリ、またはパッケージに関連付けます。

3. 毎回自動的に SBOM へ署名する。

手動による署名プロセスは、リリースのプレッシャーの中で破綻しがちです。SBOM 署名はリリースワークフローの一部として自動化しましょう。

4. 署名鍵を保護されたシステムに保管する。

開発者の端末上に署名鍵を保管することは不要なリスクを生みます。成熟したプログラムでは、堅牢な鍵保管環境を利用し、鍵管理をリリースワークフローへ組み込んでいます。

5. 下流チームが簡単に検証できるようにする。

脆弱性が発見された際、チームは影響を受けるリリースを迅速に特定する必要があります。そのためには、信頼でき、取得可能で、検証可能な SBOM が必要です。

DigiCert Software Trust Manager の役割

多くの SBOM プログラムが停滞する理由は、「証明」のレイヤーを後付けしているためです。

DigiCert Software Trust Manager は、ソフトウェアサプライチェーン全体においてポリシー主導の署名を運用レベルで実現するために設計されています。レポートでは、Software Trust Manager がコード署名証明書、鍵、ワークフローの管理、自動署名、改ざん防止、および FIPS 準拠 HSM によるコンプライアンス強制の手段として紹介されています。

SBOM の観点では、これは重要です。SBOM 署名には以下が必要だからです。