Inspector 組織統合設計書

1. 目的・スコープ

目的

Amazon Inspector の組織統合を行い、全アカウントの脆弱性スキャンを一元管理する。これにより以下を実現する。

ECR コンテナイメージ・Lambda 関数・EC2 インスタンスの脆弱性を自動検知
手動での外部サイト確認による脆弱性検知からの脱却
全アカウントの脆弱性 findings を Delegated Admin に集約
Security Hub を通じた統合通知基盤での即時通知
ECR ライフサイクルポリシーによるコスト最適化

スコープ

Inspector 組織統合の設計・構築
Delegated Admin 登録
スキャンタイプの選定（ECR / Lambda / EC2）
ECR ライフサイクルポリシーの設計・導入（コスト最適化の事前準備）
ECR Registry Scanning Configuration の環境別設定（CONTINUOUS_SCAN / SCAN_ON_PUSH）
re-scan duration の最適化
脆弱性対応フロー・SLA の正式化

スコープ外

CI/CD 統合の詳細設計（Inspector 導入・安定稼働後に実装。方針のみ本設計書 Section 9 に記載）
Code Security の詳細設計（Inspector 導入後に手動実行して検出結果を確認してから判断。概要・試算は本設計書 Section 10 に記載）
Lambda Code Scanning（アドオン）の詳細設計（まず Standard Scanning で傾向を見てから判断。Security Hub 設計書に方針記載済み）
S3 Malware Protection（GuardDuty 設計書に今後のタスクとして記載済み。監視対象バケットの整理が先）
Suppression Rules の詳細設計（導入後に findings の傾向を見てから設計）

前提

OU・アカウント構成はOU・アカウント設計書に従う
SCP設計はSCP設計書に従う
Security Hub V2 の Configuration catalog で Inspector が組織全体に有効化済み ※ 「Security Hub (必須機能とその他の機能)」適用時に Inspector ポリシーも自動作成された ※ Inspector ポリシーはスキャンの有効/無効のみ制御する ※ スキャン設定（re-scan duration 等）は Delegated Admin で別途管理が必要
Config Recorder には依存しない（Inspector は SSM / EBS スナップショットで独自収集）

2. 現状と課題

現状（2026-08-27時点）

Inspector 導入状況:
  V2 Organizations ポリシーで全アカウントに Inspector が有効化済み。
  Delegated Admin: fd-security-tooling (860801568046)
  メンバーアカウントの関連付けは自動伝播中。

  Terraform 管理:
    ・common/security-tooling/inspector.tf — aws_inspector2_organization_configuration
    ・各アカウントの aws_inspector2_enabler は削除済み（PR #2712, #2714）
    ・スキャン対象: ECR, EC2, Lambda Standard（Lambda Code / Code Repository は初期不採用）

脆弱性管理の現状:
  ・Dependabot でライブラリ更新（メジャーバージョン除く）
  ・CVE ごとのリアクティブ対応（統一フローなし）
  ・Inspector findings の通知基盤なし（検知しても気づけない）
  ・脆弱性対応 SLA はドキュメント上存在するが実運用で徹底されていない
    - Critical: 24時間以内
    - High: 1週間以内
    - Medium: 1ヶ月以内
    - Low: 次回メンテナンス
  ・SBOM 未導入

ECR の現状:
  ・scan-on-push 有効（全リポジトリ）
  ・IMMUTABLE タグ設定済み
  ・ライフサイクルポリシー: 全リポジトリに設定済み（imageCountMoreThan 20）
  ・Registry Scanning Configuration:
    → staging / infra-dev / develop: SCAN_ON_PUSH（適用済み）
    → production / fd-sys: CONTINUOUS_SCAN

re-scan duration:
  ・Delegated Admin から全アカウントに一括設定済み
  ・Last pull date 60日 + push date 3日

リソース数の調査結果（2026-08-07時点）

ECR イメージ数:
  | アカウント | リポジトリ数 | イメージ総数 |
  |-----------|------------|------------|
  | staging | 73 | 2,748 |
  | production | 71 | 1,586 |
  | develop | 32 | 1,430 |
  | fd-sys | 19 | 615 |
  | infra-dev | 17 | 113 |
  | 合計 | 212 | 6,492 |

  ※ ライフサイクルポリシー未設定のため古いイメージが蓄積
  ※ staging が最多（2,748）

Lambda 関数数:
  | アカウント | 全体 | 90日以内に更新（スキャン対象） | 90日超未更新（対象外） |
  |-----------|------|---------------------------|-------------------|
  | production | 28 | 10 | 18 |
  | fd-sys | 165 | 1 | 164 |
  | staging | 29 | 15 | 14 |
  | develop | 69 | 1 | 68 |
  | 合計 | 291 | 27 | 264 |

  ※ Inspector は90日間未使用の関数を自動的にスキャン対象外にする
  ※ 実質のスキャン対象は27個のみ → コスト影響軽微

EC2 インスタンス数（running）:
  | アカウント | 台数 |
  |-----------|------|
  | production | 5 |
  | fd-sys | 5 |
  | staging | 6 |
  | develop | 6 |
  | 合計 | 22 |

  ※ Fargate 中心のため EC2 は少ない → コスト影響軽微

コスト影響の分析:
  ・ECR が最大のコスト要因（6,492イメージ + re-scan 90日）
  ・Lambda / EC2 はコスト影響軽微
  ・事前にやるべきこと:
    ① ECR ライフサイクルポリシー設定（イメージ総数の削減）
    ② re-scan duration を 90日 → 60日に短縮

課題

#	課題	影響
1	ctop-production（本番）に脆弱性スキャンがない	脆弱性を検知できない
2	Inspector findings の通知基盤がない	検知しても気づけない（Security Hub 導入で解消）
3	脆弱性対応が CVE ごとのリアクティブ対応	統一フロー・SLA が徹底されていない
4	ECR ライフサイクルポリシー未設定	古いイメージが蓄積しコスト増
5	re-scan duration が90日	再スキャン対象が多くコスト増
6	Dependabot がメジャーバージョン更新PRを生成しない	重要なセキュリティ更新を見逃す可能性

3. アーキテクチャ

Security Hub Essentials との関係

Security Hub Essentials プランに Inspector が統合されている。
参照: Security Hub 組織統合設計書

  Security Hub V2 と Inspector の関係:
    ・V2 Configuration catalog で「Security Hub (必須機能とその他の機能)」を適用すると
      Inspector ポリシー（Organizations ポリシー）が自動作成される
    ・Essentials プランに Inspector による脆弱性管理が含まれている
    ・Inspector を別途有効化・課金する必要はない（二重課金なし）
    ・findings は Security Hub に自動集約される
    ・通知基盤は Security Hub 側で構築（詳細は Security Hub 設計書に記載）
    参照: https://docs.aws.amazon.com/securityhub/latest/userguide/security-hub-usage-page.html

  V2 Inspector ポリシーと Delegated Admin の役割分担:
    ・V2 Inspector ポリシー（Organizations ポリシー）:
      - スキャンの有効/無効のみ制御
      - 全アカウントに自動適用
      - ポリシーが Delegated Admin の設定より優先される
    ・Delegated Admin:
      - スキャン設定の管理（re-scan duration、deep inspection 等）
      - findings の集約閲覧
      - Suppression Rules の管理
      - SBOM エクスポート
    ・両方を併用する（AWS ドキュメントで推奨）
    参照: https://docs.aws.amazon.com/inspector/latest/user/admin-member-relationship.html
    参照: https://docs.aws.amazon.com/inspector/latest/user/managing-multiple-accounts.html

  Inspector 固有の設定（CLI で別途実施）:
    ・Delegated Admin 登録（CLI、マネジメントアカウントで実行）
    ・自動有効化設定（Terraform: aws_inspector2_organization_configuration）
    ・ECR re-scan duration の設定（CLI、Terraform リソースなし）
    ・Lambda Code Scanning の有効化（アドオン、初期は不採用）

  Config Recorder との関係:
    ・Inspector は Config Recorder を作成しない
    ・SSM Agent / EBS スナップショットで独自にデータ収集
    ・Config のコスト高騰問題とは無関係

スキャンの仕組み

  ECR イメージスキャン:
    ・Inspector 有効化で Basic Scanning → Enhanced Scanning に自動切替
    ・Basic: OS パッケージの CVE のみ（ECR 課金）
    ・Enhanced: OS パッケージ + アプリケーションライブラリ（npm, pip 等）の CVE（Inspector 課金）
    ・push 時に自動スキャン + 新 CVE 公開時に再スキャン（継続スキャン）
    ・re-scan duration で再スキャン対象の期間を制御

  Lambda スキャン:
    ・Standard Scanning: パッケージ依存関係の CVE チェック（デフォルト有効）
    ・Code Scanning: コード自体の脆弱性チェック（アドオン、初期は不採用）
    ・90日間未使用の関数は自動的にスキャン対象外
    ・注意: カスタマー管理 KMS キーで暗号化された関数はスキャン非対応

  EC2 スキャン:
    ・ハイブリッドモード（デフォルト）:
      - Agent-based: SSM Agent 経由（30分ごとにインベントリ収集）
      - Agentless: EBS スナップショット経由（24時間ごと）
    ・ネットワーク到達可能性分析: 12時間ごと
    ・SSM Agent がない場合は自動的に Agentless でスキャン
    ・プライベートサブネットの EC2:
      SSM 用 VPC エンドポイント（ssm, ssmmessages, ec2messages）が
      production 等で設定済みのため、Inspector スキャンは既に動作可能。
      追加のエンドポイント設定は不要。

  ECR スキャン方式（Registry Scanning Configuration）と re-scan duration の関係:

    ECR と Inspector で役割が分かれている:

      ECR 側（Registry Scanning Configuration）:
        ・「いつスキャンするか」を制御する（トリガー）
        ・CONTINUOUS_SCAN: push 時 + 新 CVE 公開時に自動再スキャン
        ・SCAN_ON_PUSH: push 時のみスキャン（再スキャンなし）
        ・ECR の機能であり、Inspector の機能ではない
        ・Inspector 有効化時に ECR が BASIC → ENHANCED に自動切替され、
          ENHANCED の場合のみ上記の設定が利用可能
        ・アカウント × リージョン単位で設定
        ・フィルタルールで全リポジトリ or 特定リポジトリに適用可能

      Inspector 側（re-scan duration）:
        ・「どの期間のイメージを再スキャン対象にするか」を制御する（期間）
        ・CONTINUOUS_SCAN のリポジトリにのみ効果がある
        ・SCAN_ON_PUSH のリポジトリでは無関係（再スキャン自体がないため）
        ・Last in use date / Last pull date / Push date のモードで起点を選択
        ・push date duration との OR 条件で判定
        ・詳細は Section 7 参照

    環境別の方針:
      ・production: CONTINUOUS_SCAN（デフォルトのまま）
        → 新 CVE 公開時に自動再スキャンで脆弱性を即時検知
      ・staging / infra-dev: SCAN_ON_PUSH に変更
        → staging は ECR コストの最大要因（$340/月）
        → staging イメージは本番と同じものが push されるため、
          production の continuous scan でカバーされる
        → staging で重複して continuous scan する必要はない
        → push 時のスキャンのみで十分
      ・develop: SCAN_ON_PUSH に変更
        → 開発環境は push 時のスキャンのみで十分
      ・fd-sys: CONTINUOUS_SCAN（デフォルトのまま）
        → 本番環境のため production と同じ方針

    設定方法（Terraform）:
      aws_ecr_registry_scanning_configuration で設定
      → 今後のタスク（Section 13）に記載

    コスト影響:
      ・staging の現在コスト内訳（2026年7月実績、Section 11 参照）:
        - ECR 再スキャン: $185.42/月（$0.01/回、CONTINUOUS_SCAN による自動再スキャン）
        - ECR push 時スキャン: $123.50/月（$0.11/イメージ、push 時に発生）
      ・SCAN_ON_PUSH に変更すると:
        - 再スキャン $185.42 → $0（再スキャンが発生しなくなる）
        - 初回スキャンはデプロイ頻度に応じて継続発生
      ・SCAN_ON_PUSH のアカウントでは re-scan duration の設定は無関係
        （再スキャン自体が行われないため）

  ECR Enhanced Scanning への自動切替:
    ・Inspector 有効化で ECR の全リポジトリが自動的に
      Basic Scanning → Enhanced Scanning に切り替わる
    ・Basic: OS パッケージのCVEのみ（ECR課金）
    ・Enhanced: OS + アプリライブラリ（npm, pip等）のCVE（Inspector課金）
    ・既に Inspector 有効化済みの6アカウント → 切替済み、影響なし
    ・未導入アカウント（ctop系, cc-poc, hospital-ai-prod, develop）は
      有効化時に自動切替される
      → アプリライブラリの CVE が新たに検出され findings が増える
      → スキャンは読み取りのみでサービスへの実害はない

  findings の通知:
    ・Inspector findings は Security Hub に自動集約される
    ・通知基盤は Security Hub 側で構築（Inspector 単体の通知基盤構築は不要）
    ・通知の詳細設計（構成、即時通知の条件、日次/週次サマリー等）は
      Security Hub 設計書に記載

4. Delegated Admin

Inspector の Delegated Admin を fd-security-tooling に登録する。
GuardDuty / Config / Security Hub と同じアカウント。

