AWS Inspector: Continuous Vulnerability Management for EC2 and Containers

From Point-in-Time Scanning to Continuous Assessment

Traditional vulnerability management involves periodic scans: run a scanner against your infrastructure monthly, review the report, prioritize findings, patch the most critical ones, repeat next month. This approach has a fundamental problem: in cloud environments, your infrastructure changes daily. New EC2 instances launch, container images are deployed, Lambda functions are updated. A monthly scan misses the vulnerabilities introduced between scans.

Amazon Inspector v2 takes a different approach. It continuously monitors your EC2 instances, ECR container images, and Lambda functions for vulnerabilities — evaluating against the NVD database automatically when new CVEs are published, not just when you run a scan. When a new critical vulnerability is disclosed, Inspector flags your affected resources within hours, not at your next scheduled scan.

Inspector v2 vs. Inspector Classic

Amazon Inspector had a major redesign. Inspector v2 (launched 2021) differs from Inspector Classic in important ways:

• Continuous monitoring vs. scheduled assessments
• No assessment targets or templates to configure — just enable and Inspector discovers resources automatically
• Native ECR integration for container image scanning
• Lambda function scanning for package vulnerabilities and code security
• Integration with Security Hub for centralized findings
• Risk scoring that combines CVE severity with exploit availability and network reachability

If you're using Inspector Classic, migration to v2 is strongly recommended.

Enabling Inspector v2

aws inspector2 enable   --resource-types EC2 LAMBDA ECR

For multi-account deployments, delegate Inspector administration to your security account and enable across the organization:

aws inspector2 enable-delegated-admin-account   --delegated-admin-account-id 123456789012

Inspector requires SSM Agent on EC2 instances for deep vulnerability analysis. The SSM Agent collects the software inventory that Inspector uses to match against CVE databases. Ensure SSM Agent is deployed and managed via Systems Manager. See our EC2 patch management guide for SSM configuration.

Understanding Inspector Risk Scores

Inspector calculates a risk score for each finding using multiple factors:

• CVSS score: Base severity from the NVD database
• Exploit availability: Is there a known exploit in the wild? (CISA KEV database)
• Network reachability: Is the vulnerable component network-accessible?
• Package fix available: Does a patched version exist?

A CVE with CVSS 7.5 becomes much more urgent when there's a known exploit and the affected EC2 instance is accessible from the internet. Inspector's risk scoring surfaces these high-priority findings at the top of your remediation queue.

EC2 Vulnerability Findings

For EC2 instances, Inspector identifies:

• CVEs in installed packages (OS packages, application packages)
• Packages with known exploits
• Network exposure (open ports accessible from the internet)

Filter findings by risk score and network reachability to prioritize remediations. A critical CVE in a package on an instance that's only accessible from within a private subnet is lower priority than the same CVE on a publicly accessible instance. See our security groups audit guide for reducing network exposure.

Container Image Scanning with ECR Integration

Inspector integrates directly with Amazon ECR to scan container images both on push (scanning new images as they're pushed) and continuously (re-evaluating existing images when new CVEs are published). Enable enhanced scanning in ECR:

aws ecr put-registry-scanning-configuration   --scan-type ENHANCED   --rules '[{
    "repositoryFilters": [{"filter": "*", "filterType": "WILDCARD"}],
    "scanFrequency": "CONTINUOUS_SCAN"
  }]'

Container image findings appear in both ECR and Inspector, with Security Hub aggregation. For a complete container security strategy, see our guide on ECR security and EKS security.

Lambda Function Vulnerability Scanning

Inspector v2 scans Lambda function packages for vulnerabilities in third-party libraries. This is particularly valuable because Lambda functions are often overlooked in traditional vulnerability programs — they're serverless, they don't have OS packages to patch, but they do have application dependencies.

Inspector scans Lambda function deployment packages and layers, identifying CVEs in bundled libraries (boto3, requests, fastapi, and similar). Findings include the specific package and version, the CVE, and the fix version — directly actionable for development teams. See our Lambda security guide for the full Lambda security context.

Prioritizing and Remediating Findings

Inspector typically surfaces a large number of findings when first enabled. A practical prioritization approach:

Phase 1: Critical with Active Exploits

Filter for: Critical/High severity + exploit available in CISA KEV. These are the most likely attack vectors. Patch within 24-48 hours.

Phase 2: Network-Reachable High Severity

Critical/High severity on network-accessible resources. Reduce network exposure through security group tightening while preparing patches.

Phase 3: Standard Critical/High

Remaining critical/high findings. 7-day remediation SLA.

Phase 4: Medium and Low

Batch-process medium findings monthly. Low findings quarterly.

Inspector and AWS Systems Manager Patch Manager

Inspector identifies vulnerabilities; Systems Manager Patch Manager remediates them on EC2 instances. The workflow:

1. Inspector finds CVE in a package on multiple EC2 instances
2. Inspector finding triggers EventBridge rule
3. Lambda creates a Patch Manager patch group and schedules patching for affected instances
4. Patch Manager runs patching during the next maintenance window
5. Inspector re-evaluates and closes the finding once the package is updated

This automation loop eliminates the manual "identify → create ticket → schedule → patch → verify" workflow for common OS package vulnerabilities.

Finding Integration with Security Hub

Inspector publishes findings to Security Hub automatically. Configure EventBridge rules for high-severity findings:

aws events put-rule   --name "inspector-critical"   --event-pattern '{
    "source": ["aws.inspector2"],
    "detail-type": ["Inspector2 Finding"],
    "detail": {
      "severity": ["CRITICAL"],
      "status": ["ACTIVE"]
    }
  }'

For Security Hub automation patterns, see our Security Hub automations guide.

Suppressing False Positives

Inspector sometimes flags packages that aren't actually exploitable in your environment — for example, a CVE in a feature you don't use, or a vulnerability in a package that's present but not installed in an accessible path. Create suppression rules for known false positives:

aws inspector2 create-filter   --name "SuppressKnownFalsePositive"   --action SUPPRESS   --filter-criteria '{
    "cveId": [{"comparison": "EQUALS", "value": "CVE-2023-XXXXX"}],
    "ecrImageRepositoryName": [{"comparison": "EQUALS", "value": "internal-base-image"}]
  }'

FAQ

Does Inspector replace dedicated vulnerability scanners like Qualys or Rapid7?

For AWS-native workloads, Inspector provides comparable coverage at lower cost and with better integration. For hybrid environments (on-premises + AWS) or for organizations that need specific compliance scanning profiles (PCI ASV scans, for example), dedicated scanners may still be needed. Inspector and third-party scanners can run simultaneously for defense in depth.

How do I reduce Inspector costs in large environments?

Inspector charges per instance-hour for EC2 and per image digest for ECR. For cost optimization: scope EC2 scanning to production and staging (exclude dev/sandbox), configure ECR to scan only production repositories continuously and dev repositories on-push, and use tag-based scoping to exclude non-critical resources.

What's the typical finding count when first enabling Inspector?

Highly variable — environments with older AMIs or base images with unpatched OS packages can have thousands of findings. Don't be alarmed by the initial volume. Use the risk scoring and prioritization approach above to focus on what matters, and reduce the baseline over time as patches are applied.