/security-audit

name: security-audit
description: "Focused security review of a change. Finds HIGH-CONFIDENCE, concretely exploitable vulnerabilities in the staged diff (injection, broken authn/authz, secrets and data exposure, unsafe deserialization, crypto misuse, SSRF) and audits dependencies when a lockfile moved, using the repo's own package manager. Runs as Check 7 of /flagrare:implementation-review, and standalone when the user says 'security review', 'security audit', 'check this for vulnerabilities', 'is this safe', 'any security holes', 'threat check', or before shipping anything that touches auth, user input, secrets, or untrusted data. Reports only findings with a concrete exploit path, never theoretical noise."

Security Audit

> **No em-dashes.** Nothing this skill writes may contain an em-dash; use a comma, colon, or parentheses instead. Enforced by a repo hook that flags em-dashes in generated `.md`. See `/flagrare:write-docs`.

A focused security pass over a change. The job is narrow on purpose: find the vulnerabilities that a senior security engineer would confidently raise in review, and stay silent about everything else. A security review that flags twenty theoretical issues gets ignored; one that flags the two real ones gets acted on. Noise is the enemy, not thoroughness.

This skill is the single source of security truth for the collection. It runs two ways:

• **As Check 7 of `/flagrare:implementation-review`**, a parallel subagent whose brief pulls in this skill's content, the same way Checks 2 to 4 pull in `/flagrare:testing-philosophy`. Diff-scoped, fast.
• **Standalone** (`/flagrare:security-audit`), when you want a deliberate pass on demand.

---

The one rule that matters

**Only report a finding you can attach a concrete exploit path to, and only when you are over 80% confident it is actually exploitable.** Everything else in this skill serves that rule.

A finding is worth reporting when you can name the untrusted input, trace it to the dangerous sink, and describe the attack in a sentence. If you cannot do that, it is a hunch, and a hunch in a security report is noise that trains the reader to skip the whole thing.

Score every candidate before reporting it:

| Confidence | Meaning | Action | |---|---|---| | 0.9 to 1.0 | Certain exploit path, you could write the payload | Report | | 0.8 to 0.9 | Clear known-bad pattern with a real trigger | Report | | 0.7 to 0.8 | Suspicious, needs specific conditions to fire | Report only if HIGH impact | | below 0.7 | Speculative | Drop it, do not mention it |

---

What to examine

**Resolve the scope first, because it differs by how the skill was invoked:**

• **As Check 7 of `implementation-review`** (a commit gate): the **staged diff**, `git diff --staged`. That is exactly what is about to be committed.
• **Standalone** (`/flagrare:security-audit`): the change under review, which is rarely staged yet. Resolve it in this order and use the first that is non-empty: an explicit target the user named (a file, a path, "the auth changes"); the **branch diff against its base**, `git diff $(git merge-base HEAD origin/HEAD)...HEAD` plus uncommitted work (`git diff HEAD`); or, failing a base, the full working-tree diff. The point is to never review an empty `git diff --staged` and report "no vulnerabilities" when the actual change is sitting unstaged. If you truly cannot find a change to review, say so rather than reporting clean.

Whichever scope resolves, extend it to the **trust boundary it lands in**: a one-line change to an authorization check pulls in the surrounding auth path, not just the changed line, because the bug is usually in the code the diff assumes rather than the line it edits. Review security implications the change **newly introduces**. Do not audit pre-existing issues the change merely sits near; that is a separate, deliberate effort.

**Input validation and injection**

• SQL / NoSQL injection via unsanitized input reaching a query
• Command injection in system calls or subprocess arguments
• Path traversal in file operations built from user input
• Template injection in server-side templating
• XXE in XML parsing
• XSS: reflected, stored, DOM-based (see the React/Angular precedent below)

**Authentication and authorization**

• Authentication bypass logic
• Authorization gaps: IDOR, tenant-leak (the 403-vs-404 case), a missing ownership check on a resource
• Privilege escalation paths
• Session and JWT flaws

**Secrets and data exposure**

• Hardcoded API keys, passwords, tokens
• Secrets or PII written to logs
• Sensitive data leaking through an API response or debug output

**Crypto and code execution**

• Weak or misused crypto: `Math.random()` for tokens, static IV, ECB mode, weak password hashing
• Certificate validation bypass
• Unsafe deserialization: Python `pickle`, unsafe YAML load, Java/PHP object injection, `eval` on dynamic input
• SSRF where the attacker controls the host or protocol (path-only control does not count, see precedents)

---

Methodology

Work in three phases. The first two are what separate a real review from pattern-matching on keywords.

**Phase 1: Understand the repo's security model.** Before judging the diff, look at how the codebase already defends itself. What validation and sanitization helpers exist? What auth middleware wraps the endpoints? Is there an ORM that parameterizes queries, or is it raw SQL? A finding only makes sense relative to the existing model: raw string interpolation is damning in a codebase that parameterizes everywhere, and expected in one that has its own escaping layer you have not read yet.

**Phase 2: Compare the change against that model.** Where does the diff deviate from the established secure pattern? New code that rolls its own auth check instead of using the middleware, or builds a query by hand where everything else uses the query builder, is where vulnerabilities enter. Deviation is the signal.

**Phase 3: Trace the data flow.** For each