ECRマネージド署名の今後に期待すること
本記事は、CyberAgent Group SRE Advent Calendar 2025 / AWS Containers Advent Calendar 2025 の23日目の記事です。
2025年11月21日のアップデートにより、ECRにおいて自動でイメージ署名を行えるようになりました。
本記事では、上記のマネージド署名を触ってみた所感を踏まえて、EKS/ECS/Lambdaにおけるイメージ署名・検証やその周辺に関して「今後ここが伸びてほしい」を書き連ねます。
先に結論
- 署名の検証もマネージドだと嬉しい（EKSは別として）
- SBOMやProvenanceは今後の動向に注目したい
アップデートの概要
ECRにイメージをプッシュした際に、自動でイメージ署名を行うことが可能になりました。裏ではAWS Signerが動作しています。
マネージド署名のフロー。公式ブログより
ECR側で単純な設定を行うだけなので、有効化は非常に簡単です。
ハンズオンとしては以下の2点がわかりやすいです。
このアップデートの嬉しさ
従来は自前で署名する必要があり、AWS Signerを使うにしても構築・運用の手間がありました。
例えば以下スライドにあるように、署名ツールのインストールや署名処理の記述などが必要でした。
今回のアップデートによってそれらの手間が不要となり、イメージの改ざん防止を以前よりも簡単に行えるようになりました。
この機能が刺さりそうなのは以下のケースかと思います。
- AWS Signer+Notaryなどで署名していたが、その辺の管理が面倒なのでマネージドに任せたい
- これからイメージ署名を手軽に導入してみたい（後述の理由により賛否あり）
今後の期待
便利になったのは確実ですが、私の期待を2点挙げます。
期待1. 検証もマネージドだと嬉しい
同様に感じた方もいるかと思います。
今回のアップデートのスコープは署名のみであり、検証は依然として別の仕組みが必要です。
作り込みの例:
なお、EKSに関してはKubernetesエコシステムにのっとるのが適していると思うので、マネージドでなくとも良いと思います。
※Lambdaでは、Zipファイルに関してはマネージドの検証がサポートされています。
自前で検証を作り込む場合の課題
1. 検証処理の構築・管理が面倒
検証処理の記述、その実行環境の管理、署名ツールのアップデート運用などが発生します。
また、ECSにおいて先述の公式ブログがLifecycle Hooks(PRE_SCALE_UP)+Lambdaでイメージ検証を行う例を紹介していますが、サンプルがあるとはいえLambda関数のコードまで管理するのは運用上面倒だと感じました。
2. 抜け道の発生リスク
ECSとLambdaにおいては、CI/CDパイプラインからデプロイするのがメインと思いますが、緊急時などにUI/CLIからデプロイする場合や、新しく構築したCI/CDパイプライン等では、検証処理が抜け落ちる可能性があります。
そういった「抜け道」をコントロールプレーンが門番として防いでくれると嬉しいです。
3. 検証状況を一元的に確認しにくい
個別のECSサービスやLambda関数単位で検証設定を行う場合、「どのECSサービス/Lambda関数で検証を有効化できているか」を一元的に確認しにくいです。
これは抜け漏れ検知やガバナンス・監査の観点で不便です。
「このアカウント/クラスター等では、署名検証に成功したイメージしか稼働してません/できませんよ！」とすぐ言える状態が理想と思います。
4. そもそもイメージ署名・検証に大きな手間をかけたくない
ソフトウェアサプライチェーンを保護する上でやるべきことは数多く存在し、イメージ署名・検証によって防げるのはその一部（Push後のイメージの真正性・完全性）です。
npm等のサプライチェーン攻撃が流行る昨今、個人的には、ビルドまでのセキュリティ強化やイメージスキャンの方に相対的には注力したいと考えています。
そのため、イメージ署名・検証にはできるだけ手間をかけずに済ませたいです。
また、改ざん防止という観点では、ECRをイミュータブルで運用したり、イメージのPush元をECRのリポジトリポリシーによって制限することも、選択肢の一つと思います。
こうなってほしい
以上を踏まえて、こうなってほしいという願望です：
- ECS: アカウント/クラスター/サービス/タスク定義単位で検証ポリシーを設定→不適合の場合はタスク定義orサービスの更新に失敗する
- Lambda: コンテナでも、アカウント/関数単位で検証ポリシーのオプションを設定→不適合の場合は関数の更新に失敗する
- Zipファイルでの検証機能と近い形が良いと思います
要はコントロールプレーン側で一元的かつマネージドで（+無料で）検証できたら嬉しいです。
検証までマネージドになれば「署名&検証をとりあえず導入する」がやりやすくなりそうです。
期待2. SBOMやProvenanceも簡単に扱えたら嬉しいかも (ECS,Lambda)
こちらはイメージ署名とは少し別の話で、「嬉しいかも」という温度感です。
KyvernoやRatifyでは、イメージ署名に限らず、SBOMやProvenanceに関しても検証が行えます。
これにより、例えば以下のような制御が可能になります。
- SBOM:
- SBOMが付与されていないイメージの利用禁止
- 特定の脆弱なパッケージの利用を完全禁止
- 指定のセキュリティツールやエージェントが含まれていないイメージの利用禁止
- Kyvernoでの設定例
- Provenance:
- Provenanceが付与されていないイメージの利用禁止
- 特定のパイプライン以外でビルド・テストされたイメージの利用禁止
- Kyvernoでの設定例
現時点で、AWSにおいてSBOM/Provenanceの生成・検証をマネージドで行う方法はなさそうです（あったら教えてください）。[1]
こうなったら良さそう？
- SBOMの生成: マネージド署名同様に、ECRにPushしたら自動で生成&保管される
- Provenanceの生成: CodeBuildやCodePipelineが担う（GitHub Actions等なら自前で）
- SBOM/Provenanceの検証: kyverno等のような条件を書くだけで、デプロイ前にコントロールプレーンが弾いてくれる
- イメージ署名の検証と比較すると条件の柔軟性が求められるのが難しい点かと思います
なおSBOMに関しては、デプロイ前のブロッキングというより、発覚した脆弱性の影響調査に利用することが多いかと思います。
また、そもそもSBOM/Provenance等に取り組む程度は規制に依存するところもあるかと思います。
関連情報
re:Invent 2025にて、GitHub ActionsとOctopus DeployによってSBOMやProvenanceなどのガバナンスを強化するセッションがありました。
おわりに
今回のマネージド署名は、署名部分の構築・運用を簡単にするアップデートでした。
本記事の執筆を通じて、AWSにおけるコンテナセキュリティの現在地を確認できました。
昨今のサプライチェーンセキュリティの重要性も鑑みて、検証側やSBOM/Provenanceに関する今後のアップデートに期待しています。
-
SBOMに関しては
inspector-sbomgen container $IMAGE_URI -o sbom.jsonやaws inspector2 create-sbom-export --s3-destination bucketName=xxxなどのコマンドで生成できますが、それをパイプラインに組み込む必要があります。https://docs.aws.amazon.com/inspector/latest/user/sbom-generator.html ↩︎
Discussion