What a real security audit looks like

The code audit pipeline has a security pillar. It finds hardcoded secrets, unvalidated inputs, and dependency CVEs. That's useful. But it's one auditor looking at security alongside four other concerns. It catches the obvious things.

A real security audit is different. It's six agents doing nothing but looking for ways to break your application. Authentication flows get traced end to end. Every API endpoint gets examined for input validation, authorization checks, and data leakage. Infrastructure configuration gets pulled apart — headers, TLS, deployment setup, network exposure. Protocol-specific surfaces get their own examination because MCP, GraphQL, and WebSocket each have attack vectors that REST doesn't.

The difference between the code audit's security pillar and a dedicated security audit is the difference between a physical and a full diagnostic workup. Both check your heart rate. Only one looks at everything.

What you're actually worried about

Most security problems aren't dramatic. They're mundane. An API endpoint that doesn't check whether the authenticated user owns the resource they're requesting. A session token that doesn't expire. A form that accepts 10MB of input because nobody set a limit. A CORS policy that says * because someone was debugging and forgot to change it back.

These aren't hypothetical. They're in most codebases. They're easy to write, easy to miss, and easy to exploit. The security audit finds them by looking at every surface systematically instead of hoping a code reviewer notices.

Six agents, six angles

The audit launches six parallel agents. Each one examines a different attack surface:

Authentication (Report 01) — Traces every auth flow: login, signup, password reset, token refresh, session management, OAuth. Checks token storage, expiration, rotation, and revocation. Evaluates whether authentication state is correctly propagated across the application. This catches the "logged in as user A but can see user B's data" class of bugs.

API & Data Protection (Report 02) — Examines every endpoint for input validation, output encoding, authorization checks, rate limiting, and data exposure. Checks whether responses leak internal IDs, stack traces, or database structure. Evaluates request/response schemas for injection opportunities. This is where SQL injection, XSS, and mass assignment vulnerabilities live.

Infrastructure (Report 03) — Evaluates hosting configuration, deployment pipelines, network exposure, security headers, TLS configuration, and container security. Checks for exposed admin interfaces, debug endpoints, and default credentials. Reviews CI/CD for secret leakage and supply chain risks.

Protocol-Specific (Report 04) — Examines attack surfaces unique to the protocols in use. MCP servers have tool injection risks. GraphQL has introspection exposure and query complexity attacks. WebSocket connections need authentication and message validation. RSS feeds can be vectors for stored XSS. Each protocol gets its own assessment because generic security tooling misses protocol-specific vectors.

Abuse Prevention (Report 05) — Evaluates rate limiting, brute force protection, spam prevention, enumeration resistance, and resource exhaustion protections. This is the "what happens if someone is deliberately hostile" layer. Not sophisticated attacks — just someone running a script in a loop.

OWASP Compliance (Report 06) — Maps findings against the OWASP Top 10. This is the standard that auditors, clients, and compliance teams recognize. Each Top 10 category gets a pass/fail with specific findings and remediation steps.

Report 07 is optional — privacy compliance. If the audit detects PII handling (user data, personal information, geographic data), it evaluates GDPR considerations, data retention, consent mechanisms, and right-to-deletion support.

Report 00 synthesizes everything into an executive summary with an overall posture score and the top remediation priorities.

The output you hand to someone

The executive summary is the document that goes to leadership. It says: "Our security posture is X/10. Here are the three things that need to happen this sprint. Here are the five things that should happen this quarter."

The individual agent reports go to the developer doing the work. Each finding has a location (the specific file and function), the current state, why it's a problem, how to fix it, and the severity. A developer can open the report and start working through it without needing additional context.

When to run it

Before launch. Non-negotiable. Especially if the application handles user data, financial transactions, or authentication.

After adding auth or API changes. Authentication and authorization are where most security bugs hide. Any change to auth flows should trigger a re-audit.

Before a compliance review. The OWASP report gives you a head start. You'll know what the auditor will find before they find it.

Quarterly. Dependencies get CVEs. New code gets written. Attack surfaces change. The security posture you had three months ago isn't the one you have now.

Skip it on internal tools with no external exposure and no sensitive data. Even then, the infrastructure and dependency checks are worth running.

---

Resources

Pipeline reference: /security-audit — 8 reports, 6 agents, full output tree.

Related reading:

• 01. How to audit your codebase before it audits you — the code audit includes a lighter security pillar
• 03. Documenting projects that don't document themselves — technical specification includes security architecture

Download: Full toolkit (252KB) — all 16 commands, all 11 skills, installs in 30 seconds.

---

Part of the Claude Skills Library.