Inspector Vulnerability Assessment
AWS's automated, continuous vulnerability scanner for EC2, container images, and Lambda — it finds known CVEs and exposures in your workloads without you scheduling scans.
What is Amazon Inspector?
Amazon Inspector is an AWS service that automatically and continuously scans your workloads for software vulnerabilities and unintended network exposure. It assesses EC2 instances, container images in Amazon ECR, and Lambda functions, checking their installed software against databases of known vulnerabilities (CVEs) and flagging findings with severity, affected resources, and remediation guidance. The “vulnerability assessment” job is answering “which of my running workloads contain known-vulnerable software, and how bad is it?” — continuously, without anyone scheduling scans.
What makes it useful: continuous and automated
The important shift Inspector represents is from periodic manual scanning to continuous automated assessment. Traditional vulnerability management ran scans on a schedule (weekly, monthly), leaving windows where newly-disclosed vulnerabilities went undetected until the next run. Inspector instead scans automatically and continuously — it discovers eligible resources without you enumerating them, scans container images as they’re pushed to ECR, re-evaluates workloads when new CVEs are published (so a vulnerability disclosed today surfaces against your existing fleet without a new scan job), and requires no scan scheduling or scanner infrastructure to maintain. For EC2 it uses agentless scanning or the AWS Systems Manager agent to inventory installed packages; for containers it inspects image layers; for Lambda it examines function code and dependencies. Findings are prioritized with a risk score and flow into AWS Security Hub and EventBridge, so they can be aggregated with other security signals and drive automated remediation rather than sitting in an isolated console. This positions Inspector as the workload vulnerability feed in a broader AWS security posture, complementing Macie (sensitive-data discovery), GuardDuty (threat detection), and Config (configuration compliance).
Using it well — and its limits
Inspector is valuable but, like any scanner, its findings are a starting point for prioritization, not a to-do list to blindly clear. The same lesson from CVSS applies: a scanner reporting hundreds of “critical” CVEs across a fleet can overwhelm a team, and patching strictly by raw severity wastes effort on high-scored-but-low-real-risk findings while genuinely dangerous, internet-exposed, or actively-exploited vulnerabilities wait. Inspector’s risk scoring incorporates network reachability (is the vulnerable resource actually exposed?) and exploitability signals to help, but human judgment about asset criticality and exploitation-in-the-wild (KEV) still matters — the goal is contextual prioritization, not chasing the count to zero. Other realities: Inspector finds known vulnerabilities in software inventory, so it doesn’t catch custom-code logic flaws (that’s SAST/DAST and code review), zero-days (unknown by definition), or misconfigurations that aren’t software vulnerabilities (that’s Config/Security Hub’s domain) — it’s one layer in defense-in-depth, not a complete security program. And it has cost (priced per resource scanned/assessed), so like other continuous-scanning services it should be scoped and its findings actively triaged rather than enabled-and-ignored. The recurring mistakes: treating the finding count as the metric (rather than real risk reduction), assuming Inspector covers vulnerability classes it doesn’t, and not wiring findings into an actual remediation workflow so they translate into patches.
What people get wrong
- Patching by raw severity/count — hundreds of “critical” findings need contextual prioritization (exposure, exploitation, asset criticality), not blind top-down clearing.
- Assuming it covers everything: Inspector finds known software CVEs and network exposure — not custom-code logic flaws, zero-days, or non-software misconfigurations.
- Enable-and-ignore — findings only reduce risk when routed (via Security Hub/EventBridge) into a real remediation process; a scanner nobody acts on is just cost.
Primary source: Amazon Inspector documentation
Historical figures and technical concepts for informational purposes only. Not technical, professional, legal, or financial advice. Sources: Official Documentation.