Amazon InspectorのECR再スキャン期間をDAYS_3に設定して4日間のログを確認してみた

はじめに

Amazon InspectorのECR継続スキャンに、再スキャン期間としてDAYS_3とDAYS_7が新たに追加されました。設定手順はいわさの記事を参照してください。

https://dev.classmethod.jp/articles/inspector-ecr-rescan-during/

本記事では実際にDAYS_3を設定し、イメージpushから期間終了の翌日までの挙動をログで確認しました。

検証内容

検証環境

• リージョン：ap-northeast-1
• 検証時期：2026年7月
• rescanDuration：DAYS_30 → DAYS_3に変更
• pullDateRescanMode：LAST_PULL_DATE
• pullDateRescanDuration：DAYS_90（変更なし）
• テストイメージ：python:3.12-slim（Debian 13 / arm64）ベース
• 脆弱性検出用パッケージ：requests==2.28.0, urllib3==1.26.5, setuptools==65.5.0, pip==22.0.4, certifi==2022.12.7
• 観測手段：Inspector2 FindingイベントをEventBridgeルールでCloudWatch Logsに送る構成

本検証ではpush後にpull操作を行っていないため、最終pull日時による監視期間の延長はなく、rescanDuration=DAYS_3が実効的な監視期間となっています。

rescanDurationの設定変更は以下のコマンドで実行しました。

aws inspector2 update-configuration \
  --ecr-configuration '{"rescanDuration":"DAYS_3","pullDateRescanDuration":"DAYS_90"}'

ECR継続スキャンの再スキャン期間やpullDateRescanDurationとの優先関係については公式ドキュメントを参照してください。

初回Finding確認（push直後）

イメージをpushしてから約12秒後に、最初のFindingを確認しました（push時刻7/14 01:05:05 JST → Finding確認01:05:17 JST）。この時点で5件のFindingsを確認しました。

期間中のFinding更新（pushから約32〜41時間後）

7/15 09:00〜18:00 JSTにかけて、複数のFindingでlastObservedAtの更新や、それまで取得結果に含まれていなかったFindingの追加を確認しました。以下はこの期間中に追加を確認した5件です。なお、期間満了直前にACTIVEだった10件の内訳とは一部異なります。

なお、上記5件のうちsetuptools・perl・urllib3の3件は、firstObservedAtがpush時刻付近（7/14 01:05）でした。API上は7/14に最初に観測されたFindingとして記録されていますが、今回の観測で7/15まで取得結果に現れなかった理由は特定できませんでした。

DAYS_3期間満了（pushから約72時間後）

pushから約72時間後の7/17 01:18:40 JSTに、期間満了直前までACTIVEだった10件のFindingsがCLOSEDに遷移しました。検証期間全体では、後続の取得結果から消えた初回の2件（CVE-2026-5928、CVE-2026-7010）を含め、少なくとも12件のFindingを確認しています。

初回検出のCVE-2026-5928（glibc）とCVE-2026-7010（perl）は後続の取得結果に含まれなくなり、代わりにCVE-2026-3219（pip）やCVE-2026-34743（xz-utils）が出現しました。脆弱性DB更新に伴う判定変化と考えられますが、個々の要因は追えていません。

期間満了時にはEventBridgeを通じて各FindingのCLOSEDイベントが発行されました。以下はCloudWatch Logsに記録されたイベントの抜粋です。

{
  "version": "0",
  "id": "example-event-id",
  "detail-type": "Inspector2 Finding",
  "source": "aws.inspector2",
  "account": "123456789012",
  "time": "2026-07-16T16:18:40Z",
  "region": "ap-northeast-1",
  "detail": {
    "findingArn": "arn:aws:inspector2:ap-northeast-1:123456789012:finding/example-finding-id",
    "status": "CLOSED",
    "severity": "MEDIUM",
    "type": "PACKAGE_VULNERABILITY",
    "title": "CVE-2026-50812 - sqlite3",
    "updatedAt": "2026-07-16T16:18:40Z"
  }
}

EventBridge＋CloudWatch Logsの構成により、いつどのFindingが変わったかを追跡できました。

CLOSED後（7/17 01:18以降〜7/18時点）にCloudWatch Logsへ新たなイベントは記録されておらず、list-findingsでもlastObservedAtは7/15 18:00のまま更新されていませんでした。期間満了後は再スキャンが実行されていないことを確認しました。

期間満了後、イメージ自体はECRに残りますが、再スキャン対象からは外れます。再びスキャン対象にするには、イメージをpullするか新たにpushする必要があります。

タイムライン

まとめ

rescanDurationをDAYS_3に設定した結果、push後に監視期間を延長するpullやECS/EKS上での利用がない今回の条件では、pushから約3日後にイメージが継続監視・再スキャン対象から外れ、期間満了直前までACTIVEだったFindingsが一括でCLOSEDになりました。

従来、イメージのpushから14日未満で再スキャンを止めるには、ライフサイクルポリシーなどでイメージ自体を早期に削除する方法が選択肢となっていましたが、必要なバージョンへロールバックできなくなる可能性も伴います。DAYS_3/DAYS_7の追加により、イメージをECRに保持したまま継続スキャン期間を短く設定できるようになりました。多世代のイメージを保持しつつ、利用を終えたイメージに対する再スキャン課金やFindingのノイズを抑えたい環境では、有力な選択肢になりそうです。