Cloud Security Automation: Prowler, Checkov and AWS Config

Cloud Security Automation: Automate Audits, Scanning and Security Pipelines #

A manual cloud audit captures a moment. In an environment where IAM, S3, and Lambda are changed daily via CI/CD, a one-time audit is already out of date the next week. This guide covers how to automate scans—both offensive (recurring recon on a target) and defensive (continuous audit integrated into the pipeline).

When to use it: Recurring scoped cloud pentesting, internal DevSecOps, continuous hardening on AWS environments. What it covers: ScoutSuite/Prowler scheduling, IaC scanning (Terraform/CloudFormation) in CI/CD, repeatable enumeration scripts. What it doesn't cover: IAM/S3 exploitation details—for that, see our AWS pentesting guide (IAM, S3, EC2).

What is Cloud Security Automation? #

Cloud security automation is the automation of security controls, audits, and misconfiguration detection in cloud environments, rather than relying solely on periodic manual checks. On AWS, this means continuously monitoring IAM, S3, EC2, and infrastructure-as-code, so that risky configurations are detected within hours or minutes rather than at the next scheduled audit.

Why Automate Cloud Security? #

An S3 bucket accidentally made public during a 3 a.m. deployment remains exposed until someone audits it again. The difference between a good audit and a one-time audit is automation.

Real-world cases where automation intercepts and a manual monthly audit does not:

• a merge introduces an IAM policy with "Action": "*" mistakenly in production for days before the next scheduled audit
• An S3 bucket becomes public after a deployment that overrides the ACL
• a hardcoded secret ends up in a Terraform file and gets committed
• the environment dev has IMDSv1 active, prod no — silent drift that no one notices until you confront it

Best Tools for Cloud Security Automation #

How to Automate an AWS Audit #

Phase 0 — Native Tools Before External Tooling #

Native-first approach: AWS Config continuously evaluates the health of your resources with managed rules, without installing anything:

aws configservice put-config-rule --config-rule file://s3-public-read-rule.json

Use this for native compliance without external dependencies. Switch to ScoutSuite/Prowler when you need readable cross-service reporting or compliance mapping (CIS, PCI-DSS).

Phase 1 — ScoutSuite Scheduling #

pip install scoutsuite --break-system-packages
scout aws --profile default --report-dir /var/reports/scoutsuite-$(date +%F)

Automate with cron to get a daily snapshot:

# crontab -e
0 3 * * * /usr/local/bin/scout aws --profile default --report-dir /var/reports/scoutsuite-$(date +\%F) >> /var/log/scoutsuite.log 2>&1

Diff between two scans — what's changed since yesterday. ScoutSuite saves the results in JSON. A targeted diff tells you what's changed without rereading the entire report:

diff <(jq -S . /var/reports/scoutsuite-2026-07-05/scoutsuite_results.json) \
     <(jq -S . /var/reports/scoutsuite-2026-07-06/scoutsuite_results.json) > drift.diff

This is the concept of drift detection : you don't care about the absolute state every time, you care about what has changed since yesterday.

Phase 2 — Prowler in CI/CD Pipeline #

pip install prowler --break-system-packages
prowler aws --output-formats json-ocsf --output-directory ./prowler-report

Example of a step in a GitHub Actions pipeline, to block the merge if critical findings arise:

