Amazon Inspector

Amazon Inspector is a vulnerability management service that automatically discovers and scans workloads for software vulnerabilities and unintended network exposure.

What It Scans

• EC2 Instances: OS packages (using SSM Agent) and network reachability
• ECR Container Images: OS packages and programming language packages in container images
• Lambda Functions: code dependencies and packages

Key Features

• Continuous Scanning: automatically re-scans when new CVEs are published or when workloads change
• Risk-based Prioritization: Inspector score combines CVSS with environmental factors (network exposure, exploit availability)
• SBOM Export: generate Software Bill of Materials for compliance
• Integration: findings go to Security Hub, EventBridge, and S3 for centralized management
• CIS Benchmarks: assess EC2 instances against CIS hardening standards

How EC2 Scanning Works Under the Hood

For EC2, Inspector has two collection methods, and understanding them explains most coverage surprises. Agent-based scanning uses the SSM Agent: Inspector creates SSM associations in your account that extract package inventory from managed instances, and re-scans continuously when new software is installed or when a relevant CVE lands in its database. Agentless scanning covers instances that SSM does not manage: Inspector snapshots the attached EBS volumes, reads them through EBS direct APIs, evaluates the inventory, then deletes the snapshots it created (tagged with an InspectorScan key while they exist). In hybrid mode, the default when you first activate EC2 scanning, agent-based is used where the SSM Agent is present and agentless fills the gaps every 24 hours; agentless eligibility requires EBS-backed instances with ext3, ext4, or xfs filesystems, fewer than 8 volumes, and at most 1200 GB combined. Network reachability scans run every 12 hours regardless. Instances can be excluded with the InspectorEc2Exclusion tag, and excluded instances are not charged.

How It Goes Wrong in Practice

The classic operational failure is phantom coverage. A team activates Inspector, sees findings flowing, and assumes the estate is covered. But agent-based scanning only sees instances that are SSM-managed: instances missing the instance profile with SSM permissions, or with a stopped agent, silently drop out unless agentless mode catches them, and agentless itself has eligibility limits (filesystem, volume count and size). The result is that the least-maintained instances, exactly the ones most likely to carry old vulnerable packages, are the ones most likely to be invisible. Audit coverage explicitly rather than inferring it from the findings feed; the coverage view exists precisely because "no findings" and "not scanned" look identical on a dashboard.

The second failure is finding fatigue: thousands of CVE findings, no triage rule, so nothing gets fixed. Filter to what is actually reachable and exploitable first (critical and high severity on internet-exposed workloads), wire those into ticketing via EventBridge, and fix by rebuilding images and AMIs rather than patching one instance at a time.

Practical Check: List Active Critical Findings

Pull the findings that should top the queue:

aws inspector2 list-findings --filter-criteria '{"severity":[{"comparison":"EQUALS","value":"CRITICAL"}],"findingStatus":[{"comparison":"EQUALS","value":"ACTIVE"}]}'

The --filter-criteria structure supports comparisons like EQUALS, NOT_EQUALS, and PREFIX; severity values are INFORMATIONAL, LOW, MEDIUM, HIGH, CRITICAL, and UNTRIAGED, and finding status can be ACTIVE, SUPPRESSED, or CLOSED. Add --sort-criteria 'field=SEVERITY,sortOrder=DESC' to rank output, and use the coverage APIs to verify which resources are actually being scanned.

Frequently Asked Questions

Does Inspector need an agent on every EC2 instance?

No. Agent-based scanning rides on the SSM Agent (no separate Inspector agent to install), and agentless scanning covers eligible EBS-backed instances that SSM does not manage by analyzing snapshots. Hybrid mode combines both automatically.

What is the difference between Inspector and GuardDuty?

Inspector finds weaknesses before an attacker does: vulnerable packages and unintended network reachability. GuardDuty detects active threats: anomalous API calls, malware, cryptomining. They are complementary; most environments should run both, with findings aggregated in Security Hub.

How fresh are the scans?

Agent-based EC2 scans re-run when instances launch, when software changes, and when new relevant CVEs are added to Inspector's database, with SSM inventory evaluated every 30 minutes by default. Agentless scans of eligible instances run every 24 hours, with newly eligible instances detected hourly, and network reachability analysis runs every 12 hours. The practical consequence: a freshly disclosed CVE shows up against agent-managed instances much faster than against agentless-only ones, one more reason to keep the SSM Agent healthy on everything that matters.