security-review

Audit the changed code for exploitable vulnerabilities and report each one with its severity, confidence, and a concrete fix. The audit is read-only: remediation is code in the report, never an edit. Explicit user instructions override anything below.

Think like an attacker: before rating a pattern, ask how it would be exploited from the attack surface. Calibrate in both directions. Code exploitable remotely without authentication is CRITICAL, never softened. When exploitability is uncertain, lower the confidence and flag the finding for human review instead of raising the severity; a missed borderline LOW costs less than a false CRITICAL.

1. Scope

Audit the files or folder in $ARGUMENTS. Without arguments, take the changed files from git: git diff --name-only HEAD, git diff --name-only --cached, git diff --name-only main...HEAD (or master), and untracked new files from git ls-files --others --exclude-standard, which have no diff and are audited whole. With no changes and no arguments, or when git fails and no arguments were given, stop and ask which files to audit; never fall back to the whole repository. Skip binary, unreadable, and empty-diff files, and name them in the scope line.

Read every file in scope before auditing. Above about 20 files, read in priority order: auth, session, crypto, database, and user-input handling first, then new files, then the largest changes. Classify language, framework, and risk tier (auth, billing, crypto: HIGH; business logic: MEDIUM; UI and docs: LOW).

2. Threat model

Before rating anything, write a 3-5 line threat model from what you read: trust boundaries (where untrusted input enters, where privileged data exits), data flows from source to sink, the attack surface (HTTP handlers, CLI parsers, message consumers, public endpoints, upload handlers), and the risk context of the domain. It sets severity: the same pattern can be CRITICAL in auth code and MEDIUM in an internal CLI.

3. Audit

Examine every file in scope through three lenses, using the matching sections of the security checklist for indicators: