Prioritising Inspector Findings by Reachability

The situation

The platform security team’s inventory:

• 400 EC2 instances across prod (111111111111), staging (222222222222), and shared services (333333333333). Amazon Linux 2023 and Ubuntu 22.04. SSM Agent installed and managed on every host.
• 1,800 Lambda functions in Python, Node.js, Go, and some Java, deployed as zip packages and container images, using up to five layers each.
• 200 ECR container images across 35 repositories, built by CodeBuild on merge to main, deployed to ECS Fargate and Lambda.
• An AWS Organization with a delegated-administrator account (999999999999) the security team owns. Security Hub and GuardDuty are already enabled org-wide.

The brief: continuous CVE scanning across all three surfaces, prioritisation that matches how attackers work, evidence of coverage for the auditor, remediation timelines tied to severity visible org-wide, one deployment, not per-account.

What actually matters

Before mapping services to the ask, worth naming the deeper properties of an answer.

The first observation is that “CVE scanner” sounds like one kind of thing but the three surfaces in scope are materially different. An EC2 host’s vulnerabilities live in rpm or dpkg packages, running kernels, and application-layer language packages installed via pip/npm/maven. A Lambda function’s vulnerabilities live in its deployment package and attached layers. An ECR image’s vulnerabilities live in its filesystem. A single tool that scans all three, with the same UI and the same scoring model, is worth a lot more than three tools stitched together through a dashboard. The question is less “which scanner is best on EC2” and more “what can I enable once and cover all three surfaces with one finding format.”

Scoring that matches attacker behaviour is the property that distinguishes a useful prioritisation from CVSS-all-the-way-down. CVSS is a published severity, it reflects how bad the bug is in the abstract. Attackers don’t work in the abstract. They pick targets where an exploit already exists (because writing a new one is expensive) and where the vulnerable component is reachable from somewhere they sit (because nothing is exploitable if it’s not reachable). A scanner that reports raw CVSS leaves the triage work to the humans; a scanner that adjusts CVSS by exploit availability and network reachability gives the team a queue to burn down. Two CVE-8.6s on the same package, one on an internal-only worker and one on a public load balancer, have genuinely different urgency. The score should reflect that.

Coverage that is provable matters more than coverage that is comprehensive. Compliance asks “prove every host is in scope.” If the answer is “we installed an agent on most of them and hope for the best,” the auditor is unhappy. What we want is a first-class coverage API, every scanned resource, every excluded resource with a documented reason, every failed-to-scan resource with an error code the team can act on. That’s the difference between “we scan” and “we can prove we scan.”

Remediation timelines tied to severity are the workflow attribute. A finding is a starting point, not an outcome. The scanner has to expose firstObservedAt and severity in a way that lets an SLA like “Critical in 7 days, High in 14, Medium in 30” be computed and reported. Without that, the scanner produces a dashboard nobody scrolls past.

Finally, there’s operational fit at organisation scale. Three accounts today, four next quarter, ten in two years. Per-account enablement is toil that someone will eventually skip. The deployment that scales is one enablement at the organisation level, with auto-enrol for new accounts, and findings visible in the delegated administrator without cross-account IAM plumbing.

What we’ll filter on

1. EC2 coverage, running hosts, OS packages and application-layer packages, without deploying a bespoke scanner.
2. Lambda coverage, function code and attached layers across the major runtimes.
3. ECR coverage, on push and continuously as new CVE data lands.
4. Exploitability scoring. CVSS modified by exploit availability and, for EC2, network reachability.
5. Operational fit, one enablement at the organisation level, delegated to the security account.

The vulnerability-scanning landscape

Five places CVE scanning can live.

1. Amazon Inspector (v2). The current Inspector, rewritten from the legacy agent-and-template v1. Scans EC2, Lambda, and ECR as three surfaces under one service. EC2 is hybrid: hosts with a managed SSM Agent are inventoried continuously via SSM Inventory and matched against the Inspector CVE database; hosts without an agent are scanned agentless by EBS snapshot analysis. Lambda has standard scan (function package and layer dependencies against CVEs) and code scan (CodeGuru-based SAST for injection, hard-coded secrets, crypto misuse). ECR scans on push and continuously re-scans as new CVE data lands. Findings carry the Amazon Inspector score. CVSS modified by exploitability and, for EC2, network reachability. Integrates with Security Hub and EventBridge; supports delegated-administrator deployment via Organizations. Billed per resource per month.

