既存システムを安全に保つには、稼働中のリソースに新たに発見された脆弱性を継続的に検出する仕組みが不可欠です。本記事ではAmazon Inspectorを解説します。

SAA レベル：基礎概念

Inspectorのスキャン対象

対象	スキャン内容
EC2インスタンス	OS・ミドルウェアのソフトウェア脆弱性、意図しないネットワーク到達性
ECR上のコンテナイメージ	イメージ内の既知の脆弱性（CVE）
Lambda関数	関数コード・依存パッケージの脆弱性

SAA 試験のポイント

Inspectorは継続的スキャンを行うマネージドサービスです。新しいCVE（共通脆弱性識別子）が公開されると、過去にスキャン済みのリソースも自動的に再評価され、新たに該当する脆弱性があれば検出されます。一度きりのスキャンではない、という点がSAAで問われます。

SAP レベル：高度な設計シナリオ

CVEベースの優先度付け

SAP 試験のポイント

Inspectorが検出する脆弱性には、CVSS（共通脆弱性評価システム）スコアに基づいた重要度（Critical、High、Medium、Low）が付与されます。しかし、単純にCVSSスコアだけで対応順位を決めるのではなく、SAPレベルでは**「そのリソースが実際にインターネットに到達可能か」というネットワーク到達性の評価と組み合わせた優先度付け**が推奨されます。同じCriticalな脆弱性でも、プライベートサブネット内でインターネットから到達不可能なリソースより、パブリックに公開されたリソースの方が実際のリスクは高いためです。

優先度 = CVSSスコア（脆弱性自体の深刻度） × ネットワーク到達性（実際の悪用可能性）
   最優先: Critical + インターネットから到達可能
   次点: Critical + プライベートのみ

CI/CDパイプラインへの統合

SAP 試験のポイント

本番環境にデプロイされてから脆弱性を検出するのでは、修正までの対応コストが大きくなります。SAPレベルでは、ECRへのイメージプッシュ時点でInspectorスキャンを実行し、Critical/High脆弱性が検出された場合はCI/CDパイプラインを失敗させてデプロイをブロックする、シフトレフト（開発の早い段階でのセキュリティ検証）の設計が問われます。

設計上の落とし穴

「本番環境だけスキャンすれば十分」という判断は、脆弱性のあるイメージが繰り返しビルド・デプロイされ続けるリスクを見逃します。SAPでは、開発パイプラインの早い段階（ビルド時）でのスキャンと、本番稼働中の継続的スキャンの両方を組み合わせる多段階の検証設計が問われます。

Security Hubとの統合による一元管理

Inspectorの検出結果はSecurity Hubに自動的に集約され、GuardDutyやConfigの検出結果と合わせて統合的に確認できる
組織全体（委任管理者アカウント経由）で、どのアカウント・どのリソースに未対応の脆弱性が残っているかを一元的にダッシュボードで可視化できる

修復の自動化

検出結果をEventBridge経由でSystems Manager Automationと連携させ、特定の条件（Critical脆弱性かつパッチが利用可能）を満たす場合は自動的にパッチ適用を実行する、という自動修復パイプラインもSAPレベルの設計として問われることがある

まとめ

SAA: Inspectorが継続的にEC2/ECR/Lambdaの脆弱性をスキャンするサービスであることを理解する。
SAP: ネットワーク到達性を加味した優先度付け、CI/CDパイプラインへのシフトレフト統合、Security Hubとの一元管理・自動修復ができる。

次は **コンプライアンス対応（Audit Manager、Artifact）**を見ていきましょう。