設定:
  ・Delegated Admin: fd-security-tooling (860801568046)
  ・リージョンごとに登録が必要
  ・全サポートリージョンで登録（Security Hub と同じ方針）

手順（マネジメントアカウントで実施）:
  aws inspector2 enable-delegated-admin-account \
    --delegated-admin-account-id 860801568046 \
    --region ap-northeast-1
  ※ 各リージョンで実施

  確認:
  aws inspector2 list-delegated-admin-accounts \
    --region ap-northeast-1

自動有効化:
  ・Delegated Admin から全メンバーアカウントの Inspector を自動有効化
  ・新規アカウント追加時も自動有効化
  ・Security Hub の Organizations policies 経由でも有効化可能

参照: https://docs.aws.amazon.com/inspector/latest/user/designating-admin.html

既存の個別有効化済みアカウントとの関係:
  ・6アカウントで Inspector が個別に有効化済み
  ・組織統合（Delegated Admin + 自動有効化）後、既存の有効化は
    Delegated Admin の管理下に入る
  ・既存の設定（スキャンタイプ等）は引き継がれる
  ・GuardDuty 組織統合と同じパターン

  既存 Terraform モジュールの扱い:
    ・template_modules/options/inspector/main.tf で aws_inspector2_enabler を使用
    ・組織統合後は Delegated Admin から一括管理されるため、
      各アカウントの aws_inspector2_enabler は不要になる
    ・terraform state rm で既存リソースを Terraform 管理から外す
    ・既存モジュールの呼び出しを各アカウントの Terraform から削除
    ・削除手順は適用手順（Section 12）に記載

SCP:
  ・SCP①（deny_disable_security_services）に inspector2:Disable が設定済み
  ・追加の SCP 修正は不要

5. スキャンタイプの選定

  | スキャンタイプ | 採否 | 理由 |
  |-------------|------|------|
  | ECR Enhanced Scanning | ✅ 有効 | コンテナイメージの脆弱性検知。アプリライブラリも対象 |
  | Lambda Standard Scanning | ✅ 有効 | パッケージ依存関係の CVE チェック |
  | Lambda Code Scanning | ❌ 初期は不採用 | アドオン課金。Standard で傾向を見てから判断 |
  | EC2 Scanning | ✅ 有効 | ハイブリッドモード。Fargate 中心だが EC2 も22台稼働中 |
  | CIS Scanning | ❌ 初期は不採用 | EC2 の CIS ベンチマークチェック。無料トライアルなし |

  EC2 スキャンの SSM Agent 確認:
    ・FD の EC2 は SSM Agent が稼働している前提
      （踏み台等で SSM 接続を使用しているため）
    ・Agentless モードもあるため、SSM Agent がなくてもスキャンは可能
    ・詳細な SSM Agent 稼働状況は導入時に確認する

6. ECR ライフサイクルポリシー

方針

Inspector 導入前に ECR ライフサイクルポリシーを設定し、
不要イメージを削減してスキャンコストとストレージコストを最適化する。
適用手順は Section 12 Phase A Step 1 に記載。

現状:
  ・全アカウント合計 6,492 イメージ（ライフサイクルポリシーほぼ未設定）
  ・production の一部リポジトリ（4個）のみポリシー設定済み
  ・tagMutability も fd-sys ではほぼ全リポジトリが MUTABLE のまま
    （IMMUTABLE に統一すべきだが、これは Security Hub の FSBP コントロールで検知される）

目標:
  ・使用中のイメージ + 直近N世代のみ保持
  ・タグなしイメージは自動削除
  ・ストレージコストと Inspector スキャンコストの両方を削減

ポリシー設計

ルール: 最新20個を保持、超過分を削除（実質10世代分）
  ・対象: 全イメージ（tagStatus: "any" — tagged + untagged 両方）
  ・条件: 最新20個を超えるイメージ（imageCountMoreThan: 20）
  ・アクション: expire（削除）
  ※ 1回の push で tagged 1個 + untagged 1-2個が生成されるため、
    20個 ≒ tagged 約10世代分

  1ルールにまとめる理由:
    ・Docker のマルチプラットフォームビルド等で、1回の push で
      tagged 1個 + untagged 1-2個（マニフェストリスト等）が生成される
    ・tagged と untagged はペアで存在するため、まとめて管理する方がシンプル

  20個の根拠:
    ・tagged + untagged がペアで存在するため、実質 tagged 約10世代分
    ・過去イメージの用途はロールバック（直前1-3個）と調査（直前5-10個）
    ・10世代あれば十分。それ以上古いイメージは git から再ビルドで復元可能
    ・20個は必ず残る（デプロイ頻度に関係なく、どんなに古くても保持される）

  方式の選定理由（imageCountMoreThan vs sinceImagePushed）:
    ・imageCountMoreThan（最新N個保持）を採用
      → 必ずN個は残るため、全イメージが消えるリスクがない
    ・sinceImagePushed（push からN日経過で削除）は不採用
      → デプロイ頻度が低いサービスで全イメージが消える危険がある
      → 例: 1年間デプロイなし + 90日設定 → 全イメージ削除 ❌

  コスト影響（10個 vs 20個）:
    ・ストレージ差: 約 $19/月（939個 × 200MB × $0.10/GB）
    ・スキャン差: ほぼゼロ（re-scan duration 60日で制御されるため）
    ・安全性を優先して20個保持で問題ない

  削減効果:
    | アカウント | 現在 | 20個保持後 | 削減率 |
    |-----------|------|----------|--------|
    | staging | 2,748 | 1,003 | 64% |
    | production | 1,586 | 700 | 56% |
    | develop | 1,430 | 441 | 69% |
    | fd-sys | 615 | 144 | 77% |
    | infra-dev | 113 | 113 | 0%（20個未満のリポが多い）|
    | 合計 | 6,492 | 2,401 | 63% |

適用手順:
  1. 各アカウント・各リポジトリの現在のイメージ数を調査
  2. 使用中のイメージ（ECS タスク定義で参照されているもの）を特定
  3. ライフサイクルポリシーを Terraform で設定
     → 既存の ecr モジュール（modules/ecr/main.tf）に aws_ecr_lifecycle_policy を追加
     → 変数 ecr_image_retention_count（デフォルト20）を variable.tf に追加
  4. 適用後のイメージ数を確認
  5. Inspector / Security Hub 導入へ進む

Terraform 管理:
  ・aws_ecr_lifecycle_policy で全リポジトリに統一ポリシーを適用
  ・既存の ecr モジュール（modules/ecr/main.tf）に追加

7. re-scan duration の最適化

