Security audit skill

Security, Bug & Data Protection Audit

A single comprehensive audit skill that replaces ad-hoc prompt lists. It combines static checklist review (100+ items, mapped to current industry standards) with a live threat-intel step, so findings reflect this week's attack patterns, not a stale training-data snapshot.

This skill is defensive/blue-team only: it finds and helps fix weaknesses in code the user owns or is authorized to audit. It never generates exploit code, malware, or attack tooling — only detection guidance and fixes.

When NOT to over-trigger

Don't run the full audit for a one-line code question, a single function review, or when the user is mid-feature-development and just wants that feature reviewed. In those cases, do a targeted check against the relevant category file only (see references/). Reserve the full 100+ item run for explicit audit requests or pre-launch checks.

Workflow

Run these five phases in order. Don't skip phases 1 and 5 — they're what makes this audit better than a static checklist someone could paste from a PDF.

Phase 1 — Recon (before opening the checklist)

Figure out what you're actually auditing before picking checks:

• Stack: language(s), framework(s), package manager(s), DB, auth provider, hosting.
• App type: has payments? has auth/accounts? multi-tenant? handles PII? has an LLM/agent component? public API? mobile app? Note this because it determines which checklist categories matter most (e.g., skip Category 11, LLM/AI-Specific, entirely if there's no LLM integration; deprioritize Category 8, Business Logic & Payments, with no checkout flow).
• Read package.json / requirements.txt / Gemfile / go.mod / Cargo.toml etc. to get the actual dependency list — you'll need it for Phase 2.
• If the codebase is large, don't try to hold it all in context at once — work category-by-category (per reference file) and grep/search for patterns rather than reading every file top to bottom.

Phase 2 — Live threat intelligence (do this even if you think you know the landscape)

Before running the static checklist, spend 3-8 web searches pulling current threat data. Training data on "the latest attacks" is never actually current — attacker TTPs, specific malicious package names, and active CVEs change weekly. See references/threat-intel.md for the exact search queries to run, organized by what's in the user's stack. At minimum:

• Search for supply-chain compromises affecting the specific package manager/ecosystem in use (npm, PyPI, RubyGems, crates.io, etc.) from the last 60-90 days.
• If any dependency in the project matches a name flagged in search results (or is suspiciously similar — typosquat check), flag it as critical regardless of what else you find.
• Search for any recently disclosed CVEs in the specific frameworks/libraries detected in Phase 1.
• If the app uses a specific auth provider, payment processor, or BaaS (Supabase, Firebase, Clerk, Stripe, Razorpay, Auth0, etc.), search for recent security advisories tied to that provider's misconfiguration patterns — these evolve as the providers change their defaults.

Cite what you find inline in the report (see report format below) so the user knows which findings are "always true" security hygiene vs. "this is actively being exploited right now."

Phase 3 — Run the checklist

Work through references/checklist.md (the full 100+ item list organized into 11 categories). For each applicable item:

• Mark PASS, FAIL, or N/A (with one-line reason for N/A — e.g., "no payment flow exists").
• For every FAIL, cite the exact file/line or pattern found, explain the concrete exploit path (not just "this is insecure" — say what an attacker does with it), and give the specific fix. Check references/fix-patterns.md first — it has ready-to-adapt code for the most common failures (IDOR, SQLi, password hashing, reset tokens, rate limiting, cookie flags, JWT pinning, security headers, CORS, webhook verification, SSRF guards, supply-chain config, XSS/ upload validation, LLM prompt-injection separation). Adapt the pattern to the actual framework/style in front of you rather than pasting it verbatim. If nothing there matches, write the fix from scratch following the same principles (parameterize, verify server-side, fail closed, least privilege).
• Don't just paste the checklist item text back — actually inspect the code. If you can't verify an item (e.g., can't see the production infra config from the repo alone), mark it UNVERIFIED and say what the user needs to check manually or provide.

Use references/scoring.md for exactly how PASS/FAIL/N/A/UNVERIFIED map to category scores.

Phase 4 — Fix or report

Ask the user (if not already clear from their request) whether they want you to:

1. Just report — produce the scored findings report only, no code changes, or
2. Fix as you go — apply fixes directly for FAILs as you find them, then report what changed.

Default to reporting first for anything touching auth, payments, or data deletion — those fixes can have behavioral side effects the user should approve. Low-risk fixes (adding security headers, redacting a log line, adding .env to .gitignore) can be applied directly if the user asked you to fix-as-you-go.

Phase 5 — Score and report

Use references/scoring.md for the rubric, but compute the actual numbers with scripts/calculate_score.py, not by hand. Tally each category's FAIL counts by severity (Critical/High/Medium/Low) plus UNVERIFIED counts, group them into the three report categories per scoring.md Step 2 (security / data_protection / bugs_reliability), build a small JSON object matching scripts/examples/findings-example.json's format, and run:

python3 scripts/calculate_score.py findings.json

This exists because hand-computing severity-weighted deductions across up to 116 items is exactly the kind of arithmetic that drifts between runs — the script is the single source of truth for the scoring math (it has its own test suite in scripts/tests/), so two audits of the same app with the same findings will always produce the same score. Use the script's output directly in the report; don't re-derive or round differently.

Report format

Always structure the final output like this:

# Security & Data Protection Audit — [app/project name]

## Overall Score: XX/100 (Grade: A-F)
Security: XX/100 | Bugs & Reliability: XX/100 | Data Protection: XX/100

## Critical Issues (fix before anything else)
[Numbered list — anything that's an active exploit path or matches a live threat found in Phase 2]

## Threat Intelligence Notes
[What was found in Phase 2 that's specifically relevant — recent CVEs, active supply-chain
campaigns, provider-specific advisories — with dates and sources]

## Findings by Category
[One collapsible-style section per checklist category from references/checklist.md — only
include categories that had applicable checks; skip categories marked entirely N/A except to
note them in one line]
  For each: ✅ Passed (count) | ❌ Failed (list with file/line, exploit path, fix) | ⚠️ Unverified (list)

## What Was Fixed vs. What Needs Your Review
[If fix-as-you-go was used]

## Re-test Recommendation
[When to re-run this audit — e.g., "after auth is rebuilt" or "before public launch" or
"re-run Phase 2 threat intel monthly since dependency risk changes weekly, independent of your code changes"]

Keep the tone direct and concrete — no filler, no "great job!" padding. A FAIL is a FAIL even if the rest of the app is solid. Cite specific attacker actions ("an attacker can change the user_id in this request body and read another tenant's invoices") not vague risk language ("this could be a security concern").

Origin mapping (for traceability)

This skill supersedes the "5 copy-paste security prompts" style of guide (the kind built on Gitleaks/Bearer/production-audit/Trail-of-Bits/attacker-review prompts pasted one at a time into an AI builder). If the user is coming from that workflow, here's where each prompt landed:

Original prompt	Based on	Now lives in
1. Secret Leak Prevention	Gitleaks	references/checklist.md Category 1
2. Personal Data Flow Audit	Bearer	references/checklist.md Category 5
3. Pre-Deploy Production Audit	ECC Production Audit	references/checklist.md Category 7
4. Deep Security Audit (payments/auth)	Trail of Bits Skills	references/checklist.md Categories 2 & 8
5. Attacker's Perspective Review	ECC Security Review	Woven through Categories 2, 4, 8 + the exploit-path framing required in "Report format" below

Everything else (Categories 3, 6, 9, 10, 11, 12, and the Phase 2 live threat-intel step) is net-new coverage the five-prompt approach didn't include — supply chain, LLM/AI-specific risk, error handling, API/mobile, AI-code hygiene, and current-week attack cross-referencing.

Reference files

• references/checklist.md — the full 100+ item checklist, organized into 11 categories (secrets, access control, injection, auth, data protection, supply chain, infra/config, business logic, error handling & logging, API/mobile-specific, LLM/AI-specific). Read the whole file; it's organized for scanning, not sequential reading.
• references/scoring.md — exact scoring rubric and how to compute category/overall scores.
• references/threat-intel.md — search query templates for Phase 2, organized by stack.
• references/vibe-coding-patterns.md — failure patterns specific to AI-generated code (Lovable/Bolt/Replit/Cursor/v0/Claude Code output), since these differ from patterns in hand-written legacy code and are what most requesters of this skill actually have.
• references/fix-patterns.md — ready-to-adapt code snippets for the most common FAILs, keyed to checklist item numbers, covering Node/Express, Next.js, Supabase/Postgres, Python, Django, and Rails.
• scripts/calculate_score.py — the authoritative, tested scoring calculator. Run this in Phase 5 rather than computing the rubric by hand; see scripts/tests/ for its test suite and scripts/examples/findings-example.json for the expected input format.