コンテナワークフロー用のSBOMを生成する方法

Omdiaの2026ソフトウェアサプライチェーンセキュリティレポートによると、 86 %の組織がSBOMの生成を困難に感じている。主な要因はツールの乱立です。チームがさまざまな成果物タイプに合わせて異なるスキャナーを寄せ集め、パイプライン全体で一貫性のない出力が得られ、エンジニアリングの時間を結果の調整に費やし、それに基づいて行動する時間が奪われています。

SBOM（部品表）は、セキュリティチームが脆弱性の開示にどのように対応するか、コンプライアンスチームが監査担当者の要求を満たす方法、そして調達に関する意思決定を行う方法において、重要な役割を果たすようになっている。これにより、発電ステップは耐荷重構造となる。パイプラインが生成するSBOMに推移的依存関係が欠落していたり、解決済みバージョンではなく宣言済みバージョンが記録されていたり、記述対象のアーティファクトに暗号化的にバインドされていなかったりすると、そのデータに基づいて行われるすべての下流の決定にそのギャップが引き継がれます。

この記事では、SBOMの品質を左右する決定事項、つまり、いつどこで生成するか、実用的な出力と単にチェックボックスにチェックを入れるだけのデータを区別する要素、そして画像ポートフォリオが拡大するにつれて生成の信頼性を維持する方法について解説します。

生成タイミング：ビルド時 vs. ビルド後

SBOMの品質に最も影響を与える唯一の決定は、SBOMをいつ生成するかということです。大きく分けて2つのアプローチがあり、それぞれ大きく異なる結果をもたらす。

ビルド時生成

ビルド時の生成機能は、ビルドシステム自体に組み込まれています。ジェネレーターは、解決済みの依存関係ツリー、パッケージマネージャーのファイル、および完全なビルドコンテキストにアクセスできます。その遺物が組み立てられた時にそこにいたため、その遺物に何が使われていたかを正確に把握している。

ネイティブな認証サポートを備えたコンテナビルドシステムは、イメージビルド中にSPDX SBOMを生成し、それをイン・トト認証として添付し、イメージとSBOMの両方を単一の操作でレジストリにプッシュできます。言語固有のビルドプラグインも、アプリケーションの依存関係に関して同様のアプローチを取り、標準のビルドライフサイクルの一部としてSBOMを生成します。

その利点は構造的なものです。ビルド時の生成によって、ビルド後のスキャナーでは見落とされる可能性のある推移的依存関係を含む、すべての依存関係の解決済み状態が捕捉されます。

構築後のスキャン

ビルド後のツールは、完成した成果物をスキャンし、その内容をリバースエンジニアリングします。これらの手法は、パッケージマネージャーのメタデータ、ファイルシグネチャ、および成果物内の既知のパターンを識別することによって機能します。この方法は、構築方法に関係なく、OCI互換のイメージであればどれでも機能します。

その代償は、カバー範囲の狭さだ。静的にリンクされたバイナリ、ベンダー提供の依存関係、および中間ビルド段階でインストールされるOSパッケージは、ビルド後のスキャナーで見落とされることがよくあります。スキャナは検出できたものしか報告できず、検出は実際のビルドグラフから導き出されるのではなく、ヒューリスティックに基づいている。

コンテナイメージについては、ビルド時のSBOM認証の設定方法について、さまざまなビルドワークフローに対応した具体的なフラグやジェネレーターオプションを含め、ドキュメントで詳細に説明しています。

SBOMが役立つ理由

SBOMを生成することと、有用なSBOMを生成することは同じではない。ファイル形式は標準的ですが、SBOMがどのように、いつ作成されたかによって、コンテンツの品質は大きく異なります。実用的なSBOMとチェックボックス式の成果物を区別する5つの基準がある。

1 。完全

完全なSBOMは、すべてのレイヤーとすべてのパッケージタイプにわたる、成果物に含まれるすべてのコンポーネントを網羅しています。これには、ベースイメージからのOSパッケージ、ビルドに含まれるすべてのパッケージマネージャーからのアプリケーション依存関係、およびビルドプロセス中に追加されたツールやユーティリティが含まれます。 

多段階イメージや最小限の基本イメージでは、ここに大きなギャップが生じる。Node フロントエンド、静的バイナリにコンパイルされた C または C++ コンポーネント、およびディストリビューションレスの最終ステージを含む Dockerfile には、3 つの明確な課題があります。Node レイヤーには深い推移的依存関係ツリーがあり、静的にリンクされたバイナリにはディスク上に依存関係マニフェストが存在しないことが多く、ディストリビューションレスのベースにはパッケージマネージャがまったくありません。ビルド後のスキャナーは、静的にリンクされた依存関係を見落とす可能性があり、Nodeツリーを過小評価する可能性があります。各ステージの解決済み依存関係グラフにアクセスできるビルド時生成こそが、全体像を把握する唯一の方法です。

2 。正確さ

