Amazon Inspector
Continuous vulnerability management — finds known weaknesses (CVEs, software flaws, code-level bugs) in EC2, ECR container images, Lambda functions, and now source code repositories, BEFORE they're exploited. Where GuardDuty answers "is something bad happening," Inspector answers "is something exploitable sitting here."
Detective — vulnerability discovery
Infrastructure Protection
Shifts left into Governance/CI-CD
24h
Agentless EC2 rescan interval
0–10
Inspector risk score range
3
Code Security disciplines: SAST/SCA/IaC
How Inspector Actually Works
The Core Mechanism — Not Just "It Has a CVE List"
- Software inventory first — Inspector identifies exactly what packages, libraries, and OS components exist on a resource (via SSM agent metadata or agentless EBS-volume snapshot inspection), then matches that inventory against vulnerability databases (NVD, vendor advisories) to find known CVEs.
- Hybrid scanning model — for EC2, Inspector defaults to agent-based scanning (via the SSM Agent / new Inspector VM Scanner, May 2026) for managed instances, and automatically falls back to agentless scanning (EBS snapshot analysis, no agent, no IAM instance profile needed) for unmanaged or non-SSM instances. Agentless scans run roughly every 24 hours; agent-based is closer to continuous.
- Network reachability analysis — Inspector doesn't just ask "is this CVE present," it analyzes your actual security group / NACL / route table configuration to determine whether the vulnerable port/service is actually reachable from the internet. This context feeds directly into prioritization.
- Risk scoring, not just CVSS — the Inspector score combines the CVE's base CVSS score with network reachability, exploit availability (CISA KEV, EPSS), and threat intelligence (via a Recorded Future partnership) into a single 0–10 contextualized score — so a critical CVSS 9.8 vulnerability on a fully isolated private-subnet instance can rank lower than a CVSS 7 on an internet-facing one.
- Code Security (GA June 2025) extends this left into the SDLC: native GitHub/GitLab integration scans source code (SAST), third-party dependencies (SCA), and Infrastructure as Code templates as developers push commits or open pull requests — surfacing findings directly in the PR, not just in the Inspector console.
⚠️ The Recurring Exam Theme
Inspector questions almost always test one of three things: (1) can you distinguish Inspector (known vulnerabilities, pre-exploitation) from GuardDuty (active malicious behavior, in-progress), (2) do you know which resource types and scan triggers apply (EC2 continuous vs ECR on-push vs Lambda on-deploy vs code on-commit), and (3) can you reason about the risk score as more than raw CVSS — reachability and exploitability change the right prioritization answer.
Exam Domain Mapping
| Domain | Where Inspector Shows Up |
|---|
| Threat Detection & Incident Response | Less central here — Inspector is proactive, not behavioral; mostly shows up as a distractor against GuardDuty |
| Infrastructure Security | The centerpiece — EC2/ECR/Lambda scanning, network reachability, hybrid agent model, container security |
| Security Logging & Monitoring | Security Hub integration, EventBridge-triggered remediation workflows on new findings |
| Data Protection | SBOM generation/export for supply-chain visibility |
| Management & Security Governance | Organizations-wide enablement, shift-left code security in CI/CD as a governance control |
Decision Tree — Mental Model
Threat
Known CVEs, outdated packages, exploitable misconfigurations, vulnerable container images, insecure source code or IaC before deployment
↓
Security Goal
Find and prioritize known weaknesses before an attacker exploits them — across compute, containers, serverless, and code
↓
AWS Service
Amazon Inspector
EC2 (agent + agentless hybrid)
ECR container images
Lambda (standard + code scanning)
Code Security (SAST/SCA/IaC)
↓
Implementation
Enable via Organizations delegated administrator, org-wide. Opt into VM Scanner / agentless for hybrid coverage. Connect GitHub/GitLab for code scanning.
↓
Monitoring
Findings → Security Hub (aggregation). Findings → EventBridge (routing). Prioritize by Inspector risk score, not raw CVSS.
↓
Remediation
Patch via Systems Manager Patch Manager, rebuild/replace container image, update dependency version, fix source code before merge.
Final Summary
Must Memorize
- Inspector = known vulnerabilities (pre-exploitation), not behavior
- Hybrid EC2 scanning: agent-based (SSM/VM Scanner) + agentless fallback, ~24h agentless cadence
- Risk score = CVSS + network reachability + exploitability, not raw CVSS alone
- Resource coverage: EC2, ECR, Lambda (standard + code), and Code Security (SAST/SCA/IaC)
- Inspector Classic is deprecated — migrate to current Inspector
Must Understand
- Why network reachability changes prioritization, not just severity
- SBOM as a supply-chain governance artifact
- Shift-left: code scanning catches issues before deployment, not after
- The distinction triangle: Inspector (vulnerabilities) vs GuardDuty (behavior) vs Config (configuration compliance)
Can De-prioritize
- Exact dollar pricing per resource type
- Console UI navigation specifics
- Inspector Classic legacy assessment template mechanics
Exam appearance probability: HIGH
Scanning Capabilities
Each resource type has its own scan trigger and cadence — this mapping is the single most tested detail.
2.1 EC2 Scanning — Hybrid Agent/Agentless High exam relevance
Agent-basedVia SSM Agent / new Inspector VM Scanner (May 2026) — near-continuous
AgentlessEBS snapshot analysis, no agent or instance profile — rescans roughly every 24h
Default behaviorHybrid: agent-based for SSM-managed instances, automatic agentless fallback for unmanaged ones
- The May 2026 VM Scanner update brought agent-based detection coverage to parity with agentless (WordPress, Apache, Python packages, Ruby gems) while reducing CPU overhead.
- March 2026 added agentless Windows OS vulnerability scanning, plus consolidated Windows KB-based findings — one finding per Microsoft patch (KB article) instead of one per CVE it addresses, each surfacing the highest CVSS/EPSS score among the CVEs it covers.
- Exam trap: assuming agentless EC2 scanning is real-time — it isn't, it's roughly daily.
2.2 ECR Container Image Scanning High exam relevance
TriggerOn push to ECR, plus continuous rescanning as new CVEs are published
CoverageOS packages and language-level dependencies inside the image layers
- A previously "clean" image can generate a NEW finding days later if a CVE affecting one of its packages is published — Inspector continuously re-evaluates already-scanned images, not just at push time.
- "Container-to-workload mapping" lets you trace a vulnerable image back to the running ECS/EKS tasks actually using it.
2.3 Lambda Scanning — Standard vs Code Frequently misunderstood
Standard scanningScans function package dependencies for known vulnerable libraries
Code scanningStatic analysis of YOUR proprietary function code — injection flaws, data leaks, weak crypto, missing encryption
- These are two separate, separately-priced capabilities — standard scanning alone does NOT analyze your own business logic, only third-party packages.
- Triggered on function deployment/update.
2.4 Code Security — SAST / SCA / IaC High — newest capability
SASTStatic Application Security Testing — analyzes first-party source code for security bugs
SCASoftware Composition Analysis — evaluates third-party/open-source dependencies for known vulnerabilities
IaC scanningValidates Infrastructure as Code templates (e.g. CloudFormation/Terraform) for misconfigurations
- Native GitHub/GitLab integration: scans on push/pull request, in CI/CD pipelines, or on a schedule — findings surface both in the Inspector console (org-wide aggregated view) and directly inside the PR for fast developer feedback.
- Also performs near real-time malicious package detection (OpenSSF partnership) — catching dependency confusion / supply-chain attacks, not just known CVEs.
- This is the "shift security left" capability — fixes the problem before it ever reaches a deployed resource.
2.5 Network Reachability Analysis High exam relevance
What it doesAnalyzes SGs, NACLs, route tables, and subnet configuration to determine actual internet/internal reachability of a vulnerable port or service
- Two EC2 instances with the identical CVE can receive very different priority if one is internet-facing and the other is in a fully private subnet with no route to the internet.
- This is a core ingredient of the Inspector risk score — not a separate finding type.
2.6 Inspector Risk Score High-trap
InputsCVSS base score + network reachability + exploit availability (CISA KEV, EPSS) + Recorded Future threat intelligence
Range0–10, contextualized per-resource
- A high CVSS score does NOT automatically mean a high Inspector score — exposure and exploitability can move the priority significantly in either direction.
- "Prioritize remediation" questions almost always want you to reason using this composite score, not the raw CVE severity.
2.7 SBOM Export
PurposeCentrally generate and export a Software Bill of Materials for EC2, container images, and Lambda functions
- Supply-chain visibility / compliance artifact — answers "what software is actually running across my fleet," independent of whether it currently has a known CVE.
2.8 Suppression Rules
PurposeSuppress findings your organization has accepted as risk, based on defined criteria
- Same conceptual pattern as GuardDuty suppression — it hides the finding from view, it does not remove the underlying vulnerability or stop the resource from being scanned.
AWS Exam Thinking
Requirement → Keywords → Expected Answer → why every distractor fails.
Detect known CVEs / outdated software packages on EC2
CVEvulnerabilityoutdated package
Expected AnswerAmazon Inspector (EC2 scanning)
| Distractor | Why it's wrong |
|---|
GuardDuty | Detects active malicious behavior, not the presence of unpatched software |
AWS Config | Evaluates configuration compliance against rules, not CVE databases |
Trusted Advisor | General best-practice/cost checks, not deep CVE-level vulnerability scanning |
Prioritize remediation across hundreds of findings
prioritizemost critical firstexploitability
Expected AnswerInspector risk score (contextualized, not raw CVSS)
| Distractor | Why it's wrong |
|---|
| Sort by raw CVSS score only | Ignores network reachability and real-world exploitability — can misprioritize an unreachable critical CVE above an exposed moderate one |
| Sort by finding age | Irrelevant to actual risk |
Scan container images before they're deployed to production
container imageECRon push
Expected AnswerInspector ECR scanning
| Distractor | Why it's wrong |
|---|
| GuardDuty EKS Protection | Detects runtime/audit-log threats in a running cluster, not pre-deployment image vulnerabilities |
Manual docker scan | Not a managed, continuously re-evaluating AWS-native solution |
Catch security bugs in proprietary source code before merge
pull requestsource codeshift left
Expected AnswerInspector Code Security (SAST)
| Distractor | Why it's wrong |
|---|
| Inspector standard Lambda scanning | Only scans third-party package dependencies, not your own business logic |
| AWS Config | Doesn't analyze source code at all — evaluates deployed resource configuration |
Determine if a vulnerable service is actually exposed to the internet
internet exposurereachability
Expected AnswerInspector network reachability analysis
| Distractor | Why it's wrong |
|---|
| Manually reviewing security groups | Possible but doesn't scale and isn't automatically correlated with the vulnerability finding itself |
| VPC Flow Logs | Shows actual traffic that occurred, not a reachability assessment of potential exposure |
Security Controls Mapping & Integrations
4 — Controls Mapping
Detective
Continuous vulnerability discovery across EC2, ECR, Lambda — finding generation when known CVEs are matched against discovered software inventory
Governance (shift-left)
Code Security gates pull requests/CI pipelines with findings before code ever reaches production — a preventive-feeling control achieved through governance/process, not through blocking network traffic
Remediation (via integration, not native)
Inspector itself doesn't patch anything — remediation requires Systems Manager Patch Manager, rebuilding a container image, or bumping a dependency version
⚠️ Inspector is NOT behavioral and NOT preventive at the network layer
It tells you a weakness exists; it does not detect an attacker exploiting it (that's GuardDuty) and it does not block traffic (that's SGs/NACLs/WAF/Network Firewall).
5 — Integrations
Security Hub
WhatFindings flow automatically into Security Hub for aggregation
WhyCross-service correlation — Security Hub's exposure findings combine Inspector vulnerabilities with GuardDuty threats and CSPM misconfigurations
EventBridge
WhatNew/updated findings generate events
PatternFinding → rule → Lambda (open ticket, trigger patch workflow, notify team)
Organizations
WhatDelegated administrator model, org-wide enablement
WhyCentralized vulnerability visibility across every member account
ECR
WhatNative scan-on-push, plus continuous re-evaluation, with direct console notifications
GitHub / GitLab
WhatCode Security native integration — scans on push/PR, surfaces findings inline in the PR
WhyFast developer feedback without leaving the existing workflow
Systems Manager
WhatSSM Agent / Inspector VM Scanner powers agent-based EC2 scanning; Patch Manager is the typical remediation partner
Costs, Limits & Quotas
Pricing Model
BasePay-as-you-go, 15-day free trial
EC2 (agent-based)Per instance per month — generally the cheaper of the two EC2 modes
EC2 (agentless)Per instance per month — priced higher than agent-based
ECRPer image scanned, with ongoing rescan as new CVEs publish
Lambda standardPer function scanned per month
Lambda code scanningAdditional per-function charge on top of standard
Code SecurityPriced separately, generally per repository
Common Cost Mistakes
- Defaulting to agentless scanning everywhere when agent-based is available and cheaper
- Enabling Lambda code scanning broadly without considering it's a separate charge from standard scanning
- Forgetting ECR continues to bill for ongoing rescans of older images, not just the initial push
Cost Optimization
- Prefer agent-based scanning (SSM/VM Scanner) where instances are already SSM-managed
- Use suppression rules for accepted-risk findings to reduce noise (not cost — same caveat as GuardDuty)
- Scope Code Security to actively-developed repositories rather than all repos org-wide
Limits & Quotas
ScopeRegional service — new regions can lag behind general availability
Agentless rescan cadence~Every 24 hours
Code Security region availabilityLaunched in a limited set of regions, expanding over time
⚠️ Exam trap
Inspector Classic is deprecated/end-of-support — any question referencing "assessment templates" is describing the legacy service. The current Inspector uses automatic discovery, not manually configured assessment runs.