Security Audit

Security Review

This skill must only be invoked from the main session, never from a subagent.

1. Determine Scope

a. If the user specified file paths, directories, or a description of what to review, use that as the scope. b. If the user said "review my changes" or similar, use git diff HEAD (unstaged + staged) and git diff --cached as the scope. If no changes exist, tell the user and stop. c. If no scope is specified, ask the user: "What should I review? Options: specific files/directories, recent changes (git diff), or the entire project." d. For entire-project scope, identify all source files (exclude vendored/generated code, build artifacts, lock files, and test fixtures). Prioritize by security relevance: route definitions, API handlers, middleware, auth modules, database access layers, and configuration files. Distribute files across agents by relevance to each agent's domain. e. Confirm scope with the user before proceeding: "I'll security-review [scope description]. Correct?"

Web Application Detection

After determining scope, check whether the project is a web application by looking for indicators: route/endpoint definitions, HTTP framework imports (Express, Flask, Django, FastAPI, Spring, Next.js, Rails, ASP.NET, etc.), HTML templates, API handlers, or middleware. If detected, set web_app = true and inform the user: "Detected web application — enabling web-specific security checks (Agent 6)." If uncertain, ask.

Threat Context

Before spawning subagents, build a threat context by examining at most 10 files (entry points, configs, auth modules, route definitions):

• Trust boundaries: Where untrusted input enters (user input, external APIs, file uploads, webhooks, message queues) and where it's consumed (database, command execution, rendering, serialization).
• Data sensitivity: Classify data handled — PII, financial, health/PHI, authentication material, or public-only. Note the highest sensitivity tier.
• High-risk components: Identify the 3-5 components with most exposure: auth modules, payment processing, admin endpoints, data export/import, file handling, external integrations.

Capture as a short bullet list (max 8 lines). If fewer than 3 relevant files are found, skip threat context generation and note "Insufficient project structure for threat modeling" in the report.

The main session must compose the relevant subset of this context into each subagent's prompt — pass trust boundaries and high-risk components to Agents 1, 2, 4, and 7; pass data sensitivity to Agents 3 and 5; pass all three to Agent 6 (if active). Follow the same pattern as web_app conditionals: inline the context directly, do not use placeholder variables.

Infrastructure as Code Detection

Check for IaC files: *.tf (Terraform), CloudFormation templates (AWSTemplateFormatVersion), Pulumi.yaml, Kubernetes manifests (files containing both apiVersion: and kind: where kind matches a known K8s resource — Pod, Deployment, Service, StatefulSet, Ingress, ConfigMap, Secret, etc. — or files co-located with kustomization.yaml), Helm charts (Chart.yaml). If found, set iac_detected = true and inform user: "Detected IaC files ([tool]) — enabling infrastructure configuration checks in Agent 4."

PHP Detection

Check for .php files or composer.json in scope. If found, set php_detected = true and inform user: "Detected PHP project — enabling PHP-specific security checks in Agent 1."

Compliance Context (Optional)

If the user includes compliance: in their arguments (e.g., /security-audit src/ compliance: hipaa), set compliance_framework and confirm with the user. If the user mentions compliance in natural language (e.g., "we need HIPAA compliance"), infer the framework but always confirm before enabling compliance-specific checks: "I detected a reference to [framework] compliance. Should I enable [framework]-specific security checks?" Multiple frameworks can be comma-separated. Supported: pci-dss, hipaa, soc2, gdpr.

Append a compliance note to the threat context passed to each relevant agent: > Compliance scope: [framework]. Prioritize findings mapping to this framework's controls. Append control references in the Category field (e.g., "CWE-798 / PCI-DSS 2.1").

2. Round 1 — Spawn Parallel Subagents

Spawn 6 subagents for all projects (Agents 1-5 and 7). If web_app = true, also spawn Agent 6 (7 total). If iac_detected = true, add up to 20 IaC files to Agent 4's scope (prioritize root modules and files containing resource/data blocks) — these must be included in the scope shown to the user in step (e) for confirmation, not added silently.

Spawn all subagents on the latest, most capable model available — omit the per-agent model override so each inherits the session's model rather than pinning a version-specific name. Do not add an override that downgrades the breadth passes (4, 5, 6, 7) to a cheaper tier such as sonnet (measured 2026-06-11: sonnet's false-positive rate in breadth slots cost more verification time than its savings), and never default any agent to haiku — these prompts require rejecting rationalizations and reading carefully, where haiku is materially weaker; use it only as an explicit opt-in after a measured comparison. (CLAUDE_CODE_SUBAGENT_MODEL, if set in the environment Claude launches subagents under, overrides the inherited model.)