re-scan duration とは:
  ・Inspector が ECR イメージを「継続スキャン」する期間の設定
  ・期間内であれば新しい CVE が公開された時に自動で再スキャンする
  ・期間を過ぎたイメージは再スキャン対象外になる（イメージ自体は削除されない）
  ・アカウント × リージョン 単位の設定（リポジトリ単位では変更不可）
  ・2つの独立した設定がある（OR 条件で判定）:
    ① re-scan duration（モード + 期間）:
       - モード: Last in use date / Last pull date / Push date の3つから1つ選択
       - 期間: 14日 / 30日 / 60日 / 90日 / 180日
    ② push date duration（モードに関係なく常に併用可能）:
       - push 日を起点とした監視期間
       - 期間: 14日 / 30日 / 60日 / 90日 / 180日 / Lifetime（無期限）
    ・①か②のどちらかの条件を満たしていれば再スキャン対象

現状:
  ・全アカウント 90日設定（レガシーデフォルト）
    ※ develop（Virginia）のみ 14日（2025-04-04 に変更済み）
  ・モード: Last pull date（最後に pull された日が起点）

変更:
  ・モード: Last pull date のまま維持
  ・期間: 90日 → 60日に短縮
  ・push date duration: 90日 → 3日に短縮（最小値、無効化は API 仕様上不可）

モード選定の経緯:

  3つのモードの比較:
    | モード | 起点 | メリット | デメリット |
    |--------|------|---------|-----------|
    | Last in use date | ECS/EKS で使用中の日 | 稼働中なら常にカバー。デプロイ頻度に依存しない | マルチアーキテクチャ非対応 |
    | Last pull date | 最後に pull された日 | マルチアーキテクチャ対応。ECS pull で日付更新 | pull されないイメージは対象外（push date で補完） |
    | Push date | ECR に push された日 | シンプル。マルチアーキテクチャ対応 | push 日で固定。デプロイ頻度が低いと対象外になる |

  検討経緯:
    1. 当初 Last in use date を検討（AWS デフォルト、稼働中なら常にカバー）
    2. マルチアーキテクチャイメージ（production 17リポ）で Last in use date が
       非対応と判明（下記「マルチアーキテクチャイメージの問題」参照）
    3. 代理店（Megazone）に相談。Last pull date + push date 90日 を推奨される
       ・Last pull date: 直近 pull されたイメージをカバー（稼働中なら定期的に pull される）
       ・push date 90日: 過去に push されたイメージをカバー（段階的に縮小）
    4. Last in use date も再検討したが Last pull date を採用:
       ・Last in use date は稼働中なら常にカバーされる（AWS ドキュメント確認済み）
       ・ただしマルチアーキ（17リポ）は Last in use date 非対応 → push date 頼みになる
       ・Last pull date ならマルチアーキも pull で更新されるため全イメージをカバーできる
       ・AWS パッチデプロイによるタスク入れ替えで pull が発生し pull date が更新される
         （Fargate はキャッシュしないため、タスク入れ替え時に必ず pull が発生する）
    5. push date の期間:
       ・代理店の助言: 一度 inactive になったイメージは期間を戻しても
         再度 active にはならない（AWS ドキュメント明記）
         参照: https://docs.aws.amazon.com/inspector/latest/user/scanning_resources_configure_duration_setting_ecr.html
       ・ただし CONTINUOUS_SCAN のリポジトリでは pull で復旧可能（検証済み）:
         - develop の INACTIVE イメージ（fd-platform-test:node.18.16-alpine-1.0.0）を docker pull
         - pull 後に ACTIVE に復旧し、再スキャンも自動実行された
         - AWS ドキュメント: "You can push or pull the image to resume scanning."
           参照: https://docs.aws.amazon.com/inspector/latest/user/assessing-coverage.html
         - SCAN_ON_PUSH のリポジトリでは push のみで復旧（pull では不可）
       ・push date は最小値（3日）に設定（無効化は API 仕様上不可）
       ・Last pull date 60日で稼働中イメージは全てカバーされるため、
         push date による補完は不要と判断

  マルチアーキテクチャイメージの問題:
    ・production の71リポジトリ中17リポジトリがマルチアーキテクチャイメージ
      （全て online-agent-* 系、OCI Image Index 形式）

    マルチアーキテクチャイメージとは:
      ・1つのタグに複数 CPU アーキテクチャ（amd64, arm64等）の
        イメージを束ねたもの
      ・構造: 親（振り分け表）+ 子（実際のイメージ）
        - 親: タグ付き。「amd64 なら子A、arm64 なら子B を使え」という定義
        - 子: タグなし。ECS が実際に pull して実行するイメージ
      ・ECS Fargate は親の振り分け表を読み、自分の CPU に合った子だけを pull する

    Last in use date で問題が起きる理由:
      ・Last in use date は「ECS で使用中か」を追跡する
      ・しかし ECS が実際に使うのは子イメージ（タグなし）
      ・Inspector は親イメージ（タグ付き）を追跡しようとする
      ・親は直接使われないため Last in use date が更新されない
      → 稼働中でも14日で再スキャン対象外になる可能性がある

    ・AWS公式: "For multi-architecture images, the last-in-use date tracking
      is not supported. We recommend that you configure scanning based on
      image pull or push events instead."
      参照: https://docs.aws.amazon.com/inspector/latest/user/scanning_resources_configure_duration_setting_ecr.html

    マルチアーキテクチャイメージの一覧（production）:
      online-agent-user-insight, online-agent-prescription,
      online-agent-doctor-evaluator, online-agent-medical-quality,
      online-agent-patient-credential, online-agent-doctor-evaluation,
      online-agent-prescription-inquiry, online-agent-karte-check,
      online-agent-mental-operator-ui, online-agent-doctor-evaluation-support,
      online-agent-hello, online-agent-employee-interface,
      online-agent-appointment, online-agent-operator-interface,
      online-agent-post-consultation, online-agent-doctor-ui,
      online-agent-online-operator-ui

  Last pull date を選定した理由:
    ・マルチアーキテクチャイメージ（17リポ）を含めて全イメージをカバーできる
    ・ECS Fargate はキャッシュしないため、タスク入れ替え時に必ず pull が発生し
      pull date が更新される（AWS パッチデプロイによるタスク入れ替えも含む）
    ・Last in use date は稼働中なら常にカバーされるが、マルチアーキ非対応のため
      push date 頼みになる。Last pull date なら pull で更新されるため push date への
      依存度が低い
    ・代理店（Megazone）の推奨と一致

  ListCoverage 調査結果（2026-08-21時点）:
    ・production / fd-sys の全リージョン（Tokyo / Virginia）で確認
    ・稼働中イメージ（desiredCount > 0）で INACTIVE は 0 件
    ・production: 稼働中イメージの pulledAt は全て直近（2026-08-12〜15）
      → AWS パッチデプロイ等でタスク入れ替えが発生し pull が更新されている
    ・fd-sys Tokyo: ACTIVE 93個中 90個が pulledAt=null（fd-system 系5リポ）
      → 全て desiredCount=0（停止中）のため pull が発生していない
      → 現状の push date 90日で ACTIVE になっているだけ
    ・停止中サービスは再稼働時に pull で復旧する（検証済み）ため、
      push date でのカバーは不要

  re-scan duration 60日の根拠（Last pull date ベース）:
    ・AWS デフォルトは14日だが、AWS パッチデプロイによるタスク入れ替えの
      間隔が20日前後のため、14日だと pull date が更新される前に対象外になる可能性がある
    ・60日なら20日前後のパッチデプロイに対して十分な余裕がある
    ・Last pull date モードでは:
      - 稼働中のイメージ → ECS pull で日付更新 → 60日以内に pull があればカバー
      - 停止後のイメージ → 最後の pull から60日で対象外（実害なし、再稼働時に pull で復旧）
    ・運用しながら必要に応じて調整する（30日に短縮 or 90日に延長）

  push date duration:
    ・re-scan duration とは別に、push 日を起点とした監視期間もある
    ・選択肢: 14日 / 30日 / 60日 / 90日 / 180日 / Lifetime（無期限）
    ・3日に設定する（API 仕様上の最小値。無効化は不可）
      参照: https://docs.aws.amazon.com/inspector/v2/APIReference/API_EcrConfiguration.html
    ・Last pull date と push date のどちらかの条件を満たせば再スキャン対象（OR 条件）
    ・push date を最小化する理由:
      - Last pull date 60日で稼働中イメージは全てカバーされる
      - 停止中サービス（desiredCount=0）は脆弱性の実害がなく、
        再稼働時に pull されれば ACTIVE に復旧する（検証済み）
      - push date を大きくすると、Last pull date を短縮してもコスト削減効果が限定的
        （push date 期間内のイメージが再スキャン対象に残るため）
    ・カバレッジまとめ:
      | イメージ種別 | Last pull date 60日 | push date 3日 |
      |---|---|---|
      | 通常イメージ（54リポ、稼働中） | ✅ pull で更新 | — |
      | マルチアーキ（17リポ、稼働中） | ✅ pull で更新 | — |
      | 停止中（desiredCount=0） | ❌ pull されない | ❌ 3日超で対象外（実害なし、再稼働時に pull で復旧） |
      | 古いイメージ | — | 対象外 |

  参照: https://docs.aws.amazon.com/inspector/latest/user/scanning_resources_configure_duration_setting_ecr.html

