Amazon Inspector got a complete rewrite in late 2021, and the v2 release changed everything about how AWS-native container scanning works. The original Inspector was clunky, agent-dependent, and limited to EC2 instances. Inspector v2 is agentless, covers ECR container images and Lambda functions, and provides continuous monitoring instead of one-time assessments.
If you evaluated Inspector v1 and walked away unimpressed, it is time to look again. And if you are using Inspector v2 but only scratching the surface, this post covers how to get real value from it.
What Changed in V2
The differences between Inspector v1 and v2 are not incremental -- they are architectural.
Agentless scanning. Inspector v1 required an SSM agent on every EC2 instance. V2 scans ECR images and Lambda functions without any agent. For EC2 instances, it uses SSM inventory data that most organizations already collect.
Continuous monitoring. V1 ran assessment templates on a schedule. V2 monitors continuously. When a new CVE is published, Inspector re-evaluates all your resources and generates new findings without you triggering anything.
Broader coverage. V1 covered EC2 only. V2 covers EC2 instances, ECR container images, and Lambda functions. The container and Lambda coverage is what makes it relevant for modern cloud-native environments.
Application dependency scanning. V1 only scanned OS packages. V2 scans application-level dependencies for major languages -- Node.js, Python, Java, Go, Ruby, .NET, and Rust. This is critical because most vulnerabilities in container images are in application dependencies, not OS packages.
Simplified pricing. V1 pricing was per-assessment-run. V2 charges based on the number of resources scanned per month. For most organizations, v2 is cheaper and provides more coverage.
Configuring Inspector V2 for Containers
Getting started with Inspector v2 is straightforward, but the defaults leave room for optimization.
Enable ECR scanning. In the Inspector console, enable scanning for ECR container images. Inspector will begin scanning all images in your ECR repositories in the region.
Choose your scanning mode. Inspector supports two ECR scanning modes. Basic scanning uses the open-source Clair engine and only scans OS packages on push. Enhanced scanning (powered by Inspector) covers OS and application packages continuously. Always use enhanced scanning for production repositories.
Configure scan filters. By default, Inspector scans all ECR repositories. If you have hundreds of repositories including development and experimental ones, configure scan filters to focus on the repositories that matter. Reduce noise by excluding repositories that do not deploy to production.
Enable Lambda scanning. Inspector can scan Lambda function code and layers for vulnerable dependencies. Enable this alongside ECR scanning for comprehensive serverless coverage.
Enable EC2 scanning. For completeness, enable EC2 scanning as well. Inspector uses SSM inventory to scan OS packages on your instances without installing a separate agent.
Understanding Inspector Findings
Inspector v2 findings include more context than most scanning tools provide. Use it.
Enhanced CVSS scoring. Inspector adjusts CVSS scores based on exploit availability and other contextual factors. An Inspector score of 9.8 means the vulnerability has a public exploit and is actively being targeted, not just that the CVSS base score is high.
Exploit availability. Each finding indicates whether a public exploit exists. This is one of the most useful fields for prioritization. A CVE with no known exploit is significantly less urgent than one with a Metasploit module.
Fix availability. Inspector tells you whether a fix is available and what version to update to. This saves your team from investigating a finding only to discover there is nothing they can do about it yet.
Network reachability. For EC2 findings, Inspector provides network reachability analysis. It tells you whether the vulnerable instance is accessible from the internet, from a VPC, or only locally. A vulnerability on an internet-facing instance is far more urgent than the same vulnerability on an isolated internal server.
Integrating Inspector With Your Workflow
Findings in the Inspector console are useful for ad-hoc investigation. For operational security, you need integration with your existing tools.
Security Hub integration. Inspector automatically sends findings to Security Hub. This gives you a centralized view alongside findings from GuardDuty, Config, and other sources. Security Hub also enables cross-account aggregation.
EventBridge for automation. Inspector publishes finding events to EventBridge. Create rules that trigger Lambda functions for automated response -- creating Jira tickets, sending Slack alerts, or triggering remediation workflows.
S3 export for analysis. Export Inspector findings to S3 for long-term retention and analysis. Use Athena to query findings across your entire history.
CI/CD integration. While Inspector primarily scans images in ECR, you can trigger on-demand scans of images during your CI/CD pipeline using the Inspector Scan API (SBOM generation). This catches vulnerabilities before images reach the registry.
Multi-Account Strategy
Most AWS organizations span multiple accounts. Inspector supports this through AWS Organizations integration.
Designate a delegated administrator. Choose one account (typically your security account) as the Inspector delegated administrator. This account can enable Inspector across all organization accounts and view findings from all accounts in a single dashboard.
Auto-enable for new accounts. Configure Inspector to automatically enable scanning when new accounts join the organization. This prevents coverage gaps when teams create new accounts.
Use organization-wide metrics. The delegated administrator can view aggregate metrics -- total findings by severity, most common vulnerabilities, accounts with the most critical findings. Use these metrics to identify which teams need the most help.
Handling Finding Volume
A large AWS environment can generate thousands of Inspector findings. Managing this volume requires strategy.
Filter aggressively. Use the Inspector dashboard's filtering capabilities to focus on what matters: critical and high findings in production accounts, findings with known exploits, findings with available fixes.
Create suppression rules. Inspector supports suppression rules that automatically close findings matching specific criteria. Use these for known false positives or accepted risks. Document the justification for each suppression rule.
Focus on fix availability. Prioritize findings where a fix is available. Your team's time is better spent patching a fixable high-severity CVE than investigating an unfixable critical one.
Track trends, not counts. The absolute number of findings is less important than the trend. Are critical findings decreasing over time? Are new findings being addressed within your SLA? Are old findings accumulating?
Inspector Limitations
Inspector v2 is good, but it has limitations you should understand.
No runtime analysis. Inspector scans the static contents of images and function packages. It does not observe what actually runs at runtime. A vulnerability in a library that is present but never loaded is still reported.
Limited custom policy support. Inspector checks against known CVEs. It does not support custom security policies like "all images must use a specific base image" or "no images with GPL-licensed packages."
Regional scope. Inspector operates per-region. You need to enable it in every region where you have resources. Findings do not aggregate across regions automatically (Security Hub handles this).
Scan frequency for ECR. While Inspector provides continuous monitoring, the re-scan frequency for ECR images depends on the image's lifecycle. Actively used images are re-scanned more frequently than dormant ones.
How Safeguard.sh Helps
Safeguard.sh builds on Inspector's vulnerability findings by adding the context and workflow capabilities that Inspector lacks. It generates comprehensive SBOMs for every scanned image, provides reachability analysis to determine whether vulnerable code is actually executed, and offers policy enforcement capabilities that go beyond CVE matching.
The platform integrates Inspector findings with deployment context from your EKS and ECS clusters, so you see not just which images are vulnerable but which vulnerable images are running in production, how they are exposed, and what the remediation priority should be. This turns Inspector from a vulnerability scanner into a complete container security workflow.