For Agent 5 (secrets), always include these files in scope regardless of user-specified scope (if they exist): .env*, *.env, docker-compose*.yml, Dockerfile*, .github/workflows/*.yml, .gitlab-ci.yml, Jenkinsfile, .gitignore, .pre-commit-config.yaml, and any config files matching *config*, *settings*, *secret*. Note: Agent 5 scans CI configs for hardcoded secrets/credentials only — security tooling presence is Agent 7's concern.

• Agent 1 — Injection & Input Validation: SQL injection, NoSQL injection, command injection, LDAP injection, XPath injection, template injection (SSTI), header injection, log injection. Check that all user input is validated at system boundaries, parameterized queries are used, and no string concatenation builds queries or commands.

If web_app = true, also check:

• Open Redirect: Any endpoint accepting a URL/path for redirection. Check for bypass techniques: @ symbol (https://legit.com@evil.com), subdomain abuse (legit.com.evil.com), protocol-relative URLs (//evil.com), javascript: URIs, double URL encoding (%252f%252f), backslash normalization, null bytes, IDN homograph attacks (Cyrillic lookalikes), data: URIs, fragment abuse. Verify redirects use an allowlist or restrict to relative paths with proper validation.
• XSS indirect input sources: Beyond form fields, check URL parameters, URL fragments (hash values), HTTP headers rendered in pages (Referer, User-Agent), data from third-party APIs displayed to users, WebSocket messages, postMessage data from iframes, localStorage/sessionStorage values rendered to DOM, error messages reflecting user input, PDF/document generators accepting HTML, email templates with user data, admin log viewers, JSON responses rendered as HTML, SVG uploads (can contain JavaScript), and markdown rendering that allows raw HTML.
• Context-specific output encoding: Verify HTML context uses HTML entity encoding, JavaScript context uses JS escaping, URL context uses URL encoding, CSS context uses CSS escaping. Flag any manual string concatenation into HTML/JS without framework auto-escaping.
• SQL injection blind spots: ORDER BY clauses (cannot parameterize — must whitelist column names), table/column names in dynamic queries (must whitelist), LIKE patterns (escape % and _ wildcards), IN clauses with dynamic lists.

If compliance_framework includes gdpr, also check:

• Consent handling: Verify data collection endpoints have explicit consent mechanisms before processing personal data.

If php_detected = true, also check:

• PHP type juggling: loose comparison (==) with "0e..." strings, "0" == false, "" == 0 — flag security-sensitive comparisons using == instead of ===
• preg_replace with /e modifier (RCE), assert() with string argument (code evaluation), extract() on user input (variable overwrite), zip:// wrapper LFI
• parse_url() vs curl parsing discrepancy: double-@ in URLs parsed differently, enabling SSRF bypass

Encoding/parsing mismatch checks (all languages):

• Unicode normalization bypass: normalization-sensitive operations (case-insensitive comparison, lowercasing for filter bypass) may not handle U+017F (ſ), U+212A (K), and similar codepoints consistently — verify input is Unicode-normalized before security checks
• Charset mismatches: Shift-JIS multi-byte SQL injection, non-breaking space (U+00A0) injection in query languages
• Go-specific: flag patterns like if len(userInput) tag hijacking when base-uri directive is missing, ` scriptless exfiltration. Flag behavioral framework attribute execution (hx-get, x-data, _`) only when attribute values are populated from unsanitized user input — mere presence is NOT a finding.
• CSS-only data exfiltration: via container queries + custom fonts (no JavaScript needed) — report as impact escalation on any identified CSS injection finding, not as a standalone finding
• DOM clobbering: named form elements (name="location", id="cookie") overriding global variables — flag when user-controlled HTML is rendered without sanitization that strips name/id attributes

• CORS configuration: Check Access-Control-Allow-Origin — flag * (wildcard) on authenticated endpoints, flag dynamic origin reflection without allowlist validation, check Access-Control-Allow-Credentials: true is only used with specific origins (never with *), verify Access-Control-Allow-Methods and Access-Control-Allow-Headers are restrictive.

• Cookie security attributes: Audit all Set-Cookie calls for:
• HttpOnly flag (prevents JS access — required for session/auth cookies)
• Secure flag (HTTPS-only — required for all sensitive cookies)
• SameSite=Strict or SameSite=Lax (flag SameSite=None without justification)
• Proper Path and Domain scoping (avoid overly broad cookie scope)
• Reasonable expiration (Max-Age/Expires — flag session cookies that never expire)

• Client-side secret exposure: Check for secrets in JavaScript bundles, source maps shipped to production, HTML comments, hidden form fields, data attributes, localStorage/sessionStorage writes of tokens/keys, initial state/hydration data in SSR apps (Next.js getServerSideProps, Nuxt asyncData, etc.), and environment variables exposed via build tools (NEXT_PUBLIC_*, REACT_APP_*, VITE_*).

• Sensitive data in client responses: Check API responses for fields that should not reach the client: password hashes, internal IDs, full SSNs, unmasked credit card numbers, email addresses of other users, internal infrastructure details, debug information, or full stack traces. Verify DTOs/serializers restrict output fields.

• Agent 7 — CI/CD Pipeline Security: Scan CI configs (.github/workflows/*.yml, .gitlab-ci.yml, Jenkinsfile, .circleci/config.yml, azure-pipelines.yml) for security tooling presence. This agent always runs (not conditional).
• SAST: Semgrep, CodeQL, SonarQube, Bandit, Brakeman — check for github/codeql-action, semgrep steps, or equivalent.
• SCA/dependency scanning: Trivy, Snyk, Dependabot (.github/dependabot.yml), Renovate (renovate.json), npm audit, pip-audit.
• DAST (web apps only): ZAP, Nuclei, Burp CI — only flag absence if web_app = true.
• If no CI config files exist, report a single finding: "No CI/CD pipeline detected — unable to verify automated security scanning."
• If CI exists but none of these scanning categories are present, flag as medium: "No automated security scanning in CI pipeline." Provide a concrete GitHub Actions snippet:

```yaml

• uses: semgrep/semgrep-action@v1
• uses: aquasecurity/trivy-action@master

with: { scan-type: 'fs' } ```

• Note: Agent 5 scans CI configs for hardcoded secrets/credentials. Agent 7 scans for security tooling presence — no overlap.

If compliance_framework includes soc2, also check:

• Change management controls in CI/CD pipelines (approval gates, protected branches, required reviews), monitoring/alerting configured.

Each subagent's prompt MUST be assembled verbatim from the shared fragments in ~/.claude/rules/review-output-contract.md plus this skill's domain-specific content. Read that file (when working inside the claude_extensions repo itself it is also at rules/review-output-contract.md) and inline the named fragment in place of each > marker below; inline every other line exactly as written: > > > > Approach the code from an attacker's perspective. For each issue found, verify it is actually exploitable in context — do not flag theoretical issues that are mitigated elsewhere. Check if a framework or middleware already handles the concern before reporting. > > > > - Severity: critical | high | medium | low > - Category: OWASP category or CWE ID (e.g., "A03:2021 Injection", "CWE-798 Hardcoded Credentials") > - Location: file path and line number or function name > - Issue: one-sentence description of the vulnerability > - Impact: one-sentence description of what an attacker could achieve — quantify blast radius from code context where possible (e.g., "exposes entire users table" not just "exposes user data"; "affects every authenticated API endpoint" not just "auth bypass possible") > - Fix: one-sentence concrete remediation (not "consider" or "review" — state what to do) > - Evidence: the specific code snippet (max 3 lines) that demonstrates the issue > > Severity guide: > - critical: Directly exploitable, leads to RCE, full data breach, or auth bypass. No additional access needed. > - high: Exploitable with some preconditions, leads to significant data exposure, privilege escalation, or account takeover. > - medium: Exploitable but limited impact, or requires significant preconditions. Includes missing security hardening that enables other attacks. > - low: Defense-in-depth gap, informational, or best-practice violation with minimal direct exploitability. > > > Rationalizations to Reject — Do not accept these dismissals as justification for downgrading or omitting findings: > - "It's behind a VPN / internal only" — internal networks get breached; defense in depth applies > - "Only admins can reach this endpoint" — admin accounts get compromised; least privilege still matters > - "We sanitize input elsewhere" — verify the sanitization exists and covers this path; don't assume > - "It's just a dev/staging environment" — dev environments often mirror prod data and credentials > - "The framework handles that automatically" — verify the framework config; defaults aren't always secure > - "We'll fix it before launch" — security debt compounds; fix now or track with a deadline > - "No attacker would find this" — security through obscurity is not a control > - "It only runs in CI" — CI environments have secrets, network access, and deploy permissions > - "The algorithm is widely used / industry standard" — widespread adoption ≠ secure in context; watch for dismissals like "we use bcrypt — except this one legacy endpoint" that concede the exception while waving it off > > Red Flags — STOP and Re-examine — If you catch yourself thinking any of these, stop and reconsider: > - "This looks like standard auth code, probably fine" — STOP. Auth code is where the most critical bugs live. > - "I don't see any obvious injection points" — STOP. The non-obvious ones are the ones that ship

…

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: kimon1230
• Source: kimon1230/claude_extensions
• License: MIT

Install and usage instructions live in the source repository linked above.