In March, a fintech client called us at 2 AM because an attacker had pulled 14GB of customer records from an S3 bucket that nobody on their team remembered creating. The bucket had been spun up by a contractor for a one-day test, tagged nothing, and inherited a permissive IAM policy. It sat exposed for 47 days before being found by a scraper. Their last vulnerability scan? Quarterly. Their cloud asset inventory? A spreadsheet.
This is the failure mode that automated vulnerability scanning for cloud resources exists to prevent. Point-in-time scans worked when servers lived for years. They do not work when an EC2 instance has a median lifespan of 39 hours and a Lambda function lives for 800 milliseconds.
The goal of this audit checklist is simple. By the end, you should know whether your cloud scanning program would have caught that bucket on day one, or whether you are running the same gamble that client was.
The Audit Goal: Continuous Coverage, Not Quarterly Snapshots
Traditional vulnerability management assumes a static asset list. Cloud breaks that assumption. New resources appear from Terraform pipelines, autoscaling groups, and CI/CD runners every few minutes. Decommissioned resources need to leave your scanner queue or you drown in dead alerts.
Each checkpoint below has a clear pass/fail criterion. If you fail three or more, your program is reactive, not proactive — and MITRE ATT&CK techniques like T1530 (Data from Cloud Storage) and T1078.004 (Valid Cloud Accounts) will hit you before you see them coming.
Checkpoint 1: Asset Discovery Is Tied to Scanning
If your scanner does not know an asset exists, it cannot scan it. Sounds obvious. Most environments fail this anyway.
Pull asset inventories from the cloud-native source of truth — AWS Config, Azure Resource Graph, or GCP Asset Inventory — and feed them directly into your scanner. Do not rely on tags. Tags get forgotten. Resource Graph does not.
# Pull every public-facing resource Azure knows about
# Catches assets that bypassed the tagging policy
az graph query -q "Resources | where properties.publicNetworkAccess == 'Enabled'"Pass: New resources appear in your scanner within 15 minutes of creation. Fail: You discover assets via a quarterly spreadsheet review.
Checkpoint 2: You Are Running a Multi-Cloud Posture Tool
If your stack touches more than one cloud, a single-cloud scanner leaves gaps. We pick one of three tools depending on the engagement:
- ScoutSuite — multi-cloud auditing against CIS Benchmarks. Produces a static HTML report you can hand to auditors. Repo:
github.com/nccgroup/ScoutSuite. - CloudSploit — install with
npm install -g cloudsploit, runcloudsploit --config config.js --cloud aws. Good for CI/CD integration because the output parses cleanly. - cloud-enum — when we are on the offensive side of an engagement and need to enumerate a target’s exposed resources across AWS, Azure, and GCP from keyword matches.
Pass: Every cloud account, in every provider, is scanned by the same tool with the same baseline. Fail: AWS has CloudSploit, Azure has Defender, GCP has nothing, and the findings live in three different dashboards nobody opens.
Checkpoint 3: Cloud-Native Scanners Are Enabled
The provider-native scanners cost less than people think and catch things third-party tools miss because they have privileged read access. Turn them on:
- Amazon Inspector for EC2, ECR, and Lambda
- Microsoft Defender for Cloud (formerly Azure Security Center)
- Google Cloud Security Command Center
Forward the findings to your central SIEM. Do not let them rot in three separate provider consoles.
Pass: Native scanners are enabled in every subscription and project, with findings routed to one queue. Fail: Native scanners are enabled in “prod” but not “dev” because someone decided dev does not matter. Dev is where the contractors create the misconfigured buckets.
Checkpoint 4: Scanning Includes IaC and Container Layers
VM-based scanning misses the configuration weaknesses that live in Terraform files, Kubernetes manifests, and container base images. We had a manufacturing client whose external pen test came back clean for six months running. Then a fresh deployment shipped with a container image that had a known CVE in its base layer, and the EDR agent never got installed because the image was too minimal.
Wire scanning into the layers where the problem starts:
# Scan a container image before it reaches the registry
# Catches CVEs in base layers before deployment
trivy image --severity HIGH,CRITICAL myorg/api:latest
# Scan Terraform for misconfigurations pre-merge
# Catches public S3 buckets and over-permissive IAM before apply
checkov -d ./terraform --framework terraformFor Kubernetes workloads, also scan manifests for missing security contexts, privileged containers, and exposed services. The Red Hat documentation on OpenSCAP is worth reading if you need formal compliance reports out of the process.
Pass: IaC, container images, and Kubernetes manifests are scanned in CI before merge. Fail: You only scan running workloads.
Checkpoint 5: Prioritization Goes Beyond CVSS
This is the checkpoint most programs flunk. CVSS 9.8 on an internal-only resource with no sensitive data matters less than CVSS 6.5 on an internet-facing API gateway holding PII. Treating them the same is how teams burn out on a backlog of 40,000 “critical” findings and stop reading the report.
Contextual prioritization should weigh:
- Internet exposure (is the resource reachable from outside?)
- Privilege level of the identity attached (IAM role with
*:*versus a scoped read role) - Active exploitation in the wild (CISA KEV catalog membership)
- Compensating controls (WAF in front, network segmentation, etc.)
- Data sensitivity tags
This is where I am going to be opinionated. If your scanner output is a CSV sorted by CVSS, it is not a prioritization system. It is a complaint generator. The good tools — Tenable.io, Wiz, Prisma Cloud — do contextual scoring. Use them, or build the enrichment layer yourself with the cloud APIs and a Python pipeline.
Checkpoint 6: Findings Trigger Action, Not Just Tickets
A finding that creates a Jira ticket and sits in a backlog is the same as no finding at all. We worked with a client whose ticket queue had a CVE-2021-44228 (Log4Shell) entry from January 2022. Still open in 2024. Three internet-facing services were still vulnerable. They got hit.
Build the automation that closes the loop:
# Auto-remediate public S3 buckets flagged by ScoutSuite
# Blocks public access on any bucket tagged data-class:internal
aws s3api put-public-access-block \
--bucket $BUCKET \
--public-access-block-configuration \
"BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true"For workloads that cannot be auto-remediated, route findings to the team that owns the resource — not to a generic security mailbox. Tag-based ownership in vSphere, AWS, or Azure should map to a real on-call rotation.
Checkpoint 7: Decommissioned Assets Leave the Pipeline
This is the boring one nobody audits. Your scanner is sending alerts on a Lambda function that was deleted three weeks ago. Your team has stopped reading the alerts because half of them are ghosts. Real findings get lost in the noise.
Pipe the AWS Config / Azure Resource Graph deletion events back into your scanner config. Dead asset, dead alert.
Pass: Decommissioned resources stop generating findings within one scan cycle. Fail: You have alerts on resources that no longer exist.
Caveats and What This Checklist Will Not Catch
Automated scanning is a floor, not a ceiling. It catches known CVEs and misconfigurations against published baselines. It does not catch:
- Business logic flaws in your application code
- Identity attacks against federated Active Directory integrations
- Supply chain compromises in dependencies the scanner has not catalogued yet
- Insider abuse of legitimate permissions
If you check every box above and stop there, you have built a strong floor — but a determined attacker who reads the same CIS Benchmarks you do will find the gap. Pen testing, threat hunting, and red team engagements are what cover the gap. We see the pattern repeatedly: clients with mature scanning programs still benefit from a quarterly adversary simulation because the scanner cannot model intent.
If you are sizing a cloud security program and want help wiring this checklist into your environment, reach out to our team. We do the integration work, not just the assessment.
Related Reading
If you are working through cloud security and operational scaling, two of our prior write-ups pair well with this checklist: Azure Scalability vs Elasticity for capacity planning context, and Intune Compliance Policies for the endpoint side of the same posture problem.
The Takeaway
Run this seven-checkpoint audit against your environment this week. Score it honestly. Anything below five passes means a contractor’s forgotten S3 bucket is your next incident. The fix is not buying another tool — it is wiring the tools you already have into a continuous loop that sees every asset, scores by context, and closes findings on a clock you control.
