Amazon Inspector Hands-On: Continuous Vulnerability Scanning for EC2, ECR & Lambda

The uncomfortable truth about vulnerability management is that a clean scan is a photograph, not a promise. You scan an image at build time, it passes, you ship it — and three weeks later a new CVE lands against a library you baked in, and nothing tells you. The image did not change; the world changed. Your instance fleet drifts as packages age; a log4j-shaped event breaks on a Friday and the only question that matters is “which of our 900 instances, images and functions actually contain the vulnerable package, and which of those can an attacker reach?” A point-in-time scanner answers that the next time someone remembers to run it. Amazon Inspector answers it continuously, because it re-evaluates your existing inventory against its vulnerability database every time a new CVE is published — with no re-scan to schedule and, for most of what it covers, no agent to deploy.

This is the deep, hands-on reference for the modern Amazon Inspector — the automated, continuous service (often called Inspector v2, API namespace inspector2) that replaced the old Inspector Classic assessment-template model. We treat it as a pipeline — discover → inventory → match → score → route → respond — and walk each stage option by option: the three scan targets (EC2 via the SSM agent or agentless EBS snapshots, ECR container images with scan-on-push and continuous rescan, and Lambda functions plus your Lambda code); the finding types (package vulnerability with a CVE, network reachability, and code vulnerability); the Inspector risk score — CVSS re-weighted by real network reachability and real-world exploitability (EPSS and known-exploit signals); the vulnerability-intelligence database and how findings appear and auto-close as CVEs land and packages get patched; findings into Security Hub and EventBridge for routing and auto-ticketing; suppression rules, SBOM export (CycloneDX / SPDX), CI/CD scanning before an image ever reaches a registry, and org-wide rollout through a delegated administrator with auto-activate. Because this is the document you open the day a CVE trends, every setting, scan-status reason, finding field, cost driver and failure mode is a table you can scan mid-incident.

By the end you will stop treating “the scan passed” as safety and start treating Inspector as a live feed you route and act on. You will know why an EC2 instance shows zero findings (and why the fix is almost always the same SSM story as every other Systems Manager feature), why an image scanned once never gets re-evaluated, why a CVSS 9.8 vulnerability can legitimately show as Medium in Inspector, why an EventBridge rule copied from your GuardDuty setup never fires (severity here is a string, not a number), and how to wire the whole detect-and-ticket loop with aws inspector2 and Terraform so it survives an org-wide rollout. Finding the vulnerabilities is Inspector’s job; making those findings reach the right queue and get patched is yours, and that is the craft this article teaches.

What problem this solves

Inspector solves the coverage-and-currency gap that every point-in-time scanner leaves open. Traditional scanning has two failure modes baked in. First, coverage: someone has to remember to run it, against the right targets, and interpret the output — so the instance that spun up yesterday, the image in the repo nobody deploys from, and the Lambda a contractor left behind are exactly the ones that go unscanned. Second, currency: a scan is true only at the instant it runs. The CVE that matters most is often published after your last scan, against code you have not touched — and a photograph from last Tuesday cannot see it. Building continuous coverage yourself means standing up a scanner fleet, an agent rollout, a package-to-CVE matching engine, and a feed of curated vulnerability intelligence, then keeping all of it current forever. Inspector is that capability as a switch you flip per account, per resource type.

What breaks without it, concretely: a base image built eight months ago sails through its build-time scan, gets deployed to 40 tasks, and silently carries a critical glibc or openssl CVE disclosed last month — invisible, because nobody re-scanned a passing image. An EC2 fleet accumulates unpatched OS packages because the patching cadence slipped, and the first anyone hears of it is a pen-test report. A Lambda function bundles a vulnerable requests or urllib3 version in a layer, and there is no image and no host to “scan” in the traditional sense at all. Each of these is a real, common exposure, and each produces a distinctive package-to-CVE match that Inspector finds continuously.

Who hits this: every account that runs compute — which is every account. Vulnerability management is a baseline control that every framework (PCI-DSS 6.x, SOC 2, HIPAA, ISO 27001, FedRAMP, CIS AWS Foundations) assumes you have, and Inspector is the AWS-native way to satisfy it for EC2, containers and serverless in one place, feeding Security Hub so it sits alongside your other findings. To frame the field before the deep dive, here is what Inspector does, what it does not, and where each answer actually lives:

Learning objectives

By the end of this article you can:

• Activate Amazon Inspector end to end for EC2, ECR, Lambda and Lambda code — via Console, aws inspector2 and Terraform — and prove each resource type is being scanned with list-coverage.
• Explain how EC2 scanning works through the SSM agent (managed instance + AmazonSSMManagedInstanceCore) versus agentless EBS-snapshot scanning, and choose hybrid mode.
• Configure ECR enhanced scanning — basic vs enhanced, scan-on-push vs continuous, and the rescan duration — and know why an aged image drops out of continuous monitoring.
• Enable Lambda standard scanning (dependency CVEs) and Lambda code scanning (your source), and know the supported-runtime and activity constraints.
• Read a finding’s type (PACKAGE_VULNERABILITY / NETWORK_REACHABILITY / CODE_VULNERABILITY), its CVE, affected package and fixed version, and the Inspector risk score versus the raw CVSS and EPSS.
• Route findings to Security Hub (ASFF) and EventBridge (severity is a string), write suppression rules, export an SBOM, and scan in CI/CD before an image reaches a registry.
• Roll Inspector out across an organization with a delegated administrator and auto-activate, and control the cost (per EC2 instance / per image scan / per Lambda function).

