Scan AWS workloads for vulnerabilities

Why this matters

A vulnerability scan you cannot act on is just a report. The goal on AWS is a list ranked by what an attacker could reach, plus a route from that list to a patched host or a rebuilt image. AWS spreads this across several services, so most of the job is assembly and triage.

Accounts grow. A test EC2 instance stays up, a Lambda function pulls a base image from last year, an ECS task runs an old agent. Each one carries a package inventory that drifts. Scanning finds the drift before a customer security review or an incident does.

Cost matters too. Scanning every volume daily adds storage and API charges, and reading the output takes time. A scoped scan that someone reviews beats a broad one that nobody opens.

Before you start

Sort three things before you switch anything on: an inventory of what to scan, the right permissions, and an owner for the findings. Start with the inventory. Use AWS Resource Explorer, AWS Config or your existing tags to list EC2 instances, ECS and EKS clusters, Lambda functions and ECR repositories per account and Region. A scanner only sees what it can reach, so gaps in the inventory become gaps in coverage.

Permissions come next. Amazon Inspector uses a service-linked role and needs IAM policies that let it read your resources. With AWS Organizations, enable trusted access and turn Inspector on from the management account so new accounts are covered without a ticket. For agent based EC2 scanning, the instance needs the Systems Manager agent and an instance profile that lets Systems Manager manage it. Agentless scanning of EBS volumes needs nothing installed on the host.

Write the scope down: which accounts, which Regions, which resource types, and what to do with container images older than a set age. Name the person who triages findings and the deadline for critical ones. A scan with no owner is a weekly email everyone mutes.

How to do it

The scan is the easy part. AWS gives you Amazon Inspector for EC2, ECR and Lambda, and you can add a scanner in your build pipeline for what you ship. The real work is wiring coverage, then deciding what to fix first.

Run discovery and scanning from a central security account. Inspector supports organization-wide enablement, so accounts that join later are covered by default. Push findings into AWS Security Hub so Inspector, GuardDuty and Config sit in one console, then route high severity findings through EventBridge to a queue your team watches.

Treat container images as their own track. Enhanced scanning for ECR rescans images when the vulnerability database changes, which catches old images sitting in a repository that nobody rebuilt. Add a scanner step in the pipeline so a bad base image fails the build rather than the audit.

Then close the loop. Every finding becomes a ticket with an owner and a deadline, and the fix is a patched AMI, a rebuilt image or a rule change. Suppress the noise that is not exploitable, with an expiry date, so the list stays short enough to read.

1. Inventory your workloads. List EC2 instances, ECS and EKS clusters, Lambda functions and ECR repositories per account and Region with AWS Resource Explorer or AWS Config. Tag each one with an application and an owner, because scan output is useless if nobody knows who should fix it.
2. Enable Inspector across the organization. Turn on Amazon Inspector from the AWS Organizations management account and set a delegated administrator in your security account. Accounts that join later inherit coverage instead of waiting for a manual click.
3. Pick scan types per resource. Use agent based scanning where you want package level detail on running EC2 hosts, and agentless EBS scanning where you cannot install anything. Turn on enhanced scanning for ECR and standard scanning for Lambda functions and layers.
4. Add build time scanning. Run a container and dependency scanner such as Trivy or Grype in CodeBuild or your CI job before an image reaches ECR. Fail the build on critical findings that have a fix available, and record a waiver when you accept the risk.
5. Route findings to one queue. Send Inspector findings to Security Hub and forward high and critical severities through EventBridge to a ticket queue. Keep the raw finding data so you can filter later by account, tag and CVE.
6. Triage by reachability. Rank findings by whether the resource is internet facing, whether the port is open, and whether the vulnerable package is actually loaded. A bad library in an unused layer is not the same as a vulnerable service listening on 0.0.0.0/0.
7. Fix by patching or rebuilding. Patch EC2 with Systems Manager Patch Manager runbooks, or replace the instance from a rebuilt AMI. Rebuild container images from a fresh base and redeploy. Avoid hand patching, since the next autoscaling event brings the old image back.
8. Suppress with an expiry date. Create Inspector suppression rules for accepted risks, each linked to a ticket and a date. Review the list monthly and let expired rules drop back into the findings.

How to check it worked

Confirm coverage before you trust any number. Inspector shows scanned and unscanned resources per account in its coverage view. Compare that against your inventory. Instances that were stopped when you enabled scanning often show as not covered until they start, and terminated instances drop out, which can make the picture look better than it is.

Test with a known bad package. Launch a throwaway EC2 instance from an older AMI, or push an image with an outdated base, and watch whether the finding appears and reaches your queue. If it does not, the usual causes are a missing permission, a Region you never enabled, or an EventBridge rule pointed at the wrong bus.

Follow one real finding end to end: ticket, fix, redeploy, rescan. Time each step. A finding that closes in the console while the same package is still live on the host means the scan ran against a stale snapshot or the wrong image tag.

Read the report as an outsider would. If it lists a hundred criticals with no context and no owner names, triage is not working yet.

Mistakes to avoid

Scanning one account and calling it done. Most AWS estates have several accounts, and the forgotten sandbox is where the unpatched host lives. Enable at the organization level and check coverage per account.

Ignoring what you no longer deploy. ECR repositories hold images from old branches and abandoned projects, and Inspector scans them like any other. Set lifecycle policies to expire old images, or you will spend the week triaging code that will never run.

Treating every finding as urgent. A severity score without context pushes teams to patch a test box while a production host waits. Order the work by internet exposure, open ports, data sensitivity and whether the package is actually loaded.

Suppressions with no expiry. A permanent suppression becomes invisible technical debt. Tie each one to a ticket, a written reason and a review date. If you want an outside read on the same evidence, Cloudverg's Cloud security review at $6,500/month covers a read-only review of up to 5 cloud accounts, including identity, exposure and logging checks with findings ranked by risk and the exact fix for each. It fits beside your scanning loop, not instead of it.

Frequently asked questions