コンテナ開発におけるソフトウェアサプライチェーンセキュリティの重要プラクティスを解説
要点
- コンテナベースのシステム開発において、信頼できるコンテンツの選択やビルドパイプラインの保護など、サプライチェーンセキュリティを向上させる実践的な方法を解説する。
- ベースイメージは、不要なコンポーネントを排除した最小限のものを選択し、タグではなくSHA256ダイジェストを用いて固定する。
- ビルドプロセスでは、成果物の出所やビルド環境を暗号技術によって証明する「ビルドプロベナンス」と「SBOM」を継続的に生成する。
- CI/CDインフラ自体を保護するため、ビルド環境の分離やシークレットの制限、プラグインのコミットSHAによる固定を徹底する。
ソフトウェアを開発しデプロイするまでのプロセス全体（ソフトウェアサプライチェーン）のセキュリティ対策は、重要性が急速に高まっています。2025年には、開発プラットフォームのnpmにおいてオープンソースのマルウェアや自己複製型ワームが確認され、サードパーティが関与するデータ侵害の割合も前年比で倍増しました。本記事では、コンテナベースのシステムを構築・配信する開発チームに向けて、サプライチェーンを保護するための具体的なセキュリティプラクティスを整理して説明します。
1. 信頼できるコンテンツの選択と管理
開発チームが最初に取り組むべきなのは、信頼できる土台の上にシステムを構築することです。
検証された最小限のベースイメージの選定
すべてのコンテナイメージは、その元となるベースイメージ（コンテナの基本となるOSや実行環境を含むイメージ）のセキュリティ状態を引き継ぎます。ベースイメージに修正されていない脆弱性や古いライブラリが含まれていると、それらのリスクが自作のイメージにも伝播してしまいます。
そのため、ベースイメージの選定においては、以下のような要素を満たすものが推奨されます。
- SBOM（ソフトウェア部品表：ソフトウェアに含まれる部品の一覧）が付属していること。
- SLSA（ソフトウェア成果物の安全性を確保するためのセキュリティ基準）のビルドレベル3に準拠したプロベナンス（ビルドの出所情報）が提供されていること。
- 検証可能な暗号署名があること。
シェルやパッケージマネージャー、不要なユーティリティを排除した「最小限のイメージ」を採用することで、攻撃者が悪用できる要素（攻撃面）を減らすことができます。
依存関係のピン留めと整合性の検証
Dockerfile内で「python:3.12」のようなタグを用いてベースイメージを指定していると、同じタグであっても、将来的に指し示す実体であるイメージダイジェストが変わってしまうことがあります。これにより、意図しない変更や悪意ある改ざんがビルドに混入するリスクが生じます。
これを防ぐためには、タグではなく「SHA256ダイジェスト」を用いてイメージを一意に固定（ピン留め）することが有効です。また、ライブラリなどの依存関係もロックファイルを使用して正確なバージョンを固定し、CI（継続的インテグレーション：ビルドやテストを自動化する手法）の実行時に整合性を検証して、一致しない場合はビルドを失敗させる仕組みを構築します。これにより、アップストリームの更新に伴う予期せぬ不具合やセキュリティリスクの混入を防ぐことができます。
2. ビルドパイプラインの保護
ソースコードからコンテナイメージを組み立てるビルドパイプラインそのものも、攻撃者にとって価値の高い標的となります。
ビルドプロベナンスとアテステーションの強制
ビルドプロベナンスは、対象の成果物がどのシステムによって、どのソースコードからビルドされたかを証明する情報です。SLSAフレームワークでは、基本的な文書化を行うレベル1から、改ざん防止されたビルドプラットフォームで偽造不可能なプロベナンスを生成するレベル3までの基準が定義されています。
ビルドの実行時には、すべての成果物をソースコミット、ビルド構成、ビルダーの識別情報に紐付ける署名付きのプロベナンスアテステーション（証明書）を生成し、デプロイ前に検証できる状態にすることが求められます。
CI/CDインフラの堅牢化
もしビルドを担うCI/CD（継続的インテグレーション／継続的デリバリー：ビルド、テスト、デプロイを自動化する仕組み）システムが侵害されると、コードレビューを通過した後の段階で悪意あるコードを注入される恐れがあります。これを防ぐための対策として、以下のような方法が挙げられます。
- 各ビルドジョブを、以前のビルド状態が残らないクリーンな使い捨て（一時的）の環境で実行する。
- ビルドジョブがアクセスできる認証情報（シークレット）を、必要最小限に制限する。
- ワークフローで使用するプラグインやアクションは、書き換え可能なタグではなく、完全なコミットSHAで固定する。
- リリースブランチへのマージの条件として、コードレビューの実施やテストの合格を義務付ける保護ルールを設定する。
3. デプロイ前の検証
構築された成果物を本番環境に展開する前、および展開した後の検証プロセスも重要です。
SBOMの継続的な生成と消費
SBOMは、製品のリリース時に一度だけ作成して保管するだけでは十分なセキュリティ効果を得られません。効果的な運用は、すべてのビルド時にSBOMを生成してコンテナイメージにアテステーションとして添付し、その後のプロセス（脆弱性スキャナーやライセンスコンプライアンスチェックなど）で継続的に活用することです。
最新のSBOMが常に手元にあれば、新たなCVE（共通脆弱性識別子：個々のセキュリティ脆弱性に割り当てられる共通の識別子）が発見された際に、自社のどの稼働中ワークロードが影響を受けるかを数分で特定することが可能になります。
補足
元記事では、これらのサプライチェーンセキュリティプログラムを成功させるためには、単なるコンプライアンスのチェックボックスを埋める作業としてではなく、エンジニアリングの規律として取り組むことが最も効果的であると指摘されています。