This maps directly to SCS-C02 (Security Specialty — vulnerability management, Inspector, Security Hub), SOA-C02 (SysOps — enabling and operating Inspector, SSM prerequisites, EventBridge automation), and SAP-C02 (Professional — org-wide security operations and cost control).

Prerequisites & where this fits

You should be comfortable with the AWS account model (accounts, regions, IAM roles and service-linked roles), containers and Amazon ECR (see Amazon ECR Hands-On: Push, Pull, Scan & Lifecycle Container Images), the basics of AWS Systems Manager (the SSM agent and managed instances — the same machinery every SSM feature depends on), Lambda packaging (dependencies and layers, per AWS Lambda Layers & Packaging: Managing Dependencies the Right Way), and EventBridge rules and SNS for routing (see Amazon EventBridge Hands-On: Event Buses, Rules, Patterns & Pipes).

Inspector sits in the Security / detective layer, next to — not instead of — your other controls. It complements Amazon GuardDuty Hands-On: Threat Detection & Automated Response (GuardDuty asks “is something behaving maliciously right now?”; Inspector asks “what known vulnerabilities do my resources contain, and how reachable are they?”) and AWS Config: Resource Inventory, Compliance Rules & Remediation Hands-On (Config asks “is this resource configured to policy?”). All three feed Amazon Security Hub Hands-On: Findings, Standards & Compliance, which is where you actually work the aggregated queue. Here is who owns which layer during a real security program, so you route a finding to the right team:

Core concepts

Six mental models make every later decision obvious.

Inspector v2 is continuous and automated — Classic was not. The old Amazon Inspector Classic (API inspector) was an assessment-template model: you installed the Inspector agent, defined an assessment target and template with rules packages, and ran an assessment on a schedule or on demand. The modern Amazon Inspector (API inspector2) has no templates and no runs — you activate it per resource type and it automatically discovers and continuously scans everything, re-evaluating as new CVEs arrive. If you read a doc mentioning “assessment templates,” “rules packages,” or “the Inspector agent,” it is about Classic and does not apply here.

Activation is per account, per region, per resource type. You enable Inspector separately for EC2, ECR, LAMBDA (dependencies) and LAMBDA_CODE (source) — and it is regional, like almost everything in AWS. A resource type you did not activate is simply not scanned; a region you did not activate is dark. This granularity is the point: you can run ECR scanning everywhere but scope the pricier Lambda code scanning to production accounts.

Most of Inspector is agentless; EC2 is the exception that uses the SSM agent (or agentless snapshots). There is no Inspector agent anymore. ECR images and Lambda functions are scanned entirely from the service side with nothing on the resource. EC2 has two mechanisms: agent-based scanning that reads a software inventory through the SSM agent (which most instances already run), and agentless scanning that takes an EBS snapshot and inventories it without any agent — with a hybrid mode that uses the agent where available and falls back to snapshots where it is not.

A finding is a package-to-CVE match with a risk score. A finding names what is vulnerable: a type (PACKAGE_VULNERABILITY, NETWORK_REACHABILITY, or CODE_VULNERABILITY), the affected resource, the CVE (for package findings), the vulnerable package and its fixed version, and an Inspector score — a 0–10 number derived from the CVSS base score but re-weighted by whether the resource is actually network-reachable and whether the CVE is actually being exploited. Findings are the atoms you route and act on.

Scanning is continuous — findings appear and auto-close on their own. Because Inspector holds a live inventory, when a new CVE is published against a package you already have, it generates a finding without any re-push or redeploy. Conversely, when you patch the package, the next scan auto-closes the finding. You are not running scans; you are subscribed to a feed.

Multi-account runs from a delegated administrator. In an organization you delegate Inspector to one account (ideally a dedicated security account) as the delegated administrator, then auto-activate chosen resource types for every existing and future member — so a new account is scanned from birth with no per-account clicking.

The vocabulary in one table

Pin down every moving part before the deep sections; the glossary repeats these for lookup:

Scan targets, option by option

Everything Inspector does hangs off what it scans. The three targets have genuinely different mechanics, and most operational pain lives in the EC2 and ECR details.

EC2 — the SSM story (and the agentless escape hatch)

EC2 scanning is where practitioners lose the most time, and the cause is almost always the same one that bites every other AWS Systems Manager feature: the instance is not a managed instance. Inspector’s agent-based EC2 scanning does not ship its own agent — it uses the SSM agent already present on most modern AMIs to collect a software inventory (via SSM associations Inspector creates for you, named with a do-not-delete suffix), then matches that inventory against the vulnerability database. For that to work, the instance must be a fully managed SSM instance:

When SSM cannot reach an instance — a hardened image with no agent, an isolated subnet, a third-party appliance — you have the agentless escape hatch. Agentless scanning takes a point-in-time EBS snapshot, inventories it in AWS-managed infrastructure, and produces the same package findings without any agent or SSM connectivity. The recommended account setting is hybrid (EC2_HYBRID) scan mode: agent-based where SSM works (which also enables deep inspection of application/language packages on Linux), agentless everywhere else. Choose deliberately:

Deep inspection deserves a callout: by default, agent-based Linux scanning inventories OS packages and application libraries in a set of default paths; you can add up to five custom paths with update-ec2-deep-inspection-configuration when your app installs dependencies somewhere non-standard. If deep inspection has no data yet you will see coverage reasons like DEEP_INSPECTION_NO_INVENTORY — normal right after activation.

EC2 also produces the second finding class: network reachability. Inspector analyses your security groups, NACLs, route tables, IGWs, VPC peering and load balancers to determine whether a port on the instance is reachable from the internet or another VPC, and raises a NETWORK_REACHABILITY finding describing the open port range and the full network path. This is what turns “port 3389 is open” into “port 3389 is open and reachable from 0.0.0.0/0 through this IGW,” which is the version that matters.