- name: Prowler Cloud Security Scan
  run: |
    pip install prowler
    prowler aws --severity critical high --output-formats json-ocsf --output-directory ./report
    CRITICAL=$(jq '[.[] | select(.status_code=="FAIL")] | length' ./report/*.ocsf.json)
    if [ "$CRITICAL" -gt 0 ]; then
      echo "Trovati $CRITICAL finding critici, blocco il deploy"
      exit 1
    fi

This turns a periodic audit into an automatic gate : no deployment with known critical misconfigurations goes into production.

Phase 3 — IaC Scan Before Deployment (Shift-Left) #

Finding misconfiguration in Terraform code before it becomes a real bucket is much cheaper than finding it afterward with ScoutSuite.

pip install checkov --break-system-packages
checkov -d ./terraform --framework terraform

# tfsec, alternativa focalizzata solo su Terraform
tfsec ./terraform

Example of a rule that Checkov catches before deploying:

resource "aws_s3_bucket" "data" {
  bucket = "azienda-data-prod"
  acl    = "public-read"  # <- Checkov lo segnala come CKV_AWS_20
}

Pipeline integration, same gate principle as seen for Prowler:

- name: IaC Security Scan
  run: |
    pip install checkov
    checkov -d ./terraform --framework terraform --compact --quiet

Phase 4 — Recurring Enumeration Script (Offensive Side) #

For a multi-day scoped engagement, a script that repeats the basic enumeration and only reports differences is more efficient than manually relaunching ScoutSuite each time.

#!/bin/bash
# recon-diff.sh — enumerazione IAM/S3 ripetibile, evidenzia solo cosa cambia
OUTDIR="./recon-$(date +%F)"
mkdir -p "$OUTDIR"

aws iam list-users > "$OUTDIR/users.json"
aws iam list-roles > "$OUTDIR/roles.json"
aws s3 ls > "$OUTDIR/buckets.txt"

PREV=$(ls -d ./recon-* 2>/dev/null | sort | tail -2 | head -1)
if [ -n "$PREV" ] && [ "$PREV" != "$OUTDIR" ]; then
  echo "--- Nuovi utenti IAM ---"
  diff "$PREV/users.json" "$OUTDIR/users.json"
  echo "--- Nuovi bucket S3 ---"
  diff "$PREV/buckets.txt" "$OUTDIR/buckets.txt"
fi

Useful in a long red team engagement: a new bucket or IAM user appearing during testing is often a sign of a change in progress by the blue team, or a new surface to test.

Phase 5 — EventBridge for Real-Time Detection #

CloudWatch Events / EventBridge reacts in real time to specific events (e.g. PutBucketAcl with public ACL) without waiting for periodic scanning:

aws events put-rule --name detect-public-s3 \
  --event-pattern '{"source":["aws.s3"],"detail-type":["AWS API Call via CloudTrail"],"detail":{"eventName":["PutBucketAcl"]}}'

This intercepts the event at the exact moment it happens, instead of waiting for the next scheduled scan — it's the difference between detecting a problem after 24 hours or after 24 seconds.

Recon Without Noise #

Automation also generates logs. A full Prowler/ScoutSuite scan every night across all services and regions results in hundreds of calls. Describe*/List* concentrated within minutes — a pattern potentially recognizable by GuardDuty if launched from an unexpected account.

AWS Config and EventBridge are native services and integrate naturally into your account's normal monitoring architecture — but being native doesn't automatically make them “invisible”: the activities they generate should also be considered in your overall logging and detection model, especially if they're configured or queried in ways that aren't typical for everyday use.

If your testing requires stealth: Run Prowler/ScoutSuite scans from the same role and IP range as your daily activity, or space them out throughout the day rather than in a single, concentrated window.

Cloud Security Automation vs Manual Pentest #

Automation quickly identifies known risky configurations, but it is not a substitute for penetration testing: it alone does not determine the actual attack path or the blast radius of a compromise—that still requires the human analysis discussed in the AWS pentesting guide.

What to Use When #

Common Mistakes #

Quick Hardening (Defensive Side) #

• AWS Config active across all regions with core managed rules (S3 public, MFA root, IMDSv2)
• Gate CI/CD on Checkov/tfsec — No critically misconfigured Terraforms make it to production
• EventBridge on high-risk events (PutBucketAcl, AttachUserPolicy, CreateAccessKey) for near-real-time detection
• Daily drift detection — an automatic diff beats a manual reread of the report every time
• Least privilege on the scanning role itself — the audit tool must not have more permissions than necessary to read, never write

Operational Workflow #

Codice Terraform (pre-deploy)
      ↓
Checkov / tfsec (shift-left, gate CI/CD)
      ↓
Deploy in produzione
      ↓
AWS Config + EventBridge (detection continua)
      ↓
ScoutSuite / Prowler (scan schedulato, drift detection)
      ↓
Report differenziale (solo cosa è cambiato)
      ↓
Remediation o escalation al team

MITRE ATT&CK (Cloud Matrix) #

Full Matrix: MITER ATT&CK Cloud

Operational Checklist #

[ ] AWS Config attivo con regole gestite base
[ ] ScoutSuite/Prowler schedulati (cron o pipeline)
[ ] Diff automatico tra scan consecutivi (drift detection)
[ ] Checkov/tfsec come gate pre-deploy su IaC
[ ] EventBridge su eventi IAM/S3 ad alto rischio
[ ] Script di enumerazione ricorrente per engagement lunghi
[ ] Verifica permessi minimi sul ruolo usato per lo scanning

FAQ #

Does automating audits replace manual pentesting? No. Automation covers what you already know to look for (misconfiguration notes). Manual pentesting finds environment-specific escalation paths that no scanner knows in advance.

What are the best tools for cloud security automation? On AWS: AWS Config for native continuous compliance, ScoutSuite and Prowler for cross-service auditing, Checkov and tfsec for infrastructure-as-code scanning, EventBridge for real-time detection.

How do I automate an AWS security audit? Start with AWS Config for continuous compliance, add scheduled ScoutSuite or Prowler (cron or pipeline) for periodic reporting, and a diff between consecutive scans for drift detection.

How do I integrate cloud security into CI/CD? With a gate: Checkov/tfsec on the Terraform code before deployment, Prowler on the live environment after deployment, both capable of derailing the pipeline if critical findings emerge.

Is Checkov or tfsec better for IaC scanning? Checkov covers multiple frameworks (Terraform, CloudFormation, Kubernetes, Dockerfile) with a single tool. tfsec is lighter and focuses solely on Terraform. For a mixed environment, Checkov is better.

How often should ScoutSuite/Prowler be scheduled? Daily is the standard for environments that change frequently via CI/CD. Weekly may suffice for stable environments, but a critical event (public bucket) should be intercepted in real time with EventBridge, not waiting for the next scan.

How do I automatically detect cloud security drift? Comparing away diff/jq two consecutive ScoutSuite or Prowler scans, instead of rereading the entire report each time — see the example in Phase 1.

Is AWS Config enough on its own, without ScoutSuite/Prowler? For ongoing compliance, yes. For a readable cross-service report with customer-ready CIS/PCI-DSS mapping, Prowler is more practical.

Official documentation: AWS Config . For basic IAM/S3/EC2 enumeration and the SSRF/IMDS portion, see our AWS pentest guide, Penetration Testing Tool on HackIta , and HTTP and HTTPS on HackIta.