はじめに

InspectorのECR継続スキャンにおいて、最新のコンテナイメージで検知した脆弱性は、基本的には古いコンテナイメージでも検知されます。
理由としては、MWバージョンが最新のコンテナイメージ < 古いコンテナイメージとなることは基本的にはなく、最新のコンテナイメージで脆弱性を含んでいるMWバージョンは、古いコンテナイメージのMWバージョンでも同じ脆弱性を含んでいる可能性が高いからです。

例えばコンテナイメージのライフサイクルを10世代としている場合、最新のコンテナイメージで検知した脆弱性は、残りの9個のコンテナイメージでも検知される可能性が高く、この場合は同じ脆弱性が10個重複して検知されてしまいます。
実際に、あるシステムで後からInspectorを有効化した際、大量の脆弱性がコンテナイメージに含まれており、脆弱性 × 全世代分で数千個の脆弱性が通知されてくるという、阿鼻叫喚な経験を筆者は体験したことがあります。

当初、InspectorのECR継続スキャンには、Push/Pullからの経過日数が何日以内のコンテナイメージをスキャン対象とするかの設定があったのですが、経過日数の設定値次第では最新のコンテナイメージがスキャンの対象から除外される可能性があることに加えて、必ず最新のコンテナイメージのみをスキャン対象とすることはできなかった為、この問題への対処としては不十分でした。

本記事公開時点では、Push/Pullからの経過日数に加えて、最終使用日からの経過日数が何日以内のコンテナイメージをスキャン対象とする設定が追加されてます。
最終使用日からの経過日数に設定できるのが14日からではありますが、この期間中の重複検知が許容できるのであれば、未使用のコンテナイメージを再スキャン対象から外すことで、この問題を解決するのもありだと思います。

この問題を解決する案として、コンテナイメージがPushされる度に、Inspectorの抑止ルールを自動更新し、最新のコンテナイメージ以外の脆弱性を抑止対象とする方法をコチラで紹介しています。
しかし、上記方法では、Lambdaによる独自実装が必要になる為、取り入れへのハードルが若干高いという問題がありました。

そこで、今回は昨年(2025年)のアップデートで追加された、コンテナイメージと実行中のコンテナのマッピング機能を使用して、最新のコンテナイメージの脆弱性のみを検知する方法を紹介します。

使用中のコンテナイメージ ≒ 最新のコンテナイメージではありますが、通常の運用では未使用のコンテナイメージは基本、非最新のコンテナイメージであるという考えのもと、本方法を紹介します。

設定方法

設定は非常に簡単で、Inspectorで以下の抑止ルールを作成するだけです。

  • 抑制ルールのフィルター: 使用中の画像数 <=0

試してみた

適当なECRレポジトリに脆弱性が含まれた適当なコンテナイメージを二世代分Pushします。

最新のコンテナイメージを使用したECSをデプロイします。

この時点では、最新のコンテナイメージと一世代前のコンテナイメージとで、同じ脆弱性が重複して検知されています。
また、最新のコンテナイメージで検知している脆弱性の詳細(影響を受けるリソース)に、デプロイされたECSタスク/EKSポッドの数が記載されています。

デプロイされたECSタスク/EKSポッドの数ですが、新しいコンテナイメージの場合、ここのカウントアップに最大36時間かかる場合があります。
本方法では「デプロイされたECSタスク/EKSポッドの数が」0か否かを重複排除の条件として使う為、既に脆弱性が含まれているコンテナイメージを新規Pushした場合、Push時のスキャンでは脆弱性が検知されません。その為、CI/CDパイプラインでコンテナイメージのスキャンを行い、脆弱性を潰した状態でのPushを行うベストプラクティスな開発サイクルが必要な点、注意して下さい。

前述の設定方法で記載した抑止ルールを作成します。

抑止ルール作成後、脆弱性の検出結果を確認すると、未使用のコンテナイメージの脆弱性が消えていることが確認できます。

未使用のコンテナイメージの脆弱性は、抑止ルールによりステータスが「Suppressed」となっているので、通知で使用するEventBridgeRuleでステータスが「Active」の脆弱性のみフィルタリングするようにすれば、最新のコンテナイメージ(非未使用コンテナイメージ)の脆弱性のみ通知が可能です。

さいごに

AWSネイティブな機能で、かつ非常にシンプルな方法で脆弱性の重複検知問題を解決することができました。
最新コンテナイメージの脆弱性のみを厳密に検知したい場合は、コチラの方法をご利用ください。