Visual overview
Inspector discovers vulnerable supported workloads, IAM governs administrative access, and Organizations can centralize multi-account enablement and oversight.
Technical reference
Inspector findings connect a workload artifact to vulnerability intelligence and, where supported, contextual evidence that helps rank remediation.
Package findings reference CVEs; supported Windows findings can aggregate remediated CVEs under Microsoft KB identifiers.
Inspector uses vendor/NVD vulnerability scoring information as a standardized severity input, with current CVSS metadata depending on source.
For supported EC2 package findings, Inspector correlates base vulnerability data with factors such as network reachability and exploitability.
Supported EC2 operating systems can be assessed through Systems Manager inventory or eligible agentless snapshot-based scanning.
Inspector integrates with Amazon ECR enhanced scanning and continuously monitors eligible active images as vulnerability intelligence changes.
Standard scanning covers supported package dependencies; code scanning is a distinct optional layer.
Service limits and capabilities can change. Values shown here reflect the current AWS documentation; use the linked official sources below as the source of truth.
Inspector asks what is vulnerable, not who is attacking
Amazon Inspector is a vulnerability management service that discovers and continuously scans supported workloads for software vulnerabilities and unintended network exposure. Its primary resource scopes include Amazon EC2 instances, container images in Amazon ECR, and AWS Lambda functions, with scan behavior depending on resource type and enabled scan options. Findings describe weaknesses that should be remediated before or after an attacker discovers them.
This is fundamentally different from GuardDuty. GuardDuty detects suspicious activity from security telemetry; Inspector assesses workload exposure and known software weaknesses. A vulnerable package can create an Inspector finding even when no attack has occurred. Conversely, suspicious credential use can create a GuardDuty finding even when the affected compute image has no known package vulnerability.
Scanning mechanics depend on the workload
For EC2, Inspector can analyze package vulnerabilities and network exposure using supported scanning paths, including agent-based and agentless capabilities according to operating system and account configuration. For ECR, enhanced scanning integrates Inspector with private container repositories so active images can be scanned for software package vulnerabilities and monitored as vulnerability intelligence changes. Lambda scanning examines deployed functions and layers for supported package vulnerabilities, with optional code-scanning capabilities available separately.
Continuous scanning matters because the resource may not change when a new CVE is published. A container image or function that looked clean yesterday can become vulnerable when new intelligence connects an installed package version to a newly disclosed issue. Inspector therefore maintains findings and coverage as resources and the vulnerability database evolve, rather than acting only as a one-time pre-deployment scanner.
Severity combines standards with AWS workload context
Software vulnerability findings are tied to identifiers such as CVEs or, in some Windows cases, Microsoft KB identifiers. Common Vulnerability Scoring System (CVSS) information provides a standardized base for understanding factors such as attack complexity and privileges required. For supported EC2 package findings, the Amazon Inspector score can correlate CVSS base information with environment context such as network reachability and exploitability data.
A score is a prioritization input, not a remediation plan by itself. Operators should also consider whether the vulnerable component is actually reachable, whether an exploit is known, the business importance of the resource, patch availability, and compensating controls. Organization integration can centralize coverage and findings, but security teams still need a patch/deployment process that turns Inspector evidence into changed workloads.
Key takeaways
- 01
Inspector continuously assesses supported compute workloads for software vulnerabilities and unintended network exposure.
- 02
EC2, ECR container images, and Lambda have different scanning mechanics and coverage conditions.
- 03
CVE/CVSS information standardizes vulnerability context; Inspector can add AWS environment context to supported findings.
- 04
A newly published vulnerability can affect an unchanged workload, which is why continuous monitoring matters.
- 05
Inspector identifies weaknesses; patching, image rebuilding, deployment and compensating controls are separate remediation actions.
Official AWS sources
Use these primary AWS resources for the source material behind this article and for deeper reference.