Amazon Inspector: coverage, finding lifecycle, and severity scoring
Amazon Inspector scans EC2 instances, ECR container images, Lambda functions, and application code for vulnerabilities. One thing to know upfront: it only generates findings when a fix exists.
Inspector doesn't surface every CVE in your environment, just the remediable ones. Your finding count isn't a complete exposure picture.
What Inspector scans
Inspector covers EC2 instances (running and stopped), ECR container images, Lambda functions, and application code. For EC2 that means package-level CVEs. ECR images get scanned on push and re-evaluated as new CVE data arrives. Lambda scanning covers function code and package dependencies. The code security category adds first-party source, third-party dependencies, and IaC templates.
The IaC scanning tends to get overlooked. Inspector can flag misconfigurations in templates before they reach deployed resources, earlier than runtime scanning catches them.
EC2 teams often miss this: findings for stopped instances stay active. An instance you stopped three months ago still shows up in your active count. You have to terminate it to close the findings; stopping doesn't do it.
Finding lifecycle
Findings have three states: Active, Suppressed, and Closed.
Fix the vulnerability and the finding goes to Closed. Apply a suppression rule and it goes to Suppressed, still in the system but excluded from active counts and alerts.
Retention after state changes:
| State change | Deletion timeline |
|---|---|
| Remediated (Closed) | 30 days |
| Resource deleted, terminated, or ineligible | 3 days |
| Inspector disabled | 24 hours |
| AWS account suspended | 90 days |
The 24-hour window on disable is the one to watch. Disabling Inspector, even temporarily, takes the finding history with it. Export to Security Hub or S3 first if the data matters downstream.
If a remediated finding reappears within seven days of being closed, Inspector reopens the original rather than creating a new one. This matters for patch rollbacks, base images rebuilt from unpatched sources, or dependencies repinned to a vulnerable version. After seven days, it's a new finding.
Suppression vs. remediation
Suppression is for findings you've accepted as risk, are handling elsewhere, or have determined aren't exploitable in your environment. The finding stays in the system as Suppressed rather than going to Closed; it's still reportable, just separated from active counts.
This matters for compliance reporting. Suppressed means acknowledged; Closed means addressed. Conflating the two distorts remediation velocity metrics.
Severity and scoring
Inspector doesn't just report the CVSS base score; it adjusts it based on your environment. For EC2, that means network reachability. A critical CVE on an instance with no internet exposure scores differently than the same CVE on a public host.
CVSS scores are static and environment-agnostic. Inspector's scores reflect whether a vulnerability is actually reachable given your network configuration at the time of evaluation. That's the difference.
Multi-account operation
With AWS Organizations, you designate one account as the delegated administrator. It aggregates findings from all member accounts, each tagged with its originating account ID. From there you can enable or disable scanning for members, set suppression rules, and check coverage gaps.
Coverage gaps are where Inspector is enabled but scanning isn't happening, distinct from accounts where Inspector isn't enabled at all.
Example finding
Here's what a critical CVE finding looks like from the ListFindings API:
{
"awsAccountId": "123456789012",
"description": "A critical vulnerability CVE-2021-44228 (Log4Shell) was found in log4j-core version 2.14.1 installed on the instance.",
"findingArn": "arn:aws:inspector2:eu-west-1:123456789012:finding/abc123def456abc123def456abc123de",
"firstObservedAt": "2026-05-18T09:00:00Z",
"lastObservedAt": "2026-05-18T09:00:00Z",
"packageVulnerabilityDetails": {
"cvss": [
{
"baseScore": 10.0,
"scoringVector": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H",
"source": "NVD",
"version": "3.1"
}
],
"source": "NVD",
"sourceUrl": "https://nvd.nist.gov/vuln/detail/CVE-2021-44228",
"vendorSeverity": "CRITICAL",
"vulnerabilityId": "CVE-2021-44228",
"vulnerablePackages": [
{
"arch": "X86_64",
"fixedInVersion": "2.15.0",
"name": "log4j-core",
"packageManager": "JAR",
"remediation": "Update log4j-core to version 2.15.0 or later",
"version": "2.14.1"
}
]
},
"inspectorScore": 10.0,
"inspectorScoreDetails": {
"adjustedCvss": {
"cvssSource": "NVD",
"score": 10.0,
"scoringVector": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H",
"version": "3.1"
}
},
"remediation": {
"recommendation": {
"text": "Update log4j-core to version 2.15.0 or later",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-44228"
}
},
"resources": [
{
"details": {
"awsEc2Instance": {
"iamInstanceProfileArn": "arn:aws:iam::123456789012:instance-profile/WebAppRole",
"imageId": "ami-0abc123def456789a",
"ipV4Addresses": ["10.0.1.45", "203.0.113.12"],
"subnetId": "subnet-0abc123def456789a",
"type": "t3.medium",
"vpcId": "vpc-0abc123def456789a"
}
},
"id": "i-0abc123def456789a",
"partition": "aws",
"region": "eu-west-1",
"type": "AWS_EC2_INSTANCE"
}
],
"severity": "CRITICAL",
"status": "ACTIVE",
"title": "CVE-2021-44228 - log4j-core",
"type": "PACKAGE_VULNERABILITY",
"updatedAt": "2026-05-18T09:00:00Z"
}The fields worth paying attention to:
inspectorScore is Inspector's adjusted score, not raw CVSS. Here they match because the instance has a public IP and the vulnerability is network-reachable. On an isolated instance, the adjusted score would be lower.
packageVulnerabilityDetails.vulnerablePackages[].fixedInVersion is the version that resolves the finding. Inspector requires a fix to exist before generating a finding at all; if this field is populated, that's why you're seeing the finding.
packageVulnerabilityDetails.vulnerablePackages[].packageManager shows JAR here, meaning Inspector found this in a bundled Java archive rather than an OS-managed package. It scans both.
resources[].details.awsEc2Instance.ipV4Addresses: having both a private (10.0.1.45) and public (203.0.113.12) IP is what triggers the network reachability assessment. An instance with only private addresses gets a lower adjusted score.
status of ACTIVE means the finding has not been suppressed or remediated. Inspector sets this automatically.
Integration points
Inspector findings publish to Security Hub natively, and from there you can route them to EventBridge for automated responses: tickets, SNS alerts, Lambda functions, whatever your workflow needs.
ECR images get re-evaluated as new CVE data arrives, not just on push. An image that was clean when you deployed it can pick up an active finding days later when a new vulnerability is disclosed. The initial scan isn't a permanent pass.
For Lambda, Inspector scans both the deployment package and attached layers. A vulnerable layer shared across functions generates a finding against every function using it, and finding counts can spike fast if a popular shared layer has a CVE and you're not tracking by layer ARN alongside function ARN.