Prowler audit + remediation

Prowler is the open-source CSPM tool everyone in cloud security has touched at some point. Running it against a real account, walking through every finding, and writing the Terraform that closes each one teaches you what "posture management" actually means in practice - and produces a write-up that demonstrates exactly the work a CSPM analyst does on day one.

What you'll have at the end

• A baseline Prowler scan of your own AWS account (HTML report committed to the repo).
• A categorized list of findings (critical / high / medium / low / informational) with brief notes on each.
• Terraform or AWS CLI snippets that remediate each finding worth fixing.
• A second Prowler scan after remediation, showing the delta.
• A short "what I learned" reflection - which findings were noise, which were real.

Prerequisites

• An AWS account with at least a few real resources (not a totally empty one - Prowler is most interesting when it has things to find).
• Python 3.9+ and pip.
• AWS CLI configured with read-only credentials (Prowler ships a least-privilege policy you can attach).
• Terraform if you want to script the fixes (recommended).

Step-by-step

1. Install Prowler

pip install prowler
prowler --version

2. Create read-only credentials for Prowler

Don't run Prowler with admin. Prowler needs two AWS managed policies plus one small custom policy the project maintains, all read-only. Attach them to a dedicated IAM role:

# The two managed policies Prowler documents as its baseline.
aws iam attach-role-policy --role-name prowler-readonly \
  --policy-arn arn:aws:iam::aws:policy/SecurityAudit
aws iam attach-role-policy --role-name prowler-readonly \
  --policy-arn arn:aws:iam::aws:policy/job-function/ViewOnlyAccess

# Plus the project's own additions, which cover services the two above miss.
curl -sO https://raw.githubusercontent.com/prowler-cloud/prowler/master/permissions/prowler-additions-policy.json
aws iam put-role-policy --role-name prowler-readonly \
  --policy-name prowler-additions \
  --policy-document file://prowler-additions-policy.json

SecurityAudit and ViewOnlyAccess are AWS-managed and grant no write actions. The additions policy is worth reading before you apply it: it is short, and knowing why a posture scanner needs each entry is exactly the kind of thing an interviewer asks about. The current requirements are in Prowler's AWS authentication docs.

Now give that role its own CLI profile, so no command in this project can accidentally run as your admin identity:

# In ~/.aws/config
[profile prowler-readonly]
role_arn = arn:aws:iam::<your-account-id>:role/prowler-readonly
source_profile = <your-normal-profile>
region = us-east-1

Confirm it works, and confirm it is the identity you think it is, before scanning:

aws sts get-caller-identity --profile prowler-readonly

3. Run the baseline scan

prowler aws --profile prowler-readonly --output-formats html json-ocsf

This produces a comprehensive scan against ~400 checks. Commit the HTML and JSON outputs to your repo as the before snapshot. Don't worry if the report is alarming on first run - that's the point.

4. Triage the findings

Open the HTML report. Group findings into four buckets:

• Real problems to fix - public S3 buckets, IAM users with no MFA, unused access keys, etc.
• Real but accepted - e.g., a region you're using and don't want to restrict.
• Noise - checks that don't apply to your setup.
• I don't understand this one - research and document.

Document each bucket in your README. The triage is the skill being demonstrated.

5. Remediate the real problems

For each "real problem to fix," write the Terraform (or AWS CLI command) that closes it. Examples:

• Block public access on S3 at the account level (aws_s3_account_public_access_block).
• Enable IMDSv2-only on EC2 launch templates.
• Enable default encryption on EBS volumes (aws_ebs_encryption_by_default).
• Set a strong password policy (aws_iam_account_password_policy).
• Enable GuardDuty (aws_guardduty_detector).

Apply the Terraform. Document each fix with a code snippet in the write-up.

6. Re-run Prowler

Run Prowler again with the same flags. Save the second HTML/JSON as the after snapshot. Commit a diff or summary of which findings flipped from FAIL to PASS.

7. Write the "what I learned" section

Most valuable section of the write-up. What surprised you? Which checks turned out to be more nuanced than they appeared? Did Prowler find anything you'd missed? Did it flag something that turned out to be a false positive?

8. (Optional) Schedule it

For bonus points: package the Prowler run into a GitHub Actions workflow that scans your account weekly and posts the diff as an issue. This is one of the most-asked interview question patterns: "how would you operate this at scale?"

What hiring managers look for

• You demonstrate triage skill, not just "ran the tool." Anyone can run a tool. Knowing what's noise vs. signal is the actual job.
• You wrote the fixes, not just listed them. Terraform diffs prove you closed the loop.
• Your before/after numbers are real. "Reduced FAIL findings from 84 to 12 in 4 hours" is the kind of bullet that lands on a resume.
• You used least-privilege credentials for Prowler - shows you practice what you preach.
• You can speak to which findings you'd treat as critical at a real org and which you'd accept with a documented exception.

Common mistakes

• Running Prowler with admin credentials. The point of CSPM is least privilege; live it.
• Listing every finding instead of triaging. A 1,200-line README is a liability, not an asset.
• Fixing things in the console without Terraforming. The Terraform is the reusable artifact.
• Not capturing the before/after delta. The compelling number is the change, not the absolute count.
• Treating every finding as critical. Demonstrating mature judgment about what to accept is part of the signal.

Where to publish

The full publishing playbook is on the portfolio hub page. The short version: a public GitHub repo with a thorough README is the strongest single signal; pair it with a LinkedIn post and (optionally) a 5-minute lightning talk at a CSOH Friday Zoom.