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.
Why you can hand over access
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.
Cloud Accounts
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.
Containers & OS Images
Known CVEs in base images, OS packages, and app dependencies.
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.
Source Repos
Leaked secrets, exposed credentials, git history, and IaC — GitHub & Bitbucket.
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, Gitleaks in pre-commit/CI for speed and custom patterns, and scheduled TruffleHog/Snyk Code sweeps (with verification) to catch what slips through both.
IaC gets the same treatment as secrets, because it lives in the same repo: Terraform,
CloudFormation, and Kubernetes manifests scanned with Checkov and Snyk IaC, so a public S3
bucket or an open security group gets caught in the pull request, not after terraform apply.
Compliance Frameworks
CIS, SOC 2, ISO 27001, NIST, PCI — scoped to whichever one you're working toward.
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.
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 Trivy/Snyk container scan, a Checkov/Snyk 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
Prowler for account/config checks, Trivy for container and OS image vulnerabilities, Checkov and Snyk for Infrastructure as Code — the same open-source scanners enterprise security teams run, not a proprietary black box.
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.
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.
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 →