Audit template
infrastructure
Audits how your system is built, shipped, and run — fragile, exposed, or unrecoverable, found and fixed.
Maps to: CIS · Well-Architected · DORA
How this audit works
Twelve specialist passes cover IaC quality and drift, cloud security and network exposure, IAM, secrets, containers, Kubernetes, CI/CD, high availability, backup/DR, observability, cost, and environment parity. Every finding cites a concrete artifact — IaC file:line, a manifest or pipeline stanza, a CIS or Well-Architected control — and the central question is always: what happens when this fails, and can you recover? P0–P1 findings are then attacked by independent skeptics before they survive into the report.
Use it when
Before a production launch
You are about to put a service on the public internet and need to know what is actually exposed. The audit traces public-exposure paths — security groups open to 0.0.0.0/0 on sensitive ports, public buckets and databases, missing TLS or edge protection — and reports each with the exact IaC line and the CIS control it violates.
After a near-miss outage
An incident made you ask whether you could actually rebuild from code and backups. The audit checks for single points of failure on tier-0 paths and whether backups are encrypted and restore-tested — not merely present — surfacing the unrecoverable states and missing DR runbooks before the next failure does.
Hardening the deploy pipeline
Your team ships fast and you suspect the gates are decoration. The audit verifies whether build, test, scan, and approval steps actually block, checks branch protection and pipeline credential scope, and flags injection paths like pull_request_target — pinpointing where a broken or unscanned build can reach prod.
What you get
A dimension-graded scorecard with a DORA snapshot, a blast-radius map, and a priority-sorted backlog of verified findings — each filed as a GitHub issue with evidence, a before/after fix, and a re-audit criterion.