正確性とは、SBOMに宣言された範囲ではなく、解決済みのバージョンが記録されることを意味します。パッケージマニフェストには「^ 4 . 17 . 0 」と宣言される可能性があります。しかし、ロックファイル内の解決済みバージョンは4 . 17 . 21です。部品表（SBOM）は、要求された内容ではなく、実際に設置された内容を反映していなければならない。

3 。鮮度

SBOMとは、特定のビルドに関連付けられた、ある時点における製品の状態を示すスナップショットです。アーティファクトが再構築されるたびに、SBOMを再生成する必要があります。古いSBOMは、誤った可視性を生み出す。

4 。検証可能性

検証可能なSBOMとは、消費者が製造システムによって生成されたものであり、改ざんされていないことを確認できるSBOMのことです。暗号署名および認証フレームワークは、SBOMを特定のアーティファクトダイジェストに結び付け、さらにアーティファクトがどこでどのように構築されたかを記録する構築履歴情報も提供します。

5 。形式 コンプライアンス

SPDXやCycloneDXなどの標準フォーマットでは、必須フィールドとオプションフィールドが定義されています。スキーマに対して検証を行うSBOMは、スキャンツール、ポリシーエンジン、およびコンプライアンスワークフロー間で相互運用可能です。そうでないものの中には、現在お使いのツールでは動作するかもしれませんが、ツールを変更すると動作しなくなるものもあります。

一部の基本イメージには、SLSAビルドレベル3の来歴および利用可能性データとともに、5つの基準すべてを満たすSBOMが既に同梱されています。これらのSBOMは、改ざん不可能な来歴を持つ強化されたビルドプラットフォーム上でビルド時に生成され、暗号署名され、イメージダイジェストに紐づけられた完全な証明書として添付されました。それらは再構築のたびに継続的に再生されるため、人手を介さずに鮮度が維持されます。これらのイメージについては、スタックの最も重要なレイヤーにおける生成に関する疑問は解決済みであり、作業は、その上に重ねるアプリケーションレイヤーの完全なSBOMを生成することに移ります。

あなたの世代のツールチェーンは攻撃対象領域です

SBOMを生成するために使用するツールは、ビルド環境への管理者権限で実行されます。彼らはあなたのソースコード、依存関係ツリー、そしてビルド成果物を読みます。侵害されたジェネレーターは、単に悪い出力を生成するだけでなく、スキャンしたデータを外部に持ち出したり、改ざんしたりする能力も持っています。

これは理論上の懸念事項ではない。GitHub Actionsおよびコンテナイメージのバージョンタグは変更可能です。今日v 2 . 1に固定したツールは、メンテナーアカウントが侵害されたり、タグが強制的にプッシュされたりすると、明日にはひっそりと別のものになる可能性があります。こうしたインシデントにおける情報漏洩の危険期間は通常数時間単位だが、自動化されたパイプラインでは数分以内に侵害されたバージョンが取得される可能性がある。

生成ツールについても、他のビルド依存関係と同様に厳格に扱ってください。

• 不変の参照（バージョンタグではなく、コミットSHA）に固定します。
• 実行前にチェックサムを確認してください。
• 再現性と監査可能性を確保するため、開発マシンではなくCI環境で生成を実行する。
• 生成ツールに関する上流のセキュリティ勧告を監視してください。

これは、より広範なソフトウェアサプライチェーンのセキュリティ課題の一側面です。パイプライン内のすべてのツールは依存関係であり、アプリケーションコードと同様に厳密な検証が必要です。ベースイメージであれば、このリスクを完全に回避できます。改ざん不可能な来歴を持つ強化されたビルドプラットフォーム上で構築されたイメージは、発生源からサプライチェーンのメタデータを、暗号化によってエンドツーエンドで検証された状態で保持します。

SBOM生成をCI/CDに統合する

手動でのSBOM生成は、単発の監査には有効です。生産ワークフローにおいては、生成は自動化され、再現可能であり、配信パイプラインの他の部分と連携している必要があります。このパターンは、CIシステム全体で一貫している。

ビルド時に生成

イメージ生成直後に、ビルドステージのステップとしてSBOM生成を追加します。コンテナイメージの場合、BuildKitの認証フラグが最も信頼性の高い方法です。アプリケーションの依存関係に関しては、言語固有のプラグイン（Maven/Gradleの場合はCycloneDX、Nodeの場合はnpm/yarn）が解決済みの依存関係グラフにアクセスするため、最高品質の出力を生成します。

複数段階のビルドの場合、最終段階のみから生成してください。中間段階では、本番環境のイメージには含まれていないビルドツールやテストフレームワークがインストールされることがよくあります。中間段階に対して生成を行うと、展開されていないコンポーネントがSBOMに含まれてしまい、脆弱性スキャンでノイズが発生する。

証明書のフォーマットを選択してください

