Finding vulnerabilities
Lesson 3 of 6 in Securing Compute Workloads.
Two services look superficially similar here and answer completely different questions. Hold the distinction in one line: Amazon Inspector tells you what could be exploited; GuardDuty Runtime Monitoring tells you what is being exploited.
Inspector is continuous vulnerability management across three compute targets. EC2 instances are scanned for operating-system and programming-language package vulnerabilities. ECR container images are scanned on push and then re-scanned as new CVEs are published, so an image that was clean in March is flagged in April without anyone rebuilding anything. Lambda functions are scanned for vulnerable dependencies in the deployment package and layers, with an optional code-scanning mode that looks at the function's own code for injection and secret-handling flaws. Inspector discovers these resources automatically once activated, needs no scan schedule, and reports into Security Hub and EventBridge; in an organization you run it from a delegated administrator account.
Two Inspector details carry real exam weight. First, scan mode: in agent-based mode Inspector collects inventory through the SSM Agent, which gives continuous re-evaluation and deep inspection of application language packages; in hybrid mode it also scans instances with no agent agentlessly, by taking EBS snapshots and reading the inventory from them — which requires an EBS-backed instance with a supported filesystem (ext3, ext4, xfs) and re-scans roughly every 24 hours instead of continuously. Second, network reachability: Inspector evaluates whether a port on an instance is actually reachable from outside the VPC through the real path — security groups, NACLs, route tables, gateways, load balancers — and folds that into the finding's risk score. A critical CVE on an isolated subnet and the same CVE on an internet-facing instance are not the same problem, and the score says so.
| Amazon Inspector | GuardDuty Runtime Monitoring | |
|---|---|---|
Question answered | “What vulnerabilities exist, and how exploitable are they?” | “What is this workload doing right now that it should not be?” |
Evidence it reads | software inventory and versions against CVE data; the network path to the port | runtime telemetry from a security agent — process execution, file access, network and DNS activity inside the instance, container or task |
Covers | EC2 instances, ECR container images, Lambda functions (packages, and optionally code) | Amazon EKS, Amazon ECS including Fargate, and EC2 instances |
Finding looks like |
| a new binary executed, a reverse shell, a container escape attempt, crypto-mining DNS lookups |
Timing | before anything happens — a prediction about risk | while it happens — a detection of behaviour |
You respond by | patching, rebuilding the image, or removing the network path | isolating the workload, capturing evidence, and running the incident process |
Findings only matter if they are triaged honestly, so learn the three levers.
Prioritization. Inspector gives each finding a severity and an Inspector score, and surfaces the attributes that change your decision: whether a fix is available, whether an exploit is known, and — for instances — whether the vulnerable port is reachable. Pair that with the EPSS probability where Inspector provides it, and you get a queue ordered by real risk rather than by CVSS alphabetical panic. A high-severity CVE with no fix on an unreachable internal service is a planning item; a medium-severity CVE with a public exploit on an internet-facing instance is today's work.
Scan mode and coverage gaps. The fleet you did not scan is the fleet you do not know about, and the usual cause is a missing or broken SSM Agent. Inspector's coverage page is the thing to read in an exam scenario that says "some instances show no findings": either they are not SSM-managed and the account is in agent-based mode, or they are unsupported for agentless scanning. The fix is Systems Manager coverage, not more scanning.
Suppression rules. A suppression rule filters findings out of the active view by criteria — a CVE you have accepted, a finding type on a specific resource — without deleting them. It is a documented decision rather than a disappearance, and the exam prefers it to "ignore the alert" or "stop scanning that account".
GuardDuty Runtime Monitoring sits alongside all of this with its own agent. Enable it per protection plan, let GuardDuty manage the agent automatically where that is supported, and accept that its findings are incident input: a container that suddenly executes a shell, a process reaching a known command-and-control domain, an attempt to escape to the host. Inspector would never see those, because nothing about the package inventory changed.
ECR scanning: basic, enhanced, and the rescan window
Basic scanning is ECR’s own on-push check against an open-source CVE feed. Enhanced scanning is Amazon Inspector: it scans on push and continuously re-evaluates stored images as new CVEs appear, covering OS and language packages. That continuous part is the reason an image you have not touched in two months starts failing your pipeline gate — which is the correct behaviour. Pair it with tag immutability so the digest you scanned is the digest you deploy.
Lambda scanning has two layers
Standard Lambda scanning looks at the dependencies in the function package and its layers — the same CVE matching as everywhere else. Lambda code scanning additionally analyses the function’s own code for issues such as injection flaws, weak cryptography and hardcoded credentials. Both are activated per account; the second is the one to name when a question asks about vulnerabilities in the function code rather than in its libraries.
CIS benchmark scans
Beyond CVEs, Inspector can run CIS benchmark assessments against EC2 instances on demand or on a schedule, targeting instances by tag and reporting per-check pass/fail. It needs SSM-managed instances. This is the service to reach for when the requirement is "demonstrate the operating system meets a configuration benchmark" rather than "find vulnerable packages" — and it is a useful pairing with a golden image whose components applied that benchmark in the first place.
Where the findings go
Inspector and GuardDuty findings both flow to AWS Security Hub for aggregation and to EventBridge for automation, which is how a critical, exploitable, internet-reachable finding becomes a ticket, a patch run, or an isolation action without a human in the loop. In an organization, designate a delegated administrator so coverage and findings are visible centrally instead of per account.
Key terms: Amazon Inspector, Inspector scan mode (agent-based / hybrid), Inspector network reachability finding, GuardDuty Runtime Monitoring
Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.