Here’s a stat that should worry every SMB running on AWS, Azure, or GCP: cloud security posture management (CSPM) adoption jumped 60% last year — but the number of open security tickets barely moved. Companies bought the tool, got the dashboard, and kept the risk. Sound familiar? Your first scan probably returned hundreds of findings, and six months later most of them are still open.
Here’s the uncomfortable truth: detection was never your problem. Open-source tools like Prowler find misconfigurations faster than you can say “public S3 bucket.” The problem is that nobody owns the findings, nobody has a triage workflow, and remediation happens in a panic — usually after an auditor or a customer asks a pointed question. This article gives you a practical, SMB-sized workflow that actually closes tickets.
Why Security Findings Never Get Fixed
Misconfiguration is the leading cause of cloud breaches — and yet the average fix rate for detected findings stays low. The reasons are boring and universal:
- Alert fatigue. A first Prowler run against a mature AWS account easily returns 300–500 findings. When everything is “high severity,” nothing is.
- No ownership. Security findings live between DevOps, engineering, and whoever “does compliance.” Without an owner, they age in the dashboard.
- Fear of change. Locking down an S3 bucket or tightening an IAM policy feels risky when nobody knows what depends on it.
- Tickets, not fixes. Most CSPM tools generate Jira tickets. Generating a ticket is not a remediation pipeline.
The fix is to treat findings like incidents: triage by severity and blast radius, remediate the 80% that are safe to automate, and handle the rest deliberately. The rest of this article is that workflow, end to end.
Build the Detection Layer: Prowler, Free and Continuous
Prowler is the open-source standard for cloud security assessment — 400+ checks across AWS, Azure, and GCP, mapped to CIS, NIST, and SOC 2 frameworks. Install and run your first scan in minutes:
pipx install prowler
# One-off scan against an AWS profile, CSV + HTML report
prowler aws -M csv html -o reports/
# Focus on the checks that matter for SMBs: public buckets, encryption, open ports
prowler aws \
--checks s3_bucket_public_access s3_bucket_encryption_enabled \
--severity critical high \
-M csv -o reports/Run it nightly, not “when someone remembers.” A scheduled GitHub Actions job using Prowler’s container image with OIDC credentials is the leanest setup — one workflow file, no servers:
name: cloud-security-scan
on:
schedule:
- cron: "0 2 * * *" # nightly
workflow_dispatch:
jobs:
prowler:
runs-on: ubuntu-latest
permissions:
id-token: write
contents: read
steps:
- uses: actions/checkout@v4
- uses: aws-actions/configure-aws-credentials@v4
with:
role-to-assume: arn:aws:iam::123456789012:role/prowler-oidc
aws-region: eu-west-1
- run: |
docker run --rm \
-e AWS_ACCESS_KEY_ID -e AWS_SECRET_ACCESS_KEY -e AWS_SESSION_TOKEN \
-v $PWD/reports:/reports \
ghcr.io/prowler-cloud/prowler:latest aws -M csv -o /reportsShift-left too: run Checkov on every Terraform pull request so misconfigurations die before they reach the cloud, not after:
pipx install checkov
checkov -d terraform/ --framework terraform --soft-failTwo tools, zero license cost, continuous coverage. Detection is now the easy part — that was always true.
The Weekly Triage: Severity × Blast Radius, and the 80/20 Rule
Book 30 minutes a week. Pull the Prowler CSV, group findings by service, and sort them with one question: “If this is exploited, what happens — and who would notice?”
- Publicly exposed + sensitive data → fix today. Open buckets, unencrypted backups, exposed databases, wildcard IAM policies.
- Internal-only but wrong → fix this sprint. Missing encryption on internal volumes, lax password policies, unused credentials.
- Compliance-only → track, don’t block. Logging gaps, tagging violations. Keep a list for your next SOC 2 evidence pass.
Then remediate the fast 80% in code, not the console. Example — Prowler flags a public S3 bucket. Emergency stop first:
aws s3api put-public-access-block \
--bucket my-app-assets \
--public-access-block-configuration \
BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=trueThen make it permanent in Terraform so it can’t regress:
resource "aws_s3_bucket_public_access_block" "this" {
bucket = aws_s3_bucket.this.id
block_public_acls = true
block_public_policy = true
ignore_public_acls = true
restrict_public_buckets = true
}Rinse and repeat. In a month you’ll have closed the criticals, learned which findings are real, and built a repo of fixes that make the next finding a ten-minute change.
Prevention: Turn Findings into Guardrails
Fixing findings is good; making them impossible is better. Three guardrails, cheapest first:
1. Gate the pipeline. Fail the build when Checkov finds a critical issue in new code — the PR workflow from the detection section, with soft_fail: false:
- uses: bridgecrewio/checkov-action@v12
with:
directory: terraform/
framework: terraform
soft_fail: false # critical findings block the merge2. Enforce at the org level. One AWS Organizations Service Control Policy can block public S3 buckets and unencrypted volumes account-wide — a single file that outranks every developer’s copy-paste:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyPublicS3",
"Effect": "Deny",
"Action": [
"s3:PutBucketAcl",
"s3:PutBucketPolicy"
],
"Resource": "arn:aws:s3:::*",
"Condition": {
"StringEquals": {
"s3:x-amz-acl": "public-read"
}
}
}
]
}3. Track three numbers. Open critical findings (trending down), median time-to-remediation (under a week), and re-opened findings (near zero). That’s your whole security dashboard — and it’s exactly what auditors and customers ask about. Pair it with the policy-as-code discipline you already use for Kubernetes, and extend it with DevSecOps automation in CI/CD.
A 90-day plan that fits a lean team: week 1 — baseline scan, pick the owner (yes, one person owns it); weeks 2–6 — close all critical and high findings via code; weeks 7–10 — add the CI gate and one SCP; weeks 11–12 — automate the nightly report and start tracking your three numbers. That’s it. No new headcount, no enterprise CSPM license.
Your cloud is probably less secure than your last scan says — and far easier to fix than it looks once someone owns the workflow. Detection was never the problem; triage and guardrails are the whole game.
Want a second pair of eyes on your first scan, or help building the guardrails? We help SMBs turn security findings into working automation — book a free 30-minute consultation and bring your Prowler report.
English 
Español