ECR — basic vs enhanced, on-push vs continuous

ECR has two scanning worlds, and conflating them is a classic mistake. Basic scanning is a native ECR feature (no Inspector) that checks OS packages only against an open-source CVE feed, on push or manually — it is fine for a sanity check but it does not scan application dependencies and it does not continuously rescan. Enhanced scanning is Amazon Inspector: OS packages and programming-language packages, with continuous rescanning as new CVEs land. Activating Inspector for ECR flips the registry’s scanning configuration to enhanced.

Within enhanced scanning, two settings govern when an image is scanned:

The rescan-duration mechanic is the subtle one. With the default DAYS_90, an image that is not pushed or pulled for 90 days drops out of continuous rescanning (coverage reason becomes SCAN_ELIGIBLE rather than continuously monitored) — because Inspector assumes an image nobody pulls is not running. A pull resets the clock. For images backing long-lived production services, set rescanDuration = LIFETIME so they are always re-evaluated. Images can also fail to scan for structural reasons — an unsupported base OS (UNSUPPORTED_OS), an image larger than the scan size limit (IMAGE_SIZE_EXCEEDED), or an unsupported manifest media type.

Lambda — dependencies and your code

Lambda scanning has two independently-activated halves. Lambda standard scanning (LAMBDA) inventories the application dependencies in the function’s deployment package and its layers, matching them against the vuln DB — the same PACKAGE_VULNERABILITY findings you get elsewhere, for a resource that has no host or image to scan. Lambda code scanning (LAMBDA_CODE) is different in kind: it runs static analysis on your own source code to find code-level flaws — injection, weak crypto, hardcoded credentials, unvalidated input — and raises CODE_VULNERABILITY findings with the offending file, line range, and a suggested remediation, using automated-reasoning detectors.

Two constraints to internalise. First, supported runtimes matter — standard and code scanning each support a set of managed runtimes (Java, Node.js, Python, Go, .NET, Ruby among them); a function on an unsupported or deprecated runtime shows UNSUPPORTED_RUNTIME in coverage. Second, Inspector scans functions with recent activity — a function must have been invoked or updated within a rolling window (about 90 days); functions that have sat idle beyond that are not scanned until they are updated or invoked again, so a long-dormant function can legitimately show no coverage.

Finding types, the risk score and the vuln database

A finding is the product; reading it fluently — type, CVE, package, and which score to trust — is most of the operational skill.

The three finding types

Anatomy of a package finding (the fields you route on)

When a finding lands in EventBridge or Security Hub, these are the fields your rule, ticket and dashboards read:

The Inspector risk score vs CVSS vs EPSS — the confusion, resolved

The single most common Inspector question is “why does this CVSS 9.8 vulnerability show as Medium?” The answer is that a finding carries three different numbers, and the severity band follows the one that accounts for your environment:

The Inspector score starts from CVSS but adjusts it using network reachability (a remote-code-execution CVE on a port nothing can reach is scored down) and exploitability signals (a CVE with a known, in-the-wild exploit is scored up). The finding’s Inspector score details panel shows exactly which CVSS metrics were re-weighted and why. The severity band (CRITICAL/HIGH/…) is derived from the Inspector score, which is why it can differ from the CVSS band. The right prioritisation is not “sort by CVSS descending” — it is exploitAvailable = YES and high epss.score and fixAvailable = YES, because that is a vulnerability that is exploitable, being exploited, and fixable today.

The vulnerability database and the finding lifecycle

Inspector maintains a vulnerability-intelligence database aggregated from 50+ sources — the NVD for CVSS, plus vendor and distro advisories (Amazon Linux Security Center, Debian, Ubuntu USN, Red Hat, Alpine secdb, and language ecosystems). It also folds in exploitability signals (known-exploited catalogues) and EPSS. Because Inspector keeps a live inventory of your packages, the lifecycle runs itself:

The operational takeaway is badge 4 in the diagram: a finding whose firstObservedAt is later than the resource’s creation is a new CVE against old code — exactly the exposure a point-in-time scanner never shows you.

Routing: Security Hub, EventBridge, suppression and SBOM

A finding in the Inspector console changes nothing until you route it. Inspector integrates on two axes — an aggregation path (Security Hub) and an event path (EventBridge) — plus the controls to tune and export.

Findings to EventBridge — severity is a string

Inspector publishes to the default EventBridge bus in the finding’s region, with source = "aws.inspector2". The event detail-type tells you what happened:

The trap here is the mirror image of GuardDuty’s. In GuardDuty, detail.severity is a number and matching the word "High" fails. In Inspector, detail.severity is a string — so people who copy their GuardDuty numeric pattern get a rule that never fires:

{
  "source": ["aws.inspector2"],
  "detail-type": ["Inspector2 Finding"],
  "detail": {
    "severity": ["CRITICAL"],
    "status": ["ACTIVE"],
    "exploitAvailable": ["YES"]
  }
}

From the rule you fan out to whatever should react:

Suppression rules — hide noise, keep the record

An Inspector suppression rule is a filter with action SUPPRESS. Matching findings move to status SUPPRESSED — they are not deleted; they are retained (so you keep the audit trail and can review them) but excluded from the active list and from Security Hub’s active findings. This is the right tool for an accepted risk (“this CVE has no fix and we have a compensating control”), a dev-only exposure, or a false positive on a package you have patched out-of-band. You build the filter from finding criteria:

The discipline (badge 6): suppress by specific, documented criteria — a named CVE, a named repo, a tag — and record the justification, never a blanket “hide everything above the pain threshold.” A too-broad suppression rule is how a real critical finding disappears.