SPDXはBuildKitの認証におけるネイティブ出力フォーマットであり、ライセンスコンプライアンスが最優先事項である場合は、より強力な選択肢となります。CycloneDXは、より高度な脆弱性相関分析機能と、より詳細なコンポーネント分類機能を備えているため、セキュリティ重視のワークフローに最適です。利用しているツール（ポリシーエンジン、脆弱性スキャナー、コンプライアンスダッシュボードなど）に推奨設定がある場合は、それに従ってください。両方をサポートしている場合は、コンテナイメージにはデフォルトでSPDXを使用します。これは、BuildKitに組み込まれているジェネレーター以外に追加のツールを必要としないためです。

アーティファクトに取り付ける

SBOMは、それが記述する成果物と同じ場所に保管してください。コンテナイメージの場合、これはアーティファクトストアに別ファイルとして保存するのではなく、レジストリにOCI認証情報として添付することを意味します。証明ベースのストレージにより、SBOMは検索可能、バージョン管理され、特定のイメージダイジェストに紐付けられます。イメージが開発環境からステージング環境、そして本番環境へと昇格される際、SBOMはすべてのレジストリを介してイメージと共に移動するため、必然的にずれが生じる別のコピーおよび同期ワークフローは不要になります。

公開前に検証してください

生成とレジストリへのプッシュの間に検証ステップを追加する。SBOMをフォーマットバリデーター（SPDXとCycloneDXはどちらも公式のスキーマバリデーターを提供しています）に通し、コンポーネント数がアーティファクトに対して妥当であることを確認し、SBOMが正しいイメージダイジェストを参照していることを確認します。200以上のパッケージが含まれていることがわかっているイメージに対して、 12個のコンポーネントを生成するビルドは、パイプラインを失敗させるべきであり、黙って出荷されるべきではありません。

継続的にスキャンして適用する

製造時にSBOM（部品表）を生成することで、出荷される部品を把握できます。継続的なスキャンによって、その後何が脆弱になったかがわかります。新しいCVEは毎日発生しており、構築時には問題がなかったSBOMでも、数週間以内に重大な脆弱性が露呈する可能性があります。SBOMデータに対する継続的な分析により、画像を再取得することなく、新規開示情報を在庫と照合し、ポリシー違反が発生した時点でそれを明らかにする。SBOMをすべてのイメージに添付することで、展開を制御できます。有効なSBOMがないイメージは出荷されず、既知の脆弱性を持つパッケージが設定した深刻度しきい値を超えるイメージも展開されません。

実装の詳細はCIシステムによって異なります。弊社のドキュメントでは、一般的なコンテナビルドワークフロー全体でSBOM証明書を生成および添付するための具体的なフラグと設定について説明しています。

SBOM出力の検証

コンプライアンス報告や脆弱性管理にSBOM出力を利用する前に、以下の品質基準を満たしていることを確認してください。

• コンポーネント数の妥当性チェック： SBOM内のコンポーネント数を、Dockerfile、ロックファイル、およびベースイメージから想定される数と比較します。依存関係が200宣言されているNode.jsアプリは、推移的依存関係を含めると、大幅に多くのエントリを生成するはずです。
• 解決済みバージョン、範囲ではありません: SBOM レコードに特定のバージョン ( 4 . 17 . 21 ) が記録されていることを確認するためにエントリをスポットチェックします。宣言された範囲（^ 4 . 17 . 0 ）ではなく。
• 推移的依存関係の深さ：最上位パッケージだけでなく、推移的依存関係も存在することを確認します。アプリが30の直接的な依存関係を宣言しているにもかかわらず、SBOMに32エントリが含まれている場合、推移的カバレッジが不完全である可能性が高いです。
• OSパッケージの網羅性：ベースイメージのOSパッケージがアプリケーションの依存関係と並んで表示されていることを確認します。
• ダイジェストバインディング：アテステーションが正しいイメージダイジェストを参照していることを確認します。バインドされていないSBOMは、その成果物を正しく記述しているとは限らない。
• フォーマット検証： SBOMをスキーマバリデーターに通します（SPDXとCycloneDXはどちらも公式ツールを提供しています）。

生成を開始し、次に検証を開始します。

SBOM生成機能をパイプラインに追加する最適なタイミングは、次にCI構成を変更する時です。まずは、最もアクセス数の多い作品画像から始めましょう。ビルド時生成を設定し、SBOMを証明書として添付し、上記のチェックリストに基づいて出力を検証します。次に、ポートフォリオの残りの銘柄にも拡大してください。

すぐに作業を開始したい場合は、Docker Hardened Imagesには完全なSBOM、SLSAビルドレベル3の来歴情報、およびOpenVEXデータが既に添付されているため、ベースレイヤーの生成手順を完全に省略できます。Docker Scoutは、その上に構築するすべてのものに対して、 SBOMデータとの継続的な脆弱性照合を行い、イメージポートフォリオ全体にわたってポリシーを適用します。

• Dockerの強化イメージを使い始めよう →
• Docker Scoutで脆弱性監視を体験しよう →

よくある質問

情報源

Omdia、 「ソフトウェアサプライチェーンのセキュリティ確保：AI導入による開発規模拡大を支援する戦略的アプローチ」 、5月2026 。