Remediate Vulnerabilities with Amazon Inspector

What this lab covers

You enable Amazon Inspector against serverless functions and container images, review what it reports, and work through evaluating which findings genuinely warrant action.

The lab spends as much attention on triage as on scanning, because the output of any scanner is a list far longer than the available effort, and deciding what to do with it is the part that determines whether the tool improves anything.

It assumes no prior AWS experience and suits engineers responsible for keeping deployed workloads patched.

How cloud vulnerability scanning works

Inspector continuously scans supported resources by examining their software inventory against vulnerability databases. For container images it evaluates layers, and for functions it evaluates dependencies, without requiring an agent in either case.

Continuous is the important word. Scanning happens when a resource changes and when new vulnerability information is published, so a function deployed months ago produces new findings when a vulnerability in one of its dependencies is disclosed, without anyone rescanning.

Severity in the report is a property of the vulnerability rather than of your situation. Whether it matters depends on whether the vulnerable code path is reachable, whether the workload is exposed, and what the workload's identity permits if it were compromised, none of which the scanner knows.

How to detect this in your own environment

Route new findings above a severity threshold to alerting, and leave the rest in a queue. Reviewing the entire list periodically is how vulnerability management programs stall.

Track time to remediate rather than finding count. The number that predicts incidents is how long serious issues remain open, and it is the number most programs avoid measuring.

Watch for findings in images that are widely reused. One base image with a vulnerability propagates to everything built on it, so fixing the base is worth more than fixing dozens of derived images individually.

How to prevent it

Scan in the pipeline as well as in the registry, so vulnerable images are caught before deployment rather than found afterwards. Blocking at build is the only point where the fix is cheap.

Reduce what is in your images. Minimal base images carry fewer packages and therefore fewer findings, and much of a typical finding list comes from software the application never uses.

Rebuild regularly. Images built once and deployed for a year accumulate findings even when nothing changes, and a scheduled rebuild against updated bases removes many of them without any code change.

Real-world context

Exploitation of known vulnerabilities in internet-facing software remains a leading initial access vector, and the vulnerabilities used are frequently ones with patches available well before the intrusion.

The gap is rarely awareness. Organizations usually know about the vulnerability and have not deployed the fix, because the finding was one of thousands and nothing distinguished it from the rest. That is a prioritization failure rather than a detection failure.

The pattern maps to MITRE ATT&CK T1190 Exploit Public-Facing Application and T1195 Supply Chain Compromise.

Applying this at work

• Enable Inspector for your container images and functions, since agentless scanning removes the usual deployment obstacle.
• Prioritize by exposure and reachability rather than by severity alone, starting with internet-facing workloads.
• Add image scanning to your build pipeline so vulnerable images are blocked before deployment.
• Identify your most reused base images and fix those first, since the benefit propagates.
• Measure time to remediate for high severity findings on exposed workloads, and report that rather than total findings.

Frequently asked questions

Does Amazon Inspector need an agent?

Not for container images in ECR or for Lambda functions, which are scanned agentlessly by examining their software inventory. That removes the deployment obstacle that limits coverage for traditional scanners.

Why is severity a poor way to prioritize?

Because severity describes the vulnerability, not your exposure. A critical finding in a code path your application never executes matters less than a moderate one in an internet-facing component whose identity holds broad permissions.

How do I reduce the number of findings?

Use minimal base images and rebuild regularly. Much of a typical finding list comes from packages the application never uses, and images deployed for a long time accumulate findings even when the code has not changed.

Do I need my own AWS account to practice this?

No. The lab runs in a live AWS environment that Pwned Labs provisions for you, so there is nothing to set up and no risk to your own infrastructure.

Which certification covers this in depth?

The Amazon Cloud Red Team Professional (ACRTP) covers AWS attack and detection paths in full, including IAM abuse and privilege escalation, and is assessed hands-on in a live AWS account.