SBOM export and CI/CD scanning

Inspector can export a Software Bill of Materials for its monitored resources to S3, in CycloneDX 1.4 or SPDX 2.3 format — the machine-readable inventory auditors, supply-chain tooling and your own “which of us runs xz?” queries want. It needs an S3 bucket and (for the encryption) a KMS key the Inspector service role can use (see AWS KMS Hands-On: Keys, Key Policies & Envelope Encryption).

Separately, CI/CD scanning lets you catch a vulnerable image before it ever reaches a registry. The inspector-sbomgen tool generates an SBOM from a container image or directory in your pipeline, and the lightweight inspector-scan API (aws inspector-scan scan-sbom) evaluates that SBOM against Inspector’s database and returns the vulnerabilities as CycloneDX — which your pipeline can fail on by severity. AWS ships plugins/actions for Jenkins, GitHub Actions, GitLab and CodeCatalyst, so a build stage can block a critical image the same way it blocks a failing unit test. This path is billed per scan and does not require activating continuous scanning on any resource — it is a pure pipeline gate that pairs naturally with CI/CD on AWS: CodePipeline + CodeBuild Hands-On.

Multi-account: delegated administrator & auto-activate

One account is a demo; a real estate is dozens. Inspector’s org model lets you activate and govern the whole thing from one place.

From the management account you register a dedicated security account as the Inspector delegated administrator; from that account you set auto-activate per resource type so every existing and future member is scanned. Getting auto-activate wrong is why “a new account is unscanned” happens — you set it per resource type, and it applies to new members automatically but you must associate existing members too.

When you diagnose “this member has no findings,” check its association state first:

Architecture at a glance

The diagram traces the continuous vulnerability pipeline left to right. In SCAN TARGETS, Inspector auto-discovers and scans three resource classes: EC2 instances (through the SSM agent for a deep OS + language-package inventory, or agentless EBS snapshots where SSM cannot reach), ECR container images (scan-on-push plus continuous rescan), and Lambda functions plus your Lambda code. Those inventories feed the INSPECTOR zone, where every package is matched against the vulnerability-intelligence database and each match is assigned an Inspector risk score — the CVSS base score re-weighted by real network reachability and real-world exploitability (EPSS and known-exploit signals). Matching produces a FINDING carrying the CVE, the vulnerable package and its fixed version, and a severity band expressed as a string (CRITICAL, HIGH, …). Findings flow automatically into Security Hub (normalised to ASFF) and onto the default EventBridge bus, where a rule matching detail.severity as a string routes critical, exploitable findings into the RESPOND zone — SNS to notify a human and a ticketing Lambda (or SSM Automation runbook) to open a Jira ticket with the exact package to patch.

The six numbered badges mark where the pipeline silently breaks: an EC2 instance that is not an SSM managed instance and so is never scanned (badge 1 — the UNMANAGED_EC2_INSTANCE reason); an ECR image scanned once on push but never continuously rescanned, or aged past its rescan duration (badge 2); the risk-score-versus-CVSS confusion when a high-CVSS CVE scores lower because nothing can reach it (badge 3); the continuous-scan value where a new CVE generates a finding with no redeploy (badge 4); findings missing from Security Hub, or an EventBridge rule that never fires because it matched severity numerically instead of as a string (badge 5); and noise plus cost — accepted-risk findings paging the on-call and the bill scaling with resource count, both tamed with suppression rules and scoping (badge 6). The legend narrates each as symptom, the exact confirm command, and the fix.

Real-world scenario

Northwind Analytics, a fictional but realistic data-platform company, runs a 23-account AWS organization across ap-south-1 and eu-west-1: a mix of EC2 batch workers, roughly 140 ECR repositories feeding ECS, and about 300 Lambda functions. Vulnerability management was a quarterly ritual — a contractor ran an image scanner against “the important repos,” produced a spreadsheet, and the platform team patched what they could before the next audit. Between quarters, the estate was a black box. The ECR “scan on push” toggle was on, which everyone treated as coverage, so nobody looked again.

The incident began when a widely-used compression library disclosed a critical remote-code-execution CVE on a Tuesday. Northwind’s images had all passed their build-time scans months earlier — scan on push had returned clean, once, and never looked again (badge 2). The vulnerable library was baked into a base image that backed 31 of the 140 repositories, running in production. With only scan-on-push, none of those images were re-evaluated when the CVE landed; the spreadsheet was six weeks stale; and the security team’s honest answer to “are we affected?” was “we’ll get back to you.” It took two engineers most of a day grepping Dockerfiles and pulling images by hand to build the list the tooling should have produced in seconds.

The post-incident review rebuilt the program around Amazon Inspector, and it maps one-to-one to this article’s failure badges. First, they activated Inspector for EC2, ECR, LAMBDA and LAMBDA_CODE org-wide: registered their dedicated security account as the delegated administrator, set auto-activate for all four resource types, and — catching badge “auto-activate covers new, not existing” — ran associate-member across all 23 existing accounts, in both regions. They flipped ECR to enhanced scanning and set rescanDuration = LIFETIME on the production repositories, so an idle-but-deployed image could never age out of continuous monitoring again. The moment enhanced scanning caught up, Inspector produced the exact list of affected images — 31 repos, each with the image digest, the vulnerable package version, and the fixedInVersion — in the console, no grepping.

