auto-audit-security

/auto-audit-security

An adversarial security review of this codebase, plus an honest compliance-readiness assessment — findings first, fixes only when you approve them.

The boundary, stated once and never blurred: a code audit produces INPUT EVIDENCE to a compliance program. It never produces the compliance artifact. SOC 2 is an attestation engagement performed under SSAE 18 by an independent licensed CPA firm; ISO 27001 is certified by an accredited body. What this skill produces is a readiness assessment: which technical controls are evidenced in the code, which are missing, and what an auditor will ask for that no repository can answer.

Two facts worth getting right, because vendors routinely get them wrong:

• The Trust Services Criteria comprise 61 criteria, of which 18 are the privacy category. Higher counts in circulation (64, 80+) come from counting points of focus as criteria — they are explicitly not criteria.
• A SOC 2 report is restricted-use. SOC 3 is the general-use report. If the goal is something publishable on a marketing site, that is SOC 3, and confusing the two misdirects the whole effort.

Everything this skill generates is IPE — information produced by the entity. A service auditor will test its completeness and accuracy before relying on it, so every artifact must record how it was produced, over what population, and at what time.

Step 1 — Scope And Authorization

Establish before running anything:

1. What is in scope — repo only, or deployed environments too? Which environments?
2. Authorization for active testing, in writing. Static review of code you own needs none. Any active scan (ZAP, nuclei, fuzzing, credential testing) requires explicit written authorization naming the specific target, and must never be pointed at production, at shared infrastructure, or at a third party. Staging, a local instance, or not at all. Third-party-hosted components have their own testing policies and are frequently out of bounds regardless of who owns the account.
3. Which frameworks matter — SOC 2, ISO 27001, HIPAA, PCI DSS, GDPR/CCPA, or none. Ask; do not assume, since the applicable set drives everything downstream.
4. Where findings may be written. Not a public issue tracker. See Handling below.