コンテナ環境におけるSBOM生成のベストプラクティス：ビルド時生成の優位性と有用なSBOMの5つの要件

要点

• コンテナ開発のワークフローにおいて、信頼性の高いSBOM（ソフトウェア部品表）を効率的に生成するためのベストプラクティスを解説する。
• SBOMの生成手法にはビルド時に組み込む方法とビルド後にスキャンする方法があり、依存関係を正確に把握するにはビルド時生成が適している。
• 生成されたSBOMが実際に役立つものにするためには、網羅性、正確性、新鮮さ、検証可能性、規格準拠という5つの基準を満たす必要がある。
• SBOM生成ツールは高いビルド権限で動作するため、ツールの参照先をイミュータブル（不変）な値にするなどのセキュリティ考慮が求められる。

• ソフトウェアサプライチェーンの安全性を確保する上で、成果物を構成するコンポーネントを一覧化したSBOM（ソフトウェア部品表）の重要性が急速に高まっています。しかし、多くの組織がSBOMの生成に課題を抱えており、ツールの乱立や出力結果の不整合が開発者の負担となっています。本記事では、コンテナ環境において形骸化しない、実際に機能するSBOMを生成するためのポイントを整理します。

2つの生成タイミング：ビルド時とビルド後

SBOMの品質に最も大きな影響を与える決定は、どのタイミングで生成を行うかです。アプローチは大きく「ビルド時生成」と「ビルド後スキャン」の2つに分かれます。

ビルド時生成の仕組みとメリット

ビルド時生成は、コンテナイメージを構築するビルドシステムそのものに生成プロセスを組み込む手法です。ジェネレーターは、ビルド時に解決された依存関係ツリー、パッケージマネージャーの定義ファイル、およびビルドコンテキスト全体に直接アクセスできます。
コンテナビルドシステムがネイティブのアテステーション（検証用メタデータ）をサポートしている場合、イメージのビルド中にSPDX形式のSBOMを自動生成し、in-totoアテステーション（改ざん防止のためのメタデータ）として添付できます。これにより、イメージ本体とSBOMを1回のアクションでレジストリへ同時にプッシュすることが可能になります。
この手法の最大の利点は、構成の正確さにあります。ビルド時の実際のグラフから情報を得るため、ビルド後のスキャナーが見落としがちな間接依存関係（直接依存しているパッケージがさらに依存している下位パッケージ）まで確実に網羅できます。

ビルド後スキャンの特徴と課題

ビルド後スキャンは、完成したコンテナイメージなどの成果物を外部からスキャンし、中身をリバースエンジニアリング（逆コンパイルして解析）する手法です。パッケージマネージャーのメタデータや、ファイル特有の署名、既知のパターンを頼りに内部のコンポーネントを検出します。このアプローチは、ビルド方法に関わらず、すべてのOCI（コンテナの業界標準規格）準拠イメージに適用できる柔軟性があります。
しかし、その代償として検出漏れのリスクがあります。静的にリンクされたバイナリ、ソースコードから直接取り込まれた依存関係、あるいは中間ビルドステージでインストールされ、最終レイヤーに痕跡を残したOSパッケージなどは、スキャナーで検出できないケースが多々あります。スキャナーはあくまで推測（ヒューリスティック）に基づいて検出を行うため、実際のビルド履歴と完全に一致するとは限りません。

どちらを選択すべきか

自社でビルドシステムを管理し、アクセス権がある環境であれば、ビルド時生成を選択するのがベストプラクティスです。一方で、ビルドプロセスに介入できないサードパーティ製のイメージや、ビルドシステムと統合されていない古いレガシーな成果物を扱う場合には、ビルド後スキャンが適切な選択肢となります。

役立つSBOMにするための「5つの基準」

単にSBOMファイルを生成するだけでは、セキュリティやコンプライアンスの要求を十分に満たせません。価値あるSBOMとして機能させるためには、以下の5つの基準を満たす必要があります。

1. 網羅性（Completeness）

成果物の全レイヤーに含まれるすべてのコンポーネントが記録されている必要があります。ベースイメージのOSパッケージだけでなく、各パッケージマネージャー経由で導入されたアプリケーション依存関係、ビルド時に追加されたツール類も対象です。
特にマルチステージビルドや、不要なシェルなどを含まない極小のベースイメージ（distrolessなど）を利用する場合、スキャナー単体では依存関係の追跡が困難になります。各ビルドステージの依存関係グラフにアクセスできるビルド時生成こそが、網羅性を確保する唯一の方法です。

2. 正確性（Accuracy）

SBOMには、バージョン範囲の指定ではなく、実際にインストールされた解決済みのバージョンを記録しなければなりません。マニフェストファイルで「^4.17.0」と指定されていても、実際にインストールされたのが「4.17.21」であれば、その正確なバージョンを記述する必要があります。

3. 新鮮さ（Freshness）

SBOMはビルドが実行された瞬間のスナップショットです。成果物が再ビルドされるたびにSBOMも再生成され、常に最新の状態を保つ必要があります。

4. 検証可能性（Verifiability）

SBOMが改ざんされておらず、信頼できるビルドシステムで正しく生成されたことを証明できる状態です。暗号署名や、ビルドがどこでどのように行われたかを記録するプロベナンス（ビルドの出自）アテステーションによって、SBOMと成果物のハッシュ値を厳密に紐付けます。

5. フォーマットへの準拠（Format compliance）

SPDXやCycloneDXといった業界の標準仕様に準拠していることです。スキーマに沿った正しいフォーマットで出力することで、他のスキャニングツールやポリシー制御エンジンとの相互運用性が確保されます。

一部のベースイメージには、ビルド時にあらかじめこれらの基準をクリアしたSBOMや、SLSA（ソフトウェアサプライチェーンセキュリティのフレームワーク）ビルドレベル3に準拠したプロベナンス情報が添付されています。これらを利用することで、ベースイメージ層のSBOM管理の手間をなくし、開発者自身のアプリケーションレイヤーの生成作業に集中することができます。

生成ツールチェーンにおけるセキュリティの考慮

SBOMを生成するツールチェーンそのものが攻撃対象（アタックサーフェス）となる点にも注意が必要です。SBOM生成ツールはビルドシステム内で高い権限（昇格されたアクセス権）を持って動作するため、安全性を高める考慮が必要です。具体的には、使用するツールのバージョンやイメージをイミュータブル（不変）な参照で固定し、不正な差し替えを防ぐといったセキュリティ対策を導入することが推奨されます。

補足

Omdiaの2026年ソフトウェアサプライチェーンセキュリティレポートによると、約86%の組織がSBOM生成に課題を感じています。その大きな要因として、多様な成果物に対して異なるスキャナーを組み合わせることで生じる、出力結果の不整合が挙げられています。