Amazon Inspector container scanning became one of the more consequential quiet upgrades AWS security teams picked up over the past few years: instead of scanning an image once when it lands in Amazon ECR, Inspector now re-evaluates every stored image continuously, the moment a new CVE is published against any package inside it. That shift — from point-in-time to continuous — matters because the average image in a production registry sits there for weeks or months, and the vulnerability that makes it exploitable is frequently disclosed long after the scan that originally "cleared" it. Teams running mixed fleets of EC2, Lambda, ECS, and EKS workloads keep landing on the same three questions: how does Inspector's ECR scanning actually work, how does it stack up against a CI-native tool like Trivy, and does "continuous" really mean continuous. This piece answers all three, with the specifics that matter when you're deciding what runs in front of production.
What is Amazon Inspector container scanning?
Amazon Inspector container scanning is AWS's native vulnerability management capability for images stored in Amazon ECR and running on ECS, EKS, and Fargate, plus EC2 instances and Lambda functions in the same account. It replaced the old, schedule-based "Inspector Classic" — AWS rebuilt the service from the ground up and made it generally available in its current architecture in March 2022, adding automated ECR image scanning shortly after. Under the hood, it inspects OS-level packages (via apt, yum, and apk metadata) as well as language-level dependency manifests — think package-lock.json, requirements.txt, pom.xml, and go.mod — for Java, Python, Node.js, .NET, Go, and Ruby findings. Results are correlated against multiple vulnerability feeds, given a contextual risk score that can factor in network exposure for EC2, and pushed automatically into AWS Security Hub and EventBridge so they show up wherever your team already triages alerts, without a separate console to babysit.
How does Inspector ECR scanning actually work?
Inspector ECR scanning triggers an initial scan the moment an image is pushed, then keeps re-scanning it in place as the vulnerability intelligence changes underneath it — no rebuild or re-push required. There are two modes: basic scanning, which is closer to the old one-time-on-push model and relies on the Clair-style CVE data ECR has supported for years, and enhanced scanning, which is what most teams mean when they say "Amazon Inspector." Enhanced scanning adds the language-package coverage described above and the continuous re-evaluation loop. One detail worth knowing before you flip it on for a large registry: AWS lets you configure how far back Inspector looks — a rescan duration of roughly 30, 180 days, or "lifetime" — because continuously monitoring every image you've ever pushed, including ones from three years ago that nothing pulls anymore, adds cost without adding much signal. Get that window wrong and you either pay to babysit stale shelf-ware or lose visibility into an old image that unexpectedly gets pulled back into a deployment.
Amazon Inspector vs Trivy: which scanner should you trust?
Amazon Inspector vs Trivy isn't really an either/or decision — they solve different problems and most mature pipelines end up running both. Trivy, Aqua Security's open-source scanner first released in 2019, is built to run locally or in CI: it's free, it works offline against a vulnerability database that's refreshed roughly every six hours, and it's the tool most engineers reach for to fail a pull request before an image ever gets built. Amazon Inspector, by contrast, is a paid AWS service (enhanced ECR scanning is billed per image, on the order of a few cents per image per month) designed for continuous, fleet-wide monitoring after the image already exists — across every account in an AWS Organization, correlated with EC2 and Lambda exposure. The practical difference shows up in a scenario every team eventually hits: a critical CVE drops for a base-image package six weeks after ten images built from it are already running in production. Trivy, run only at build time, never re-checks those ten images unless someone manually reruns it. Inspector's continuous model catches it automatically. The tradeoff is that Inspector only sees what's inside your AWS account — it has no opinion about an image sitting in Docker Hub, GHCR, or a GitLab registry that hasn't been pushed to ECR yet.
What does "continuous vulnerability scanning" actually mean in AWS?
Continuous vulnerability scanning in AWS means Inspector re-evaluates resources you've already scanned against newly disclosed CVEs without waiting for a new build, deploy, or manual trigger — typically surfacing a new finding within about a day of a vulnerability landing in the National Vulnerability Database. That's a meaningful change from how AWS handled this a decade ago: Inspector Classic, launched in 2015, required you to define assessment templates and run scans on a schedule you controlled, which meant a two-week gap between runs was two weeks of blind spot by design. The current model is event-driven — new CVE data or a newly pushed image is the trigger, not a cron job. For a concrete sense of scale, AWS has noted that its Inspector fleet processes vulnerability intelligence updates against millions of resources continuously; the point isn't the exact number, it's that the re-evaluation happens without anyone on your team remembering to kick it off.
What are the blind spots in Amazon Inspector's container scanning?
Amazon Inspector's container scanning has real blind spots, and the biggest one is scope: it only covers images inside ECR and workloads inside the AWS account it's enabled on. If your organization pulls base images from Docker Hub, publishes to a third-party registry, or runs any workload on another cloud, Inspector has nothing to say about it. It also isn't a secrets scanner or an IaC misconfiguration checker — a hardcoded AWS key or an overly permissive Dockerfile won't show up in an Inspector finding. There's no license-risk or SCA policy engine either, and no built-in way to gate a pull request before merge — Inspector tells you about a problem in an image that already exists, not one you're about to create. Finally, because Inspector, Trivy, Snyk, and Grype each pull from overlapping but not identical vulnerability databases, running more than one (which most security teams end up doing) produces duplicate and sometimes contradictory findings for the same CVE, with no native way to reconcile them into one prioritized list.
How Safeguard Helps
This is exactly the gap Safeguard is built to close. Instead of asking teams to choose between Amazon Inspector, Trivy, and whatever else is bolted onto the CI pipeline, Safeguard ingests findings from all of them — Inspector's ECR scanning, Trivy's build-time scans, and any other SCA or container tool already in use — and de-duplicates overlapping CVEs into a single, prioritized queue instead of three separate dashboards saying slightly different things about the same package. Because Safeguard isn't scoped to a single AWS account, it also covers the images Inspector can't see: registries outside ECR, multi-cloud deployments, and images that haven't been pushed anywhere yet because they're still sitting in a developer's local build. On top of aggregation, Safeguard adds what continuous scanning alone doesn't provide — SBOM generation and diffing across environments, policy-as-code gates that block a merge before a vulnerable image ever reaches ECR, and provenance tracking back to the base image and build pipeline that introduced a given CVE. For teams that have already turned on Amazon Inspector container scanning and want the confidence that comes from knowing nothing is falling through the cracks between it, Trivy, and everything else in the pipeline, Safeguard is the layer that ties continuous vulnerability scanning across AWS and beyond into one accountable, auditable system.