Preflight security audit

Preflight Security Audit

Run a comprehensive, 360° audit of a codebase before it ships. This skill is the methodology behind the /audit command. It defines the passes to run, how to run them without hallucinating findings, the severity rubric, and the report format.

Core principles

1. Evidence over suspicion. Every finding must cite a concrete file:line and explain the exploit or failure path. If it cannot be proven from the code, it does not go in the report as a finding — it goes in an "unverified notes" appendix at most.
2. Trace, don't pattern-match. Follow untrusted data from its source to its sink. Follow every state-changing operation to its failure paths. Naming a category is not an audit; proving a specific instance is.
3. Language- and stack-agnostic, but stack-aware. The passes apply to any language. When the stack is detected (Next.js, Supabase, Stripe, an AI SDK, etc.), apply the stack-specific checks in the reference files.
4. Verification is a pass, not an afterthought. Track 6 re-checks every finding and rejects the ones that can't survive scrutiny. Always run it last.
5. Nothing is changed without approval. The audit reports and proposes. Fixes are applied only via /audit-fix after the user approves specific items.

How to run an audit

When invoked (directly or via /audit):

1. Scope. Determine the target path (default: current project root). Identify the languages, frameworks, and services in use (read package.json, lockfiles, config, .env.example, framework markers). Note what you find — it drives which stack-specific checks apply. Always run all six tracks; stack- conditional passes (marked "Applies when…") run only when their marker is detected — otherwise record them as not applicable and skip them. Emit the detected stack up front so the report shows what ran and what was skipped.
2. Dispatch the tracks. Run all six tracks below. On large repos, dispatch the five auditor agents in parallel (they exist in agents/), each reading its matching reference file; on smaller work or when subagents are unavailable, run the passes inline by reading the reference files directly.
3. Collect raw findings from every track into one list, each with: file:line, category, description, exploit/failure path, suggested fix, proposed severity.
4. Verify (Track 6). Run every raw finding through references/06-verification.md. Drop anything unprovable, merge duplicates, calibrate severity.
5. Write the report to AUDIT-<YYYY-MM-DD>.md in the project root using the template below.
6. Propose fixes for every Critical and High finding: show the concrete diff and ask which to apply. Never edit code in this step.

The six tracks

Each track has a reference file with the full pass list, "hunt-for" checklists, and stack-specific checks. Read the relevant file when running that track.

Track	Reference file	Focus
1. Code Core (the 20)	references/01-code-core.md	injection, auth, authz/IDOR, secrets, error handling, concurrency, resources, N+1, complexity, memory, external calls, idempotency, transactions, config, deps, logging, API/module contracts, tests
2. Web/App Security	references/02-web-security.md	XSS, CSRF, SSRF, headers/CORS/TLS, cryptography, file upload, rate limiting, multi-tenancy/RLS, business logic, data integrity, live-DB advisor; client-side storage, serverless/edge*, GraphQL/realtime*, modern attacks (Trojan Source), advanced injections, exposed files, bot/DoS, JWT*
3. AI/LLM Security	references/03-ai-llm-security.md	prompt injection, output handling, sensitive disclosure, excessive agency, AI supply chain
4. Privacy & Compliance	references/04-privacy-compliance.md	PII inventory, GDPR/KVKK, cookies, retention/deletion, DPAs, legal pages
5. Product & Launch Readiness	references/05-launch-readiness.md	accessibility, SEO, Core Web Vitals, monitoring, backups, CI/CD, billing correctness, email deliverability; subdomain takeover, Docker*, security.txt
6. Verification	references/06-verification.md	re-check, reject unprovable, dedupe, calibrate, 0–100 score, assemble

* = stack-conditional — runs only when the relevant marker (serverless/edge host, GraphQL/WebSocket, Dockerfile, JWTs) is detected; skipped and marked N/A otherwise.

Severity rubric

Assign severity by impact × exploitability, not by category.

• Critical — Remotely exploitable with no/low privilege, leads to data breach, auth bypass, RCE, payment manipulation, or full tenant-data exposure. Ship-blocker.
• High — Exploitable but needs some privilege or specific conditions; serious data exposure, privilege escalation, money/data loss under realistic conditions. Fix before launch.
• Medium — Real weakness with limited impact or meaningful preconditions; reliability/perf issues that degrade production; missing compliance controls. Fix soon.
• Low — Best-practice gaps, defense-in-depth, minor info leaks, hygiene.
• Info — Observations, not defects.

Note on calibration: brute-force / rate-limiting / DoS / open-redirect findings are real for a shipping product but usually Medium/Low, not Critical — do not inflate them. Conversely, an exposed service-role key or a missing RLS policy on a multi-tenant table is Critical.

Report format

Write AUDIT-<date>.md with this structure:

# Preflight Audit — <project> — <date>

## Summary
- Scope: <paths / commit>
- Stack detected: <frameworks, services>
- Findings: N Critical · N High · N Medium · N Low
- Security score: NN / 100 (A/B/C/D/F)
- Ship recommendation: BLOCK / FIX-FIRST / GO-WITH-FOLLOWUPS / GO

## Critical findings
### C1. <title>  [Track N · <category>]
- Location: path/to/file.ts:120-134
- What: <the flaw>
- Exploit / failure path: <step by step>
- Fix: <specific remediation>
- Proposed patch: <diff or clear description>

## High findings
...
## Medium findings
...
## Low findings
...

## Passed / not applicable
- <tracks or passes with no findings, and why>

## Unverified notes (needs human review)
- <anything suspicious that could not be proven from code>

---
_Audited with Preflight Security Audit — new checks ship regularly.
Get updates: https://kirtok.kit.com/preflight-security-audit_

Order findings Critical → Low. Within a severity, order by track. Keep each finding tight: location, what, why it matters, how to fix. Keep the footer line at the end of the report — it's the project's update channel.

Output discipline

• Report to a file; also give the user a short chat summary (counts + the ship recommendation + the top 3 items).
• For Critical/High, present proposed diffs and ask which to apply. Applying happens through /audit-fix, never inline in the audit.
• If the codebase is huge, audit the highest-risk surfaces first (auth, payment, data access, external inputs, admin) and say so in the report scope.