設定方法:
  ・モードは Last pull date のまま維持（変更不要）
  ・pull date duration を 90日 → 60日に変更
  ・push date duration を 90日 → 3日に変更（最小値）

  aws inspector2 update-configuration \
    --ecr-configuration '{
      "rescanDuration": "DAYS_3",
      "pullDateRescanDuration": "DAYS_60",
      "pullDateRescanMode": "LAST_PULL_DATE"
    }' \
    --region ap-northeast-1

  ※ API パラメータの対応:
    - rescanDuration: push date duration の設定（必須）
    - pullDateRescanDuration: pull date duration の設定
    - pullDateRescanMode: モード選択（LAST_PULL_DATE / LAST_IN_USE_AT）
    参照: https://docs.aws.amazon.com/inspector/v2/APIReference/API_EcrConfiguration.html
  ※ Delegated Admin から全アカウントに一括適用（各リージョンで実施）
  ※ 組織統合前は各アカウントで個別に実行可能
  ※ 組織全体に適用される（develop / staging も同じ設定になるが、
    SCAN_ON_PUSH のアカウントでは re-scan duration は無関係）
  ※ 変更後に ListCoverage で稼働中イメージが意図せず INACTIVE になっていないか確認
  ※ re-scan duration を管理する Terraform リソースは存在しないため CLI で設定する

タイミング:
  ・Security Hub / Inspector 導入前に変更
  ・ECR ライフサイクルポリシーと合わせて実施

8. 脆弱性対応フロー

対応 SLA

既存のガイドライン（docs/sre/incident-response/vulnerability-assessment-guidelines.md）に
SLA が定義されているが、実運用では CVE ごとのリアクティブ対応になっている。
Inspector 導入により自動検知されるため、SLA を正式化して運用に組み込む。
    | 重要度 | 対応期限 |
    |--------|---------|
    | Critical | 24時間以内 |
    | High | 1週間以内 |
    | Medium | 1ヶ月以内 |
    | Low | 次回メンテナンス |

  ※ 上記はこのリポジトリの docs/sre/incident-response/ に定義済み
  ※ ただし実運用では CVE ごとに異なる期限を設定しており統一されていない
    （Axios CVE: 72時間、PostgreSQL: 4時間以内に対応開始、Node.js: 2週間等）
  ※ Inspector 導入を機に、既存ガイドラインの SLA を正式な運用ルールとして定着させる
  ※ 詳細な運用フロー・エスカレーションは Security Hub 運用設計で別途策定

対応フロー概要

  1. 検知: Inspector → Security Hub → 通知（詳細は Security Hub 設計書）
  2. トリアージ: 影響範囲・実環境での悪用可能性を評価
  3. 対応判断: パッチ適用 / ライブラリ更新 / ベースイメージ更新 / 許容（サプレッション）
  4. 実施: PR 作成 → レビュー → マージ → デプロイ
  5. 確認: Inspector 再スキャンで修正確認

  ※ GitHub Issue 起票は Security Hub のカスタムアクションで実施
  ※ 詳細なフローは運用設計で策定（Security Hub 運用設計 Issue 参照）

9. CI/CD 統合

※ Inspector 導入・安定稼働後に実装する（今後のタスク Section 13 参照）。
  まず Inspector の継続スキャンで findings の傾向を把握し、
  CI/CD でブロックする閾値（CRITICAL のみか、HIGH も含めるか等）を
  実データに基づいて決定してから導入する。

目的:
  ・本番にデプロイされる前に脆弱性を検知・ブロックする
  ・現状: ビルド → デプロイ → Inspector 検知 → 対応（脆弱性が本番に入る）
  ・目標: ビルド → スキャン → CRITICAL なら止める → 修正 → デプロイ（事前防止）

構成:
  GitHub Actions workflow:
    1. 開発者が PR を作成
    2. CI でコンテナイメージをビルド
    3. Inspector SBOM Generator でイメージ内のパッケージを一覧化（SBOM 生成）
    4. Inspector Scan API に SBOM を送信し CVE データベースと照合
    5. 結果に応じて制御:
       ・CRITICAL 検出 → ワークフロー失敗（マージ/デプロイブロック）
       ・HIGH 以下 → 警告表示してデプロイ続行
    6. PR にスキャン結果をコメントとして表示

  必要なもの:
    ・IAM ロール（GitHub Actions OIDC 連携）に inspector-scan:ScanSbom 権限
    ・Inspector SBOM Generator バイナリ（GitHub Actions で取得）
    ・Inspector をアカウントで有効化していなくても Scan API は単体で利用可能

期待する効果:
  ・脆弱性のあるイメージが本番にデプロイされるのを事前に防止
  ・開発者が PR の段階で脆弱性を認識できる
  ・「デプロイ後に気づいて緊急対応」がなくなる
  ・SBOM が自動生成され、ソフトウェア部品の可視化にもなる
  ・3省2ガイドラインが求める「脆弱性対応の管理」の予防的対策

  ※ CI/CD スキャンは「ビルド時点」のスキャン。デプロイ後に公開された
    新 CVE の検知は Inspector の継続スキャン（ECR Enhanced Scanning）が担当する。
    CI/CD（事前）+ 継続スキャン（事後）の両輪で脆弱性をカバーする。

参照:
  ・GitHub Actions プラグイン: https://docs.aws.amazon.com/inspector/latest/user/cicd-inspector-github-actions.html
  ・Scan API: https://docs.aws.amazon.com/inspector/latest/user/scanning-cicd.html

10. Code Security（今後の検討項目）

※ Inspector 導入・安定稼働後に検討する（今後のタスク Section 13 参照）。
  まず手動で1回実行して検出結果を確認し、定期実行の頻度やコストを判断する。

概要:
  ソースコードリポジトリ（GitHub等）を直接スキャンして脆弱性を検出する機能。
  ECR/Lambda/EC2 スキャンがデプロイ済みリソースをスキャンするのに対し、
  Code Security はデプロイ前のソースコードをスキャンする。

3つのスキャンタイプ:
  ① SAST（Static Application Security Testing）:
     ・自社コードの脆弱性を静的解析で検出
     ・例: SQLインジェクション、XSS、ハードコードされた認証情報、弱い暗号化
     ・対応言語: TypeScript, JavaScript, Python, Java, Go, Ruby, C#, Kotlin 等
     ・ECR/Lambda スキャンではカバーできない（コードの中身は見ない）

  ② SCA（Software Composition Analysis）:
     ・サードパーティライブラリの既知 CVE を検出
     ・Dependabot や ECR スキャンと一部重複する

  ③ IaC（Infrastructure as Code）スキャン:
     ・Terraform, CloudFormation, CDK のセキュリティチェック
     ・例: S3パブリック公開設定、SG全開放、暗号化なし
     ・Security Hub FSBP はデプロイ済みリソースをチェックするが、
       IaC スキャンはデプロイ前のコード段階で検知できる

ECR/Lambda スキャンとの違い:
  | 検知対象 | Code Security | ECR/Lambda スキャン |
  |---------|--------------|-------------------|
  | 自社コードの脆弱性（SAST） | ✅ | ❌ |
  | ライブラリの既知 CVE | ✅（SCA） | ✅ |
  | IaC の設定不備 | ✅ | ❌ |
  | OS パッケージの CVE | ❌ | ✅ |
  | ベースイメージの CVE | ❌ | ✅ |

スキャン実行方法:
  ・オンデマンド（手動）: 任意のタイミングで手動実行
  ・定期スキャン: 週次/日次で自動実行
  ・変更ベース: PR/MR 作成時に自動スキャン

対応リポジトリ:
  ・GitHub SaaS / GitHub Enterprise Cloud / GitLab Self Managed

注意:
  ・findings は Security Hub には送信されない
    （Inspector コンソールと API でのみ参照可能）

料金:
  ・$0.15/スキャン（スキャンタイプごと）
  ・10MB 超のリポジトリは 10MB 単位で複数カウント
  ・従量課金（最小料金なし）

コスト試算:
  主要リポジトリのサイズ:
    ・terraform_for_aws: 16MB → 2リポ分
    ・mental-online-karte: 360MB → 36リポ分（モノレポ）

  手動1回実行:
    ・terraform_for_aws: 2 × 3タイプ × $0.15 = $0.90
    ・mental-online-karte: 36 × 3タイプ × $0.15 = $16.20
    ・合計: $17.10/回

  定期スキャン（週1回）:
    ・terraform_for_aws: 2 × 4回 × 3タイプ × $0.15 = $3.60/月
    ・mental-online-karte: 36 × 4回 × 3タイプ × $0.15 = $64.80/月
    ・合計: $68.40/月

  PR スキャン有効化時（mental-online-karte で月100PR の場合）:
    ・36 × 100 × 3 × $0.15 = $1,620/月 ⚠️ コスト注意

課題:
  ・モノレポ（mental-online-karte 360MB）が36リポ分としてカウントされ
    PR スキャンを有効にするとコストが跳ね上がる
  ・findings が Security Hub に送信されないため、通知基盤が別途必要
  ・Dependabot（SCA）、Security Hub FSBP（IaC の一部）と重複する領域がある

方針:
  ・Inspector 導入後にまず手動で1回実行し検出結果を確認する（$17程度）
  ・結果を見て定期実行の頻度（週次/月次）や対象リポジトリを判断
  ・PR スキャンはコスト影響が大きいため慎重に検討

参照: https://docs.aws.amazon.com/inspector/latest/user/code-security-assessments.html

11. コスト

料金体系:
  ・ECR: push 時スキャン + 再スキャン回数で課金
  ・Lambda: カバーされた関数数の月平均で課金
  ・EC2: カバーされたインスタンス数の月平均で課金
  ・詳細は AWS 公式料金ページを参照: https://aws.amazon.com/inspector/pricing/

現在のコスト実績（2026年7月、Cost Explorer 全リージョン合算）:
  | アカウント | ECR再スキャン | ECR push時 | EC2 | Lambda | 合計 |
  |-----------|-------------|--------|------|--------|---------|
  | staging | $185.42 | $123.50 | $13.07 | $3.20 | $325.19 |
  | production | $44.45 | $18.07 | $10.99 | $4.41 | $77.92 |
  | fd-sys | $15.66 | $5.45 | $12.21 | $23.47 | $56.79 |
  | infra-dev | $0.20 | - | $5.71 | - | $5.91 |
  | develop | $0.03 | - | $2.59 | $0.84 | $3.46 |
  | 合計 | $245.76 | $147.02 | $44.57 | $31.92 | $469.27 |

  ※ ECR再スキャン = container-image-re-scan（CONTINUOUS_SCAN による新 CVE 検知時の自動再スキャン、$0.01/回）
  ※ ECR push時 = container-image-initial-scan（push ごとに発生するスキャン、$0.11/イメージ）
  ※ 初回スキャンはデプロイ頻度に比例して継続発生する

  コスト分析:
    ・staging が最大コスト（$325/月）
      ECR 再スキャン $185.42 + push 時 $123.50 = $308.92
      イメージ数 2,748（全アカウント最多）が直接影響
    ・production: ECR 再スキャン（$44.45）
    ・fd-sys: Lambda（$23.47）
      165個中ほとんどが90日超未更新だが、Amazon Connect のコールフローで
      実行されている関数は課金対象になっている可能性あり。導入後に確認
    ・fd-sys: ECR Virginia（再スキャン $6.80 + 初回 $2.70）
      fd-system の Virginia リポジトリ分
  コスト試算（事前最適化後）:
    現状: $469/月
    ↓ ライフサイクルポリシー（20個保持）+ SCAN_ON_PUSH
      + Last pull date 60日 + push date 3日 適用後

    各施策のコスト影響:
      | 施策 | ECR 再スキャン | ECR push 時スキャン | ECR ストレージ | 対象アカウント |
      |------|-------------|-----------------|-------------|------------|
      | SCAN_ON_PUSH | → $0 | 変わらない | 変わらない | staging / infra-dev / develop |
      | Last pull date 60日 + push date 3日 | 削減 | 変わらない | 変わらない | production / fd-sys |
      | ライフサイクルポリシー | 削減（対象イメージ減） | 変わらない※ | 削減 | 全アカウント |

      ※ push 時スキャンはデプロイ頻度に依存。ライフサイクルは古いイメージを削除するだけで
        新規 push のスキャンには影響しない

    staging の試算:
      ・SCAN_ON_PUSH に変更 → 再スキャン $185.42 → $0
      ・push 時スキャンはデプロイ頻度に応じて継続発生（$123.50 は月による変動あり）
      ・ライフサイクルポリシーでストレージコスト削減
      ・EC2 / Lambda: 変わらない（$16.27）

    production の試算:
      ・CONTINUOUS_SCAN のまま（本番は再スキャン必要）
      ・ECR イメージ総数: 1,586 → 約700（ライフサイクルで56%削減）
      ・再スキャン対象:
        - Last pull date 60日: 直近60日以内に pull された稼働中の約30イメージ
        - push date 3日: 直近3日以内に push されたイメージのみ（実質的に push 直後のみ）
        - OR 条件のため、両方を合わせた数が対象
      ・ECR 再スキャン: $44.45 → 削減（対象イメージ数に比例）
        現状 1,586個 → ライフサイクル後 約700個 + re-scan duration で更に絞られる
      ・ECR push 時スキャン: デプロイ頻度依存（変わらない）
      ・ライフサイクルポリシーでストレージコスト削減
      ・EC2 / Lambda: 変わらない（$15.40）

    全アカウント推計:
      ・staging / infra-dev / develop → SCAN_ON_PUSH で再スキャンコスト $0
      ・production / fd-sys → ライフサイクルでイメージ削減 + re-scan duration で対象絞り込み
      ・全アカウント → ライフサイクルポリシーでストレージコスト削減
      ・ECR 再スキャン（現在 $246/月）→ 削減
        - staging / infra-dev / develop 分 $185.65 → $0（SCAN_ON_PUSH）
        - production / fd-sys 分 $60.11 → イメージ削減に比例して削減
      ・ECR push 時スキャン（現在 $147/月）→ デプロイ頻度依存（変わらない）
      ・ECR ストレージ → 63%削減（6,492 → 2,401 イメージ）
      ・EC2 / Lambda コスト（現在 $77/月）→ 変わらない

無料トライアル:
  ・Inspector の15日無料トライアルは有効化時に1回のみ
  ・既に有効化済みのアカウント（production, fd-sys 等）→ 消化済み ❌
  ・未導入アカウント（ctop-staging, ctop-production, cc-poc, hospital-ai-prod）
    → 初回有効化時に15日無料 ✅
  ・Security Hub Essentials と Inspector のトライアル・課金の関係は
    Security Hub Cost Estimator で確認する
  ・有効化済みアカウントのトライアル状況（確認済み）:
    production: 2024-06-13〜2024-06-28 で全スキャンタイプの15日トライアル消化済み
    他の有効化済みアカウントも同時期に消化済みと推測

コスト最適化の事前対応:
  ① ECR ライフサイクルポリシー設定（Section 6）
    ・6,492 → 2,401 イメージに削減 → ストレージコスト削減 + 再スキャン対象減
  ② ECR Registry Scanning Configuration 変更（Section 3）
    ・staging / infra-dev / develop を SCAN_ON_PUSH → 再スキャンコスト $0
  ③ re-scan duration を Last pull date 60日 + push date 3日に変更（Section 7）
    ・production / fd-sys の再スキャン対象を直近60日 pull のイメージに限定
    ・push date は最小値（3日）でコスト最適化

コスト監視:
  ・導入後1週間は Cost Explorer で手動確認
  ・Inspector Usage コンソールでスキャンタイプ別のコスト確認
  ・Security Hub Usage Page の Capability view で Inspector コスト内訳を確認

12. 適用手順

概要

Phase A: 事前準備（ECR ライフサイクルポリシー + Registry Scanning Config + re-scan duration）— 完了
Phase B: Inspector 組織統合（V2 ポリシー + Delegated Admin）— 完了
Phase C: 動作確認・安定化 — 進行中

詳細手順

Phase A: 事前準備（完了）

  Step 1: ECR ライフサイクルポリシーの設定（完了）
    → 全アカウント・全リポジトリに統一ポリシーを適用（PR #2667, #2684）
    → ポリシー: imageCountMoreThan 20（tagStatus: any）

  Step 2: ECR Registry Scanning Configuration の変更（完了）
    → staging / infra-dev / develop を CONTINUOUS_SCAN → SCAN_ON_PUSH に変更（PR #2685）
    → production / fd-sys は CONTINUOUS_SCAN のまま維持

  Step 3: re-scan duration の設定（完了）
    → 各アカウントで個別に CLI 実行（production / fd-sys / infra-dev）
    → 設定値: Last pull date 60日 + push date 3日（Section 7 参照）
    → Delegated Admin 登録後に一括再設定済み