Second, the EC2 side revealed a coverage hole nobody knew about. list-coverage showed 60-odd instances with reason UNMANAGED_EC2_INSTANCE — a legacy Packer-built AMI whose instance profile predated the SSM managed policy, so the SSM agent was installed but the instances were never managed (badge 1). Rather than chase 60 instance profiles overnight, they switched the account to EC2_HYBRID scan mode, and agentless snapshot scanning covered every one of them within hours while they fixed the profiles properly. Third, they built the response plane they never had. An EventBridge rule on the default bus in each region matched detail.severity = "CRITICAL" and detail.exploitAvailable = "YES" and detail.status = "ACTIVE" — and they caught the string-vs-number trap in review, having first copied their GuardDuty rule’s {"numeric":[">=",9]} pattern, tested it with aws events test-event-pattern, and watched it match nothing (badge 5). The corrected rule fanned out to SNS (PagerDuty + a SecOps Slack channel) and a ticketing Lambda that opened a Jira issue pre-filled with the CVE, the affected resource, and the fixed version — so remediation started with a work item, not a war room.

Fourth, they tuned the inevitable noise. Their data-science sandbox deliberately ran pinned-old images for reproducibility, generating dozens of accepted-risk findings; rather than disable scanning, they wrote a suppression rule scoped to resourceTags: env=ds-sandbox with a documented justification, keeping the record while killing the pages (badge 6). And they wired SBOM export to a KMS-encrypted S3 bucket so the next “are we running xz?” question was a single query, not a fire drill. Fifth, to shift left, they added an inspector-scan stage to their image pipelines that failed the build on any CRITICAL finding — so the next baked-in critical CVE would be caught before the image ever reached ECR.

The Inspector bill landed at roughly ₹78,000/month — dominated by the ECR image scans across 140 repos and the Lambda code scanning on 300 functions — and the CFO signed it without a second look, because the one-page review put “two engineers, most of a day, to answer are we affected” next to “now: a filtered list in ten seconds, and a build that blocks the next one.” The line that went on the wall: “Scan-on-push is a photograph. We needed a live feed, everywhere, wired to a ticket.” The order is the lesson:

Advantages and disadvantages

Inspector earns its cost the first time a log4j-class CVE drops and you have the affected-resource list in ten seconds instead of a day of grepping — but only if you have paid the operational tax up front: activated for every resource type in every region, rolled out org-wide (including associate-member for existing accounts), EC2 fully SSM-managed or in hybrid mode, wired to a response plane that opens tickets, and tuned so accepted risks are documented-and-suppressed rather than ignored. Activate it and never route it, and you get a bill and a console nobody reads.

Hands-on lab

You will activate Inspector for EC2, ECR, Lambda and Lambda code; confirm coverage; push a known-vulnerable container image and read its findings, risk score and affected packages; create a suppression rule; wire an EventBridge rule into SNS on critical findings; export an SBOM; express the core as Terraform; and tear it all down. Region ap-south-1, account 111122223333. ⚠️ Inspector is not free beyond the 15-day trial — you pay per EC2 instance, per image scan, and per Lambda function; the teardown at the end stops the meter.

Step 0 — Prerequisites

aws sts get-caller-identity            # confirm account + region
export AWS_DEFAULT_REGION=ap-south-1
export ACCT=$(aws sts get-caller-identity --query Account --output text)

Step 1 — Activate Inspector for all resource types

# Turn on EC2, ECR, Lambda (deps) and Lambda code scanning for THIS account
aws inspector2 enable \
  --resource-types EC2 ECR LAMBDA LAMBDA_CODE \
  --account-ids $ACCT

Verify (expected output):

aws inspector2 batch-get-account-status --account-ids $ACCT \
  --query 'accounts[0].resourceState.{ec2:ec2.status,ecr:ecr.status,lambda:lambda.status,code:lambdaCode.status}'
# { "ec2": "ENABLED", "ecr": "ENABLED", "lambda": "ENABLED", "code": "ENABLED" }

Console path: Inspector → Activate Inspector; then Settings → Account management to toggle each resource type. Activation creates the service-linked role AWSServiceRoleForAmazonInspector2 automatically, and (for EC2 agent-based scanning) SSM associations named with a do-not-delete suffix.

Step 2 — Set EC2 hybrid mode + ECR rescan duration, then check coverage

# Prefer hybrid EC2 scanning (agent where SSM works, agentless elsewhere)
# and keep production images under continuous rescan for their lifetime.
aws inspector2 update-configuration \
  --ec2-configuration scanMode=EC2_HYBRID \
  --ecr-configuration rescanDuration=LIFETIME

aws inspector2 get-configuration \
  --query '{ec2:ec2Configuration.scanModeState.scanMode,ecr:ecrConfiguration.rescanDurationState.rescanDuration}'
# { "ec2": "EC2_HYBRID", "ecr": "LIFETIME" }

Check what is actually covered — this is the command you will live in when something is not scanned:

# EC2 coverage with the all-important scan-status REASON
aws inspector2 list-coverage \
  --filter-criteria '{"resourceType":[{"comparison":"EQUALS","value":"AWS_EC2_INSTANCE"}]}' \
  --query 'coveredResources[].{id:resourceId,status:scanStatus.statusCode,reason:scanStatus.reason}'
# e.g. [ { "id": "i-0abc...", "status": "INACTIVE", "reason": "UNMANAGED_EC2_INSTANCE" } ]

A reason of UNMANAGED_EC2_INSTANCE or NO_INVENTORY is the SSM story from the deep section — fix the instance profile / agent, or rely on hybrid agentless.

Step 3 — Push a known-vulnerable image to ECR

Create a repo and build an image that deliberately pins old, vulnerable OS and Python packages so enhanced scanning has something to find:

aws ecr create-repository --repository-name vuln-demo \
  --image-scanning-configuration scanOnPush=true >/dev/null
export REPO=$(aws ecr describe-repositories --repository-names vuln-demo \
  --query 'repositories[0].repositoryUri' --output text)

