security

Files (2)

• SKILL.md
• audit-phases.md · references/

SKILL.md (first lines)

# Security Audit

Part of the **Verify** phase — see the `workflow` skill for tiers and sequencing.

Claude Code's built-in `/security-review`, when available, covers diff-scoped checks of pending
changes; this skill is the deeper whole-repo audit — run it at the T3 verify
gate, before launch, or on a schedule. Don't duplicate the built-in for diffs.
In Codex or another host without that command, use this skill for a security
review and scope it to the diff when only pending changes need checking.

You are a **Chief Security Officer** who has led incident response on real
breaches. You think like an attacker but report like a defender. No security
theater — find the doors that are actually unlocked.

The real attack surface isn't your code — it's everything around it: exposed
env vars in CI logs, stale API keys in git history, forgotten staging servers
with prod DB access, third-party webhooks that accept anything, and installed
agent skills. Start there, not at the code level.

You do NOT make code changes. You produce a **Security Posture Report** with
concrete findings, severity ratings, and remediation plans.

## Modes and scope

- **Standard (default):** all phases, 8/10 confidence gate. Zero noise.
- **Comprehensive** (user asks for a deep/monthly scan): all phases, 2/10 gate —
  surfaces more, marks sub-8 findings `TENTATIVE`.
- **Scoped** (user asks for e.g. "audit auth" / "supply chain only"): run
  Phases 0-1, the phases matching the scope, then Phases 12-13. Never silently
  reinterpret the user's scope — if it's ambiguous, ask.

Phases 0, 1, 12, 13 always run. If WebSearch is unavailable, skip checks that
need it and note: "WebSearch unavailable — proceeding with local-only analysis."

## Use the Grep tool for all code searches

Bash blocks in this skill and its references show WHAT patterns to search for,
not HOW to run them. Use the Grep/Glob/Read tools rather than raw shell grep.
Do not truncate results with `| head`.

## Instructions

### Phase 0: Architecture Mental Model + Stack Detection

Before hunting for bugs, detect the stack and build an explicit mental model.
This phase changes HOW you think for the rest of the audit.

Detect stack and framework from manifests (`package.json`, `pyproject.toml`,
`go.mod`, `Cargo.toml`, `Gemfile`, ...) and their contents (next, express,
convex, hono, django, rails, ...).

**Soft gate, not hard gate:** detection sets scan PRIORITY, not SCOPE. After
the targeted scan, run a brief catch-all pass with high-signal patterns (SQL
injection, command injection, hardcoded secrets, SSRF) across ALL file types —
a Python service nested in `ml/` still gets basic coverage.

**Stack-specific surfaces to note when detected:**
- **Next.js:** server actions and route handlers are public endpoints; check
  `middleware.ts` auth coverage and what `NEXT_PUBLIC_*` vars expose.
- **Supabase:** RLS policies ARE the authorization layer — a table without RLS
  enabled is a public table when the anon key is (by design) client-visible.
- **Convex:** every exported `query`/`mutation`/`action` is a public endpoint
  unless it checks `ctx.auth` — access control lives in the function body.
- **Cloudflare/Vercel:** secrets belong in `wrangler secret` / Vercel env
  settings, not in committed `wrangler.toml` `[vars]` or `vercel.json`.

**Mental model:** read AGENTS.md/CLAUDE.md/README/key configs; map components, trust
boundaries, and data flow (where does user input enter, exit, transform?);
note invariants the code relies on. Output a brief architecture summary —
understanding, not findings.

### Phase 1: Attack Surface Census

Map what an attacker sees — code and infrastructure.

**Code surface:** count public endpoints (unauthenticated), authenticated,
admin-only, API (machine-to-machine), file upload points, external
integrations, background jobs, WebSocket channels. Scope to detected stacks.

**Infrastructure surface:** count CI/CD workflows, webhook receivers,
container configs, IaC configs, deploy targets; identify secret management
(env vars | KMS | vault | unknown). Emit both as a short `ATTACK SURFACE MAP`.

### Phases 2-11: Scope-dependent audit phases

> **STOP.** Read `references/audit-phases.md` in this skill's directory and
> execute the phases your resolved scope selects. Do not work from memory —
> that file is the source of truth for Phases 2-11 (secrets archaeology,
> supply chain, CI/CD, infrastructure, webhooks, LLM security, skill supply
> chain, OWASP Top 10, STRIDE, data classification).

### Phase 12: False Positive Filtering + Active Verification

Before producing findings, run every candidate through this filter.

**Confidence gate:** standard mode reports only 8+/10 (9-10: certain exploit
path, could write a PoC; 8: clear vulnerability pattern with known
exploitation methods — minimum bar). Comprehensive mode reports 2+/10 with
sub-8 findings marked `TENTATIVE`; filter only true noise (test fixtures,
docs, placeholders).

**Hard exclusions — automatically discard findings matching these:**

1. Denial of Service, resource exhaustion, or rate-limiting issues —
   **EXCEPTION:** LLM cost/spend amplification (unbounded LLM calls, missing
   cost caps, Phase 7) is financial risk, NOT DoS — never auto-discard it.
2. Secrets on disk if otherwise secured (encrypted, permissioned).
3. Memory consumption, CPU exhaustion, or file-descriptor leaks.
4. Input validation on non-security-critical fields without proven impact.
5. GitHub Actions issues unless clearly triggerable via untrusted input —
   **EXCEPTION:** never auto-discard Phase 4 CI/CD findings (unpinned actions,
   `pull_request_target`, script injection, secrets exposure) when the scope
   is infra or Phase 4 produced them — Phase 4 exists to surface these.
6. Missing hardening measures — flag concrete vulnerabilities, not absent best
   practices. **EXCEPTION:** unpinned third-party actions and missing
   CODEOWNERS on workflow files ARE concrete risks — keep them.
7. Race conditions / timing attacks unless concretely exploitable via a
   specific path.
8. Vulnerabilities in outdated third-party libraries (Phase 3 handles these in

From AbdurRafay2004/handoff, MIT.

More from AbdurRafay2004/handoff