Phase B: Inspector 組織統合（完了）

  ※ Security Hub V2 Configuration catalog で「Security Hub (必須機能とその他の機能)」を
    適用した際に、Inspector ポリシー（Organizations ポリシー）が自動作成された
  ※ Inspector ポリシーはスキャンの有効/無効を制御し、全アカウントに適用される
  ※ スキャン設定は Delegated Admin で管理する

  Step 4: マネジメントアカウントで Delegated Admin 登録（完了）
    → CLI で4リージョン（Tokyo / Virginia / Oregon / Osaka）に登録
    → fd-security-tooling (860801568046)
    aws inspector2 enable-delegated-admin-account \
      --delegated-admin-account-id 860801568046 \
      --region ap-northeast-1

  Step 5: 自動有効化設定（完了）
    → common/security-tooling/inspector.tf で aws_inspector2_organization_configuration を apply
    → V2 ポリシーがスキャンの on/off を優先、Terraform はメンバー関連付けと設定管理
    → メンバーアカウントは自動的に Delegated Admin に関連付けされる（伝播に時間がかかる）

  Step 6: re-scan duration の一括設定（完了）
    → Delegated Admin（fd-security-tooling）から全アカウントに一括適用
    → 設定値: Last pull date 60日 + push date 3日
    → 全メンバーアカウントに上書き適用される

  Step 7: 既存 Terraform モジュールの移行（完了）
    → 既存の aws_inspector2_enabler を terraform state rm で管理から外す
    → 各アカウントの Terraform からモジュール呼び出しを削除（PR #2712, #2714）
    → V2 ポリシー + Delegated Admin で一括管理に移行

Phase C: 動作確認・安定化（進行中）

  Step 8: メンバーアカウントの関連付け確認（進行中）
    → Delegated Admin にメンバーアカウントが全て関連付けされたか確認
    → 自動伝播のため時間がかかる
    aws inspector2 list-members --region ap-northeast-1 --profile fd-security-read

  Step 9: findings とコストを確認
    → findings の量・傾向を把握
    → Cost Explorer で re-scan duration 変更後のコスト削減効果を確認
    → Security Hub Usage Page の Capability view でも確認

  Step 10: 初期 findings のトリアージ
    → CRITICAL / HIGH の findings を優先的に確認
    → 対応が必要なものを GitHub Issue に起票
    → 既知の許容事項があればサプレッション検討

  Step 11: Code Security の手動実行（Section 10 参照）
    → GitHub 連携を設定し、主要リポジトリで手動1回スキャンを実行
    → 検出結果とコストを確認し、定期実行の必要性・頻度を判断

13. 今後のタスク

優先度	タスク	概要	時期
高	ECR Registry Scanning Config 変更	staging / infra-dev / develop を CONTINUOUS_SCAN → SCAN_ON_PUSH に変更。staging が ECR コスト最大要因（$325/月）。Terraform の aws_ecr_registry_scanning_configuration で設定。production / fd-sys は CONTINUOUS_SCAN のまま維持	Phase A（ECR ライフサイクルポリシー適用後）
高	初期 findings のトリアージ	CRITICAL/HIGH 脆弱性の対応	Inspector 導入直後
高	脆弱性対応フローの運用定着	SLA に沿った対応の実践・改善	導入後1ヶ月
中	Code Security の検討	GitHub 連携でソースコード・IaC の脆弱性を直接スキャン（SAST/SCA/IaC）。ECR/Lambda スキャンではカバーできない自社コードの脆弱性・Terraform の設定不備を検知できる。まず手動で1回実行して検出結果を確認し、定期実行の頻度（週次/月次）やコストを見て判断。10MB超のリポは10MB単位で複数カウントされるため monoリポ（mental-online-karte 360MB=36リポ分）はコスト注意	導入後に手動実行
中	CI/CD 統合	GitHub Actions + Inspector Scan API でビルド時スキャン	導入安定後
中	Lambda Code Scanning の検討	Standard Scanning の傾向を見てアドオン導入を判断	導入後3ヶ月
中	ECR ベースイメージ標準化	脆弱性の少ないベースイメージを選定・統一	脆弱性傾向把握後
中	Lambda 棚卸し	fd-sys の Lambda $23.20/月が最大。165個中ほとんどが未更新だが Amazon Connect コールフローで実行中のため課金対象。Usage コンソールで実際のスキャン対象を確認し、不要な関数があれば削除を検討	導入後にコスト確認
中	Suppression Rules の設計	既知の許容事項・誤検知の自動サプレッション	運用しながら
中	Dependabot 設定見直し	メジャーバージョン更新PRの生成を検討	運用しながら
中	リソース除外タグの検討	EC2（InspectorEc2Exclusion）/ Lambda（InspectorExclusion）タグでスキャン不要なリソースを除外しコスト削減。除外対象は導入後に判断	導入後にコスト確認
低	EC2 VPC エンドポイントの確認	プライベートサブネットの EC2 で inspector2-telemetry エンドポイントが必要か確認。SSM 系は既存の可能性あり。Fargate 中心で EC2 コストは $8/月程度のため優先度低	導入後に確認
低	SBOM の導入検討	ソフトウェア部品表の生成・管理	運用安定後
低	CIS Scanning の検討	EC2 の CIS ベンチマークチェック	必要に応じて
低	AWS Security Agent の検討	AI による自動ペネトレーションテスト、脅威モデリング、設計レビュー。Code Security がルールベースの自動チェックに対し、Security Agent は AI が文脈を理解して攻撃者視点で分析する。リリース前の深い分析に有用。現在プレビュー（無料）。Security Hub 設計書の今後のタスクにも記載	プレビュー期間中

Inspector 組織統合設計書 ​

1. 目的・スコープ ​

目的 ​

スコープ ​

スコープ外 ​

前提 ​

2. 現状と課題 ​

現状（2026-08-27時点） ​

リソース数の調査結果（2026-08-07時点） ​

課題 ​

3. アーキテクチャ ​

Security Hub Essentials との関係 ​

スキャンの仕組み ​

4. Delegated Admin ​

5. スキャンタイプの選定 ​

6. ECR ライフサイクルポリシー ​

方針 ​

ポリシー設計 ​

7. re-scan duration の最適化 ​

8. 脆弱性対応フロー ​

対応 SLA ​

対応フロー概要 ​

9. CI/CD 統合 ​

10. Code Security（今後の検討項目） ​

11. コスト ​

12. 適用手順 ​

概要 ​

詳細手順 ​

13. 今後のタスク ​

参考ドキュメント ​

Inspector 組織統合設計書

1. 目的・スコープ

目的

スコープ

スコープ外

前提

2. 現状と課題

現状（2026-08-27時点）

リソース数の調査結果（2026-08-07時点）

課題

3. アーキテクチャ

Security Hub Essentials との関係

スキャンの仕組み

4. Delegated Admin

5. スキャンタイプの選定

6. ECR ライフサイクルポリシー

方針

ポリシー設計

7. re-scan duration の最適化

8. 脆弱性対応フロー

対応 SLA

対応フロー概要

9. CI/CD 統合

10. Code Security（今後の検討項目）

11. コスト

12. 適用手順

概要

詳細手順

13. 今後のタスク

参考ドキュメント