2. AWS Systems Manager Patch Manager. Automates patching, not scanning. Reports compliance against a baseline, “is this instance up to date”, not “which CVEs affect this instance right now.” No ECR or Lambda coverage. Adjacent to Inspector for the remediation side, not the scanning side.

3. Third-party agent-based scanners. Qualys, Rapid7, Tenable, per-instance agents plus pipeline-integrated image scanning. Strong on EC2, thin on Lambda (the control plane doesn’t expose the package cleanly), and every account needs commercial licensing configured separately. Operational overhead to install, update, and scope an agent fleet of 400 is real even with SSM distribution.

4. Open-source tools (Trivy, Grype, Clair). Pipeline-stage scanners – trivy image in the build, grype for filesystem scans. Good as a CI gate; weak for continuous post-deployment scanning because you’d orchestrate the scanner yourself across 400 hosts. No managed Lambda scanning, no AWS-native reachability signal, no direct Security Hub integration.

5. AWS Security Hub. Not a scanner. Aggregates findings from scanners (Inspector, GuardDuty, Macie, Access Analyzer, third parties) into ASFF and runs posture checks against CIS / PCI / NIST. Essential as the consumer of Inspector findings across the organisation; never the producer.

Side by side

Option	EC2	Lambda	ECR	Exploitability scoring	Operational fit
Amazon Inspector v2	✓	✓	✓	✓	✓
Patch Manager	,	✗	✗	✗	✓
Third-party agents	✓	✗	✓	,	✗
OSS (Trivy / Grype / Clair)	,	✗	✓	✗	✗
Security Hub	✗	✗	✗	,	✓

Inspector v2 is the only row with all ticks. Patch Manager is an adjacent service for remediation, not the scan. Third-party agents solve EC2 and ECR but leave Lambda effectively uncovered. OSS tools are CI gates, not continuous post-deployment scanners. Security Hub is where findings go, not where they come from.

One enablement, three surfaces

Inspector v2, in depth

Enabling Inspector in an account switches on all three resource types by default; each can be disabled independently. In an Organization, the delegated administrator enables it once, and auto-enable enrols new accounts as they join.

EC2 hybrid. SSM Agent is the default. Inspector reads SSM Inventory to enumerate installed packages. OS packages (rpm, dpkg) and application-layer packages (Pip, Npm, Gem, Maven, Go, Nuget), and matches on the service side. No scanner runtime on the host. Hosts without a working agent get the EBS snapshot path: Inspector snapshots the root volume on a daily schedule, mounts it server-side, enumerates, scans, discards. Slower, less timely, limited to CVE scanning (no code scan).

Lambda. Standard scan reads the function’s code bundle (zip or container image) and attached layers, matches package versions against the CVE database, re-evaluates continuously as new CVEs land. Layers are scanned once and attributed to every function that uses them. Code scan (optional, extra fee) runs CodeGuru-based static analysis over the function’s own source for injection, hard-coded credentials, insecure API calls, and crypto misuse. Lambda@Edge is out of scope.

ECR. Scan on push enumerates every image as it arrives. Continuous scanning re-scans the newest images per a configurable policy when CVE data changes, a clean image from three months ago that now has a matching critical CVE surfaces a new finding without anyone touching the image. Enhanced scanning (Inspector) is distinct from ECR basic scanning (free, push-only, Clair-based, no continuous rescan, no AWS-native prioritisation).

The Inspector score

Inspector emits three inputs per finding and computes the score.

CVSS base score (v3.1 or v4 depending on the CVE). The 0-10 severity the CVE was published with. Reflects inherent severity; does not reflect your environment.

Exploit availability. Inspector looks up the CVE in exploit databases, including the CISA Known Exploited Vulnerabilities catalogue, and sets exploitAvailable to YES or NO. A known exploit in the wild carries different operational weight than no public proof-of-concept.

Network reachability (EC2 only). Inspector walks security groups, NACLs, route tables, VPC peering, internet and NAT gateways, and classifies whether the vulnerable network service is reachable from the internet, from the VPC, or not at all. A CVE in SSH on a host whose security group restricts 22/tcp to an internal CIDR scores lower than the same CVE on a web server behind an ALB accepting 0.0.0.0/0.

The score adjusts CVSS downward when exploitability is low and reachability is limited, upward when exploitability is high and the service is internet-reachable. A raw CVSS 8.6 with no exploit on an internal-only service might land around 5.8; the same CVE internet-reachable with a known exploit stays at 9.2. The order of triage changes, which is the point.

Severity maps to Critical / High / Medium / Low / Untriaged bands following the CVSS convention. Severity is what routing rules fire on; Inspector score is the tiebreaker within a band. Two things it explicitly doesn’t do: surface EPSS-style probabilistic scoring, and weight for business-criticality, tag-plus-suppression rules handle the latter.

One enablement for the whole organisation

From the Organizations management account, the security account is designated delegated administrator for Inspector. Every subsequent setting, which scan types are enabled, auto-enable for new accounts, suppression rules, export destinations, lives in that account and applies org-wide. With auto-enable on, any new member account is enrolled on join with the chosen scan types switched on. Findings in member accounts are visible directly from the delegated-administrator console without cross-account IAM; Security Hub integration propagates them as ASFF.

Evidence for the auditor

Compliance asks for two things: proof that every running workload is being scanned, and remediation timelines tied to severity.

Coverage. Inspector surfaces a coverage view per resource type. For EC2 it breaks down into SCANNING, UNSUPPORTED_OS, SSM_UNMANAGED, EC2_INSTANCE_STOPPED, STALE_INVENTORY, INTERNAL_ERROR, the set names exactly why an instance isn’t being scanned when it isn’t. For Lambda it names functions included and excluded. For ECR it names repositories with enhanced scanning on and the images inside the continuous-rescan window. Available via the ListCoverage API.

Remediation timelines. Findings carry firstObservedAt, lastObservedAt, and updatedAt timestamps. Slice by age × severity to measure against SLAs like “Critical in 7 days, High in 14, Medium in 30.”

SBOM export. Inspector generates a software bill of materials per scanned resource in CycloneDX or SPDX. When the next log4shell lands, the SBOM is what lets the team say “here is what we have, here is what we’ll check” before Inspector’s CVE database finishes matching.

Routing findings

EventBridge events. Inspector emits events on finding creation, update, and closure. A rule filtering detail.severity = CRITICAL lands in PagerDuty; a rule on HIGH creates a Jira ticket. Without EventBridge routing, Critical findings sit in the console until someone logs in.

Suppression rules. Not every finding is actionable. A CVSS 9.8 in a package used only by a build-time tool is noise for remediation. Suppression rules scope by resource tag, account, CVE ID, severity, or finding type, and apply organisation-wide when set at the delegated administrator. Suppressed findings remain visible and continue to export to Security Hub but don’t generate alerts. Compliance-safe when documented.

What’s worth remembering

1. Amazon Inspector v2 is the single managed service for continuous CVE scanning across EC2, Lambda, and ECR, one service, three surfaces, organisation-wide via delegated administrator.
2. EC2 scanning is hybrid: agent-based via SSM Agent + SSM Inventory is the default; agentless via EBS snapshot is the fallback on a daily cadence.
3. Lambda scanning has two levels, standard scan (package dependencies in code and layers across Python/Node/Java/Go/Ruby) and code scan (CodeGuru-based SAST for injection, hard-coded secrets, crypto misuse); Lambda@Edge is out of scope.
4. ECR enhanced scanning triggers on push and continuously re-scans; distinct from ECR basic scanning (push-only, no rescan).
5. The Amazon Inspector score modifies CVSS with exploit availability (including CISA KEV) and, for EC2, network reachability (internet, VPC, or no exposure), not raw CVSS.
6. Network reachability is EC2-specific; Lambda and ECR findings carry no reachability modifier.
7. Delegated administrator is the deployment pattern, auto-enable covers new accounts; the delegated admin sees every finding; suppression rules set once apply everywhere.
8. Coverage is auditable via ListCoverage and the console, which is the evidence compliance wants.
9. SBOM export in CycloneDX or SPDX is available per resource.
10. Findings flow to Security Hub as ASFF and to EventBridge as events; Security Hub is the aggregator, EventBridge is where severity-based paging is wired.
11. Suppression rules are organisation-wide exception lists with justification and review cadence, compliance-safe when documented.