cat > Dockerfile <<'EOF'
# Old base + pinned old libraries with known CVEs (for demo only)
FROM public.ecr.aws/docker/library/python:3.9-slim
RUN pip install --no-cache-dir "urllib3==1.26.4" "requests==2.19.1"
EOF

aws ecr get-login-password | docker login --username AWS --password-stdin "${REPO%/*}"
docker build -t $REPO:demo .
docker push $REPO:demo

Step 4 — Read the findings: CVE, risk score, affected package

Enhanced scanning runs on push; give it a minute, then list this repo’s findings sorted by severity:

aws inspector2 list-findings \
  --filter-criteria '{"ecrImageRepositoryName":[{"comparison":"EQUALS","value":"vuln-demo"}]}' \
  --sort-criteria field=SEVERITY,sortOrder=DESC \
  --query 'findings[0].{sev:severity,cve:packageVulnerabilityDetails.vulnerabilityId,inspectorScore:inspectorScore,exploit:exploitAvailable,fix:fixAvailable,pkg:packageVulnerabilityDetails.vulnerablePackages[0].name,ver:packageVulnerabilityDetails.vulnerablePackages[0].version,fixedIn:packageVulnerabilityDetails.vulnerablePackages[0].fixedInVersion}'

Expected output (illustrative):

{
  "sev": "HIGH", "cve": "CVE-2021-33503", "inspectorScore": 7.5,
  "exploit": "NO", "fix": "YES",
  "pkg": "urllib3", "ver": "1.26.4", "fixedIn": "1.26.5"
}

Note the three-number story: the finding shows the CVE, an Inspector score (7.5 here), whether an exploit exists and a fix is available, and the exact package version to upgrade to (fixedInVersion). Compare inspectorScore to the CVSS in packageVulnerabilityDetails.cvss[] to see the re-weighting.

Step 5 — Create a suppression rule

Suppress LOW/INFORMATIONAL noise so the active queue is only what matters — findings move to SUPPRESSED, not deleted:

aws inspector2 create-filter \
  --name suppress-low-noise \
  --action SUPPRESS \
  --description "Accepted: low/informational findings triaged in batch" \
  --filter-criteria '{
    "severity": [
      {"comparison":"EQUALS","value":"LOW"},
      {"comparison":"EQUALS","value":"INFORMATIONAL"}
    ]
  }'

# Confirm it exists
aws inspector2 list-filters --query 'filters[].{name:name,action:action}'
# [ { "name": "suppress-low-noise", "action": "SUPPRESS" } ]

Step 6 — Wire EventBridge → SNS on CRITICAL findings (severity is a STRING)

export TOPIC=$(aws sns create-topic --name inspector-critical --query TopicArn --output text)
aws sns subscribe --topic-arn $TOPIC --protocol email --notification-endpoint secops@example.com

# Rule on the DEFAULT bus, matching severity as a STRING (not numeric!)
aws events put-rule --name insp-critical \
  --event-pattern '{
    "source": ["aws.inspector2"],
    "detail-type": ["Inspector2 Finding"],
    "detail": { "severity": ["CRITICAL"], "status": ["ACTIVE"] }
  }'

aws events put-targets --rule insp-critical \
  --targets "Id"="sns","Arn"="$TOPIC"

# Allow EventBridge to publish to the topic (topic policy) — then PROVE the pattern:
aws events test-event-pattern \
  --event-pattern '{"detail":{"severity":["CRITICAL"]}}' \
  --event '{"detail":{"severity":"CRITICAL"}}'
# { "Result": true }        # {"numeric":[">=",9]} would return false here

Step 7 — Export an SBOM

# A KMS-encrypted bucket to receive the SBOM (Inspector service role must use the key)
aws s3 mb s3://northwind-sbom-$ACCT
aws inspector2 create-sbom-export \
  --report-format CYCLONE_DX_1_4 \
  --s3-destination "bucketName=northwind-sbom-$ACCT,keyPrefix=sbom,kmsKeyArn=arn:aws:kms:ap-south-1:$ACCT:key/abcd-ef01" \
  --resource-filter-criteria '{"ecrImageRepositoryName":[{"comparison":"EQUALS","value":"vuln-demo"}]}'
# { "reportId": "..." }   # poll get-sbom-export; the CycloneDX JSON lands in s3://.../sbom/

Step 8 — The core of the lab as Terraform

# Activate Inspector for this account (all four resource types)
resource "aws_inspector2_enabler" "this" {
  account_ids    = ["111122223333"]
  resource_types = ["EC2", "ECR", "LAMBDA", "LAMBDA_CODE"]
}

# Suppression rule: hide low/informational, keep the record
resource "aws_inspector2_filter" "suppress_low" {
  name        = "suppress-low-noise"
  action      = "SUPPRESS"
  description = "Accepted: low/informational triaged in batch"
  filter_criteria {
    severity {
      comparison = "EQUALS"
      value      = "LOW"
    }
    severity {
      comparison = "EQUALS"
      value      = "INFORMATIONAL"
    }
  }
}

# Org rollout (run in the delegated-admin account)
resource "aws_inspector2_delegated_admin_account" "this" {
  account_id = "444455556666"
}

resource "aws_inspector2_organization_configuration" "this" {
  auto_enable {
    ec2         = true
    ecr         = true
    lambda      = true
    lambda_code = true
  }
  depends_on = [aws_inspector2_delegated_admin_account.this]
}

# Route CRITICAL findings to SNS (severity is a STRING)
resource "aws_cloudwatch_event_rule" "insp_critical" {
  name = "insp-critical"
  event_pattern = jsonencode({
    source        = ["aws.inspector2"]
    "detail-type" = ["Inspector2 Finding"]
    detail        = { severity = ["CRITICAL"], status = ["ACTIVE"] }
  })
}

resource "aws_cloudwatch_event_target" "sns" {
  rule = aws_cloudwatch_event_rule.insp_critical.name
  arn  = aws_sns_topic.critical.arn
}

Step 9 — Teardown (stops the billing)

⚠️ Deactivating the resource types with disable is what halts Inspector charges. You can also disable a single type (e.g., drop LAMBDA_CODE to trim cost) while keeping the others running.

Common mistakes & troubleshooting

This is the section you open when a resource is not scanned — or a finding never reaches a human. The playbook first (symptom → fix), then the scan-status-reason reference, an error reference, a decision table, and prose on the nastiest failures.

Scan-status reason reference (the field you triage on)

list-coverage returns a scanStatus.reason for every resource — memorise the common ones:

Operation / API error reference

Decision table — read the symptom, name the cause

The three nastiest failures, in prose

“Enabled but unscanned” — the SSM trap on EC2. The most common and most frustrating Inspector failure is an account where Inspector is unmistakably on, the ECR and Lambda findings roll in, and yet EC2 shows almost nothing. The cause is nearly always that the instances are not Systems Manager managed instances — the SSM agent is present (it ships in the AMI) but the instance profile never got AmazonSSMManagedInstanceCore, or the instance has no network path to the SSM endpoints, so SSM never adopts it and Inspector has no inventory to scan. The tell is list-coverage returning UNMANAGED_EC2_INSTANCE or NO_INVENTORY, and the same instances missing from Fleet Manager. This is the same story as every other SSM-dependent feature (Session Manager, Patch Manager, Run Command), which is why “is it a managed instance?” should be your first EC2 question. The fast mitigation is to switch the account to EC2_HYBRID so agentless snapshot scanning covers the instances immediately, while you fix the instance profiles properly.

The string-vs-number severity trap (the reverse of GuardDuty). Teams that already run GuardDuty automation confidently copy their EventBridge pattern — and GuardDuty’s detail.severity is a number, so the pattern uses {"numeric": [">=", 7]}. In Inspector, detail.severity is a string ("CRITICAL", "HIGH", …), so that numeric pattern is syntactically valid, deploys cleanly, and matches nothing forever — your critical findings sail past a rule that looks correct. The fix is {"severity": ["CRITICAL"]} (uppercase, case-sensitive), and the discipline is the same either way: test-event-pattern every rule against a sample event before you trust it. Knowing that these two flagship security services encode severity differently is exactly the kind of detail that separates a working response plane from a silent one.

Trusting scan-on-push as continuous coverage. ECR’s “scan on push” toggle feels like coverage — the image is scanned, findings appear, everyone moves on. But on-push scanning fires once, at push, and never again; the CVE that matters most is usually disclosed weeks after the push, against a package already in the image. An image that passed its push scan in March can be riddled with critical CVEs by June while its status still reads “scanned.” Only enhanced continuous scanning re-evaluates existing images as new CVEs land — and even then, an image nobody pulls will age out of continuous monitoring after the rescanDuration (default 90 days) unless you pull it or set LIFETIME. Treat “the scan passed” as a photograph, not a promise: enable continuous scanning, pin production repos to LIFETIME, and let Inspector be the live feed that tells you when March’s clean image becomes June’s incident.

Best practices

Security notes

Inspector is a security control, so its own posture and the plane it drives must be least-privilege and tamper-resistant.

Key IAM actions to gate, and to whom:

Cost & sizing

Inspector has a 15-day free trial per account/region, useful for right-sizing before you commit. After that, you pay for what is scanned, and the drivers differ per resource type. The figures below are indicative (US/most regions, first pricing tier) and tier down with volume — always confirm with Cost Explorer and the Inspector usage totals for your account.

A worked example for a single mid-size account — 120 EC2 instances, 140 ECR repos with steady pushes, 300 Lambda functions with code scanning on:

Multiply by account count for an org — which is why scoping the expensive levers matters at scale. The levers, ranked by impact:

The one anti-pattern: do not turn off ECR continuous scanning to save the re-scan pennies. The continuous re-evaluation of existing images is the entire reason Inspector beats a point-in-time scanner — dropping it for a few rupees of re-scan charges is trading your only defence against the new-CVE-on-old-image case, which is exactly the case that becomes an incident.

Interview & exam questions

Q1. How is Amazon Inspector (v2) different from Inspector Classic? Classic used an assessment-template model — you installed the Inspector agent, defined targets and templates with rules packages, and ran assessments on a schedule. The modern Inspector (inspector2) is continuous and automated: you activate it per resource type and it auto-discovers and continuously scans EC2, ECR and Lambda, re-evaluating as new CVEs are published — no agent, no templates, no runs. (SCS-C02)

Q2. Which resources can Inspector scan, and what does each need? EC2 (via the SSM agent for deep OS + language packages, or agentless EBS snapshots), ECR container images (enhanced scanning, on-push + continuous), Lambda functions (dependency CVEs), and Lambda code (static source analysis). Each is activated independently and is regional. (SCS-C02)

Q3. An EC2 instance shows no Inspector findings although ECR and Lambda work. Why, most likely? The instance is not a Systems Manager managed instance — the SSM agent isn’t running, the instance profile lacks AmazonSSMManagedInstanceCore, or there’s no path to SSM endpoints. list-coverage shows UNMANAGED_EC2_INSTANCE. Fix the SSM prerequisites or switch to EC2_HYBRID for agentless snapshot scanning. (SOA-C02)

Q4. Explain the difference between ECR basic and enhanced scanning. Basic is native ECR: OS packages only, on push or manual, no continuous rescan, free. Enhanced is Amazon Inspector: OS and language packages, continuous rescanning as CVEs land, findings in Security Hub — billed per scan. (SCS-C02)

Q5. A CVE with CVSS 9.8 shows as Medium in Inspector. Is that a bug? No. A finding carries three numbers: the CVSS base score, the Inspector score (CVSS re-weighted by whether the resource is network-reachable and whether the CVE is actually exploited), and EPSS. The severity band follows the Inspector score. Read the score details and prioritise by exploitAvailable + epss + fixAvailable. (SCS-C02)

Q6. You copied your GuardDuty EventBridge rule and now Inspector criticals never fire. Why? GuardDuty’s detail.severity is a number; Inspector’s is a string. A {"numeric":[">=",9]} pattern never matches a string field. Use {"severity":["CRITICAL"]} (uppercase) on the default bus in the finding’s region, and test-event-pattern it. (SOA-C02)

Q7. What is the value of continuous scanning over scan-on-push? Scan-on-push fires once; the CVE that matters is usually disclosed later, against a package already in the image. Continuous scanning re-evaluates existing images/instances/functions as new CVEs are published, generating findings with no redeploy — and auto-closing them when you patch. (SCS-C02)

Q8. What does the ECR rescan duration control, and what’s the gotcha? ecrRescanDuration (LIFETIME / 180 / 90 / 30 / 14 days, default 90) is how long after the last push or pull an image stays under continuous rescan. An idle image ages out of continuous monitoring; a pull resets the clock. Set LIFETIME for production repos. (SCS-C02)

Q9. How do suppression rules work, and how do they differ from deleting a finding? A suppression rule is a filter with action SUPPRESS; matching findings move to status SUPPRESSED — retained (audit trail preserved) but excluded from the active list and Security Hub. You suppress accepted risks by specific criteria (a named CVE, a tag, a repo) with a documented justification. (SCS-C02)

Q10. How do you scan an image before it reaches a registry? Use CI/CD scanning: inspector-sbomgen generates an SBOM in the pipeline, and aws inspector-scan scan-sbom evaluates it against Inspector’s database, returning vulnerabilities you can fail the build on. AWS ships plugins for Jenkins, GitHub Actions, GitLab and CodeCatalyst. It’s billed per scan and needs no continuous activation. (DVA-C02 / SCS-C02)

Q11. How do you cover a 50-account org so new accounts are scanned automatically? Register a dedicated security account as the delegated administrator, set auto-activate per resource type, and — since auto-activate only covers new members — run associate-member for existing accounts. Do it in every region. (SAP-C02)

Q12. What are Inspector’s dominant cost drivers and how do you control them? Resource count: per EC2 instance, per ECR image scan (initial + rescans), per Lambda function (standard + the pricier code scanning). Control by scoping enhanced ECR (inclusion filters) and LAMBDA_CODE to key repos/accounts — never by disabling ECR continuous scanning, which is the whole point. (SOA-C02)

Quick check

1. Inspector’s ECR and Lambda findings appear, but EC2 shows nothing. What is the first command you run, and what reason confirms the most common cause?
2. Your critical-finding EventBridge rule never fires though the console shows criticals. What is the single most likely bug, given you also run GuardDuty?
3. Why can a CVSS 9.8 vulnerability legitimately appear as Medium severity in Inspector?
4. An image passed its scan-on-push in March. Why might it be full of critical CVEs in June with its status still “scanned,” and what setting prevents the blind spot?
5. You set auto-activate on the delegated admin, but an existing account still has no findings. What step did you miss?

Answers

1. aws inspector2 list-coverage filtered to AWS_EC2_INSTANCE; a scanStatus.reason of UNMANAGED_EC2_INSTANCE (or NO_INVENTORY) confirms the instance is not an SSM managed instance — attach AmazonSSMManagedInstanceCore, ensure the agent runs, or switch to EC2_HYBRID for agentless.
2. You matched detail.severity numerically (as GuardDuty requires), but Inspector’s severity is a string. Use {"severity":["CRITICAL"]} (uppercase) on the default bus in the region, and test-event-pattern it.
3. The finding’s severity band follows the Inspector score, which re-weights the CVSS base score by real network reachability and exploitability — an RCE on a port nothing can reach, with no known exploit, is scored down. Read the Inspector score details.
4. Scan-on-push fires once and never re-evaluates; a CVE disclosed after March is never matched. Enhanced continuous scanning (with rescanDuration=LIFETIME on prod repos) re-evaluates the existing image as new CVEs land.
5. Auto-activate covers only new members. You must run associate-member for existing accounts (and confirm relationshipStatus = ENABLED).

Glossary

Next steps

• Pair vulnerability detection with the container registry it scans in Amazon ECR Hands-On: Push, Pull, Scan & Lifecycle Container Images and deploy the scanned images with Amazon ECS on Fargate: Deploy Your First Service Behind an ALB (Hands-On).
• Aggregate Inspector alongside your other findings in Amazon Security Hub Hands-On: Findings, Standards & Compliance, and add behavioural detection with Amazon GuardDuty Hands-On: Threat Detection & Automated Response.
• Complement vulnerability findings with configuration compliance in AWS Config: Resource Inventory, Compliance Rules & Remediation Hands-On and the audit trail in AWS CloudTrail and Config: Audit and Compliance at Scale.
• Build the response plane in depth with Amazon EventBridge Hands-On: Event Buses, Rules, Patterns & Pipes and shift scanning left into CI/CD on AWS: CodePipeline + CodeBuild Hands-On.
• Roll detection out safely across accounts on the foundation from AWS Organizations & SCPs: Building Multi-Account Guardrails Step by Step.