Run Prowler against a real AWS account for the first time and you'll get somewhere between 300 and 1,000 findings. Every tutorial stops exactly here — at the moment the actual work begins. A scan isn't a result. A prioritised, executable plan is. (New to Prowler? Start with the full 2026 setup, then come back here.)
Here's the method I use to take a first scan down to a sequenced backlog an engineering team can start on without arguing about where to begin.
Step 1: Stop reading findings top to bottom
The default Prowler output is ordered by check, not by risk. Reading it linearly is how you spend a day on low-severity IAM hygiene while a world-open security group sits at line 412. Filter first.
# Fails only, high + critical, machine-readable
prowler aws --status FAIL --severity critical high --output-formats json-ocsf csvThat alone usually cuts 500 findings to 60–120. Now you're triaging risk, not reading a phone book.
Step 2: Use ThreatScore to sort what's left
Prowler 5.6 introduced ThreatScore — risk-weighted scoring across four areas: Identity & Access Management, Attack Surface, Forensic Readiness, and Encryption. It weights findings by exploitability and blast radius rather than treating every FAIL as equal.
Sort your remaining findings into those four buckets and a pattern appears almost every time:
| ThreatScore area | What usually dominates | Fix priority |
|---|---|---|
| Attack Surface | Public S3, open security groups, public RDS | First — internet-reachable = highest blast radius |
| IAM | Over-privileged roles, no MFA, stale keys | Second — the keys to everything |
| Encryption | Unencrypted volumes/buckets, weak TLS | Third — real, but lower immediate exploitability |
| Forensic Readiness | CloudTrail gaps, no flow logs | Fourth — you need it before an incident, not during |
Step 3: Group by fix, not by finding
Fifty "S3 bucket not encrypted" findings are one remediation applied fifty times, not fifty tasks. Collapse findings into remediation actions:
- One bucket-default-encryption policy → clears dozens of S3 findings.
- One SCP denying
0.0.0.0/0ingress on sensitive ports → clears the security-group sweep. - One account-wide EBS-encryption-by-default setting → clears the volume findings going forward.
A 120-finding scan often collapses to 15–20 actual remediations. That's the number you take to standup.
Step 4: Separate "fix" from "accept with justification"
Some findings are intentional: a public bucket serving a static site, a port open by design behind a WAF. Don't remediate them — document the exception. For a CPS 234 audit, a tracked, justified exception is a pass; an unexplained public bucket is a finding. Prowler supports allowlisting (mutelist) exactly so these don't reappear as noise every scan.
Step 5: Wire the plan to evidence
The output of triage isn't a spreadsheet that rots — it's:
- A sequenced remediation backlog (attack surface → IAM → encryption → forensics).
- A set of exceptions with written justification.
- A re-scan cadence so you can show the finding count trending down over time.
That last one matters for CPS 234: "testing control effectiveness" means showing gaps get closed, with the before/after to prove it.
The honest part
Triage is the skill the tutorials skip because it's harder to demo than prowler aws. But it's the entire difference between a team that drowns in a CSPM tool and one that uses it. If you've got a first scan you're staring at and don't know where to start, sorting it into a real plan — across Prowler and your conformance-pack failures — is the first deliverable of a readiness assessment.