Cloud Security Audit — Flat Fee, 5 Business Days
Your AWS account has a way in. You just haven't found it yet.
A root account with no MFA. A security group that's had 22/tcp open to the world since the day someone was debugging something. An S3 bucket set to public during a demo and never locked back down. An IAM access key from a contractor who left eight months ago. None of it looks urgent — until it's how someone got in.
I build infrastructure for FinTech and Telecom companies by day — security review is part of that job, not a side skill. Every audit runs on Prowler, the open-source scanner used by security teams everywhere, with checks mapped to the CIS AWS Foundations Benchmark and AWS's own Foundational Security Best Practices. Then I do the part a scanner can't: read every finding in the context of your actual account and tell you what genuinely matters for a team your size — not a 200-line PDF of noise.
● No obligation — book the full audit only if the call says it's worth it.
Illustrative example — actual findings and severities depend on your account.
The deliverable
What the report actually looks like
Real report output, generated against a demo test project — not a real customer's data. Every finding ships with an actual fix, not just a description — click any thumbnail to see the full page. Why that matters →
Cover page
Severity breakdown at a glance.
Executive summary
Findings grouped by area.
Finding detail
Exact file and line per issue.
Terraform snippet
A real fix to paste in, not "review your config."
CLI command + compliance
The exact command, and which CIS/SOC 2 controls it affects.
CSV export
Flat and filterable, for your backlog.
CSV remediation column
Every row carries its own fix inline.
Why you can hand over access
Exact read-only IAM policy shared before you commit tap for detail
You see the precise AWS permissions being requested — before you grant anything. No surprises, no vague "full access" ask.
Powered by Prowler, mapped to CIS AWS Foundations tap for detail
Prowler is the same open-source scanner banks and security teams run internally — not a black-box script only I have access to.
Read-only — can't change anything on its own tap for detail
Only "Describe / List / Get" style calls run against your account. Nothing is ever created, changed, or deleted by the scan itself.
Money-back if nothing's found tap for detail
If the report comes back with nothing worth acting on, you get a full refund — the risk of a wasted engagement sits on me, not you.
AWS Certified Solutions Architect – Professional tap for detail
A professional-level AWS certification, independently verified by Credly — see the badge — not a self-reported claim.
One stop shop
Everywhere a vulnerability actually lives
Cloud misconfiguration is one entry point. Containers, OS images, and the source repo behind all of it are three more. Click a tile to see what's actually found on that surface and how it gets fixed.
Across those four surfaces that means cloud posture and compliance mapping, container and dependency CVEs, infrastructure-as-code, secrets, application code, and a software bill of materials. The high-stakes categories get two independent engines, cross-checked — no single scanner has complete coverage, so the results get reconciled into one finding instead of two half-answers.
AWS today, Azure/GCP on request — IAM, network, logging, and account-level config.
Plus a full pass across IAM, EC2, S3, RDS, VPC, KMS, Lambda, and logging/monitoring, checked against the CIS AWS Foundations Benchmark and AWS Foundational Security Best Practices.
Known, publicly-exploited vulnerabilities sitting in your container images, base OS layers, and dependencies — sometimes for months, because nobody's scanning. Scanned with Trivy, on AWS, Azure, GCP, or wherever you actually run. A few real ones worth knowing about:
A flaw in the NVIDIA Container Toolkit's OCI hook let a malicious container escape to full root on the host — a real risk on any shared GPU/AI cloud instance running customer-supplied containers.
A leaked file descriptor in runc let a container reach the host filesystem. Researchers estimated at least 80% of cloud environments were running an exposed version at disclosure.
One bundled logging library, one RCE, millions of affected images. Still turns up today in base images nobody's rebuilt since 2021.
How I actually fix it
A vulnerable package in production traces back to one repo and one Dockerfile — I fix it there, so it doesn't quietly reappear on the next build.
Most CVEs across a whole fleet of containers trace back to the same handful of base images. Patch the base image and every image built from it inherits the fix.
A patch that doesn't actually clear the finding — or quietly breaks something else — isn't done. Every remediation gets re-scanned before it's marked closed.
| Base image | Critical | High | Containers affected |
|---|---|---|---|
| node:18-slim | 3 | 5 | 12 |
| python:3.9 | 2 | 4 | 7 |
| alpine:3.14 (EOL) | 1 | 5 | 21 |
Same finding, traced across every container it touches — patch these 3 base images and all 40 affected containers inherit the fix. That's the "patch once" idea above, in practice.
A leaked API key doesn't stay leaked in one place. Deleting the file in a follow-up commit doesn't remove it from history — the old commit still has it, and anyone who cloned the repo before your fix already has a copy on their disk.
How I actually fix it
Scrubbing git history doesn't help if the exposed key is still valid — the correct order is rotate/revoke first, clean up second. Every remediation starts here.
A follow-up "remove secret" commit leaves the secret in every earlier commit. I rewrite history with git filter-repo (BFG Repo-Cleaner for very large repos), force-push, and get every collaborator to re-clone — the only way old copies stop existing.
GitHub push protection as the free always-on gate, a fast secrets scanner in pre-commit/CI for speed and custom patterns, and a scheduled deep sweep of full git history to catch what slips through both — a secret committed two years ago is still a live secret.
IaC gets the same treatment as secrets, because it lives in the same repo: Terraform,
CloudFormation, and Kubernetes manifests scanned by two independent policy engines, so a public S3
bucket or an open security group gets caught in the pull request, not after terraform apply.
Severity alone doesn't decide urgency — exposure and exploitability do. A medium-severity finding on an internet-facing service can matter more than a critical one on an isolated dev box. Once that's weighed, every finding — cloud, container, or repo — gets a clear deadline, not an open-ended backlog item:
Working toward a framework
Need this scoped to a specific standard instead of a general scan? The same Prowler engine maps every check to the framework you're actually working toward — I use that to scope the audit, close the gaps that matter for it, and track what's already covered so you have real evidence when the audit happens.
A misconfigured bucket doesn't send an alert. It just sits there until someone finds it — you, or someone else.
One weak link at any of these four points is enough — audit and remediation cover all of them.
Two ways to start
Starting from zero, or already know something's wrong?
Start with an audit
You haven't looked, or it's been a while. I scan the account, rank every finding by real-world risk, and hand you a report that says exactly what to fix first — and why.
Book the discovery call →You already have a report
A Prowler run, an AWS Security Hub export, a container image scan, an IaC scan, a GitHub secret-scanning alert, a pentest, a cyber-insurance questionnaire's gap list — whatever produced it, on AWS or another cloud, hand it over and I'll implement the fixes directly. No need to pay for a second audit.
Ask about remediation →The process
Three steps, five business days
01
Grant access, or share your report
A scoped, read-only IAM role — or if you already have Prowler/Security Hub/pentest output, just send that over instead.
02
Run the scan, or review the findings
Every check runs against CIS AWS Foundations and AWS's own best practices; existing reports get read line by line, not skimmed.
03
Get the prioritized roadmap
A report back within 5 business days — findings tagged critical/high/medium/low, with the "why it matters" for each one.
Why this, not a generic scan
What sets it apart
Industry-standard engines
The same battle-tested open-source engines enterprise security teams run — not a proprietary black box, and not a single tool's opinion: the high-stakes categories get two independent scanners, cross-checked.
Read-only, always
Only Describe/List/Get calls during the audit. Every fix ships as reviewed steps — nothing is auto-remediated without your sign-off.
Risk reversed
Full refund if the report finds nothing actionable. The risk sits on me, not you.
Pricing
One flat fee, no surprises
Security Audit
$350–$1,000
flat fee, quoted on the call
- Scope: production account(s), all enabled regions unless you narrow it — or a specific framework (CIS Controls, SOC 2, ISO 27001) if that's your target. Container/OS image scanning and source-repo secrets/IaC scanning available too.
- Deliverable: severity-ranked findings report (critical/high/medium/low) plus a 30-minute walkthrough call.
- Payment: 50% to start, 50% on delivery. Full refund if the report finds nothing actionable.
Not sure yet? Start with a 30-min discovery call — $50
Already have findings — my audit, a report you brought, or a framework you're closing gaps against? Ask about remediation — billed hourly ($50–$75/hr), scoped after you see the results.
Ready to see what's exposed?
Start with a 30-minute security review for $50 — no obligation, no long-term commitment.
Book the call →