TL;DR: Security audits usually start from a blank page, every single time. I packaged my audit process into an open-source Claude Code skill: run /security-audit all and you get an 8-phase, evidence-based assessment across web, infrastructure, backend, mobile, compliance, and LLM/AI — including the dashboard-only settings that no CLI can reach. It's on GitHub: toshipon/claude-code-security-audit-skill
The problem: code ships faster than audits
AI coding agents now write a large share of our code. Review and security checks have not kept up.
Even before AI, my audits had a recurring problem: every engagement started from scratch. The stack spans web, mobile, infrastructure, and backend, and each layer has its own checklist. OWASP's guidance is comprehensive, but it's a mountain of material to re-read each time. And some of the most important settings — Vercel Deployment Protection, Supabase Auth policies — don't exist in any CLI or API. They live behind dashboards.
So I stopped treating the audit as a document I rewrite each time, and turned it into a reusable Claude Code skill.
What it does
Install it from the plugin marketplace, inside Claude Code:
/plugin marketplace add toshipon/claude-code-security-audit-skill
/plugin install security-audit@toshipon-security-audit
Then:
/security-audit all # full-stack audit (recommended)
/security-audit nextjs # just the Next.js app
/security-audit supabase # just the Supabase backend
/security-audit llm # just LLM/AI security
/security-audit terraform # just the IaC
The audit runs in 8 phases:
| Phase | Scope | How it's checked |
|---|---|---|
| 1. Reconnaissance | Project structure, trust boundaries, data flow | Glob / Read |
| 2. Web application | Next.js Server Actions, Middleware, CSP, known CVEs | Grep / Bash |
| 3. Infrastructure | Vercel, Terraform, AWS, GCP, Azure | CLI + Chrome MCP |
| 4. Backend | Supabase RLS, Python, Go, Rails, Rust | SQL / Grep |
| 5. Mobile | iOS, Android, Flutter, React Native | Grep / Bash |
| 6. Compliance | PCI-DSS, HIPAA, SOX, GDPR, CCPA, SOC 2, ISO 27001 | Analysis |
| 7. Advanced detection | Supply chain, containers/K8s, CI/CD, secrets, LLM/AI | Grep / Bash |
| 8. Cross-layer analysis | Auth flow consistency, token lifecycle, data protection continuity | Analysis |
Nothing here invents its own categories. Web checks map to OWASP Top 10:2025 and WSTG, mobile to MASVS v2 / MASTG, infrastructure to CIS Benchmarks, and LLM checks to the OWASP Top 10 for LLM Applications. That matters when you hand the report to someone else: it's written in a language every security reviewer already speaks.
Three design decisions that made it work
1. Progressive disclosure, so the skill stays usable at scale
The detailed check patterns — more than two dozen reference files covering everything from Next.js to Rust to PCI-DSS — live in a references/ directory and are loaded only when that target is audited. SKILL.md itself stays a concise overview.
This was the single most important lesson from Anthropic's own skill best practices (and from studying Trail of Bits' skills): a skill that dumps everything into context stops being a tool and becomes noise. Run /security-audit android, and only the Android reference loads.
2. Evidence-first, and a list of rationalizations to reject
An LLM doing security review has a failure mode: plausible-sounding findings with no proof. So every check in this skill ships with the concrete command, grep pattern, or SQL query that produces the evidence. For example, finding Supabase tables with Row Level Security disabled is not an opinion — it's this query:
SELECT n.nspname AS schema, c.relname AS table_name
FROM pg_class c
JOIN pg_namespace n ON n.oid = c.relnamespace
WHERE c.relkind = 'r'
AND n.nspname = 'public'
AND c.relrowsecurity = false;
Every finding in the report carries a file path, a line number, and a concrete remediation.
The skill also hard-codes the excuses it must reject — the ones I kept hearing (and making) in real audits:
- "It's behind authentication" — authenticated users can be attackers too
- "We'll fix it later" — security debt compounds; Critical/High gets fixed now
- "It's only in dev/staging" — credentials and patterns leak into production
- "The framework handles it" — verify it covers this specific case
- "No one would find it" — security through obscurity is not a defense
3. CLI + Chrome MCP, because dashboards are part of the attack surface
This is the part most audit automation skips. Some settings simply cannot be checked from a terminal:
| Setting | CLI/SQL | Needs dashboard inspection |
|---|---|---|
| Vercel environment variables | ✅ vercel env ls
|
— |
| Vercel Deployment Protection | — | Toggle state and protection scope |
| Supabase RLS status | ✅ SQL query | — |
| Supabase Auth settings (MFA, email confirmation, rate limits) | — | Dashboard only |
| Supabase Security Advisor | — | Full lint findings |
The skill drives Chrome MCP to open those dashboard pages, extract the setting states, and capture screenshots as evidence. And because a dashboard finding can't be fixed with a code change, the report format says so explicitly and includes the manual remediation steps:
### [HIGH-003] Vercel Deployment Protection Disabled
- Current Value: Deployment Protection = OFF
- Recommended Value: Deployment Protection = Vercel Authentication
- Manual Remediation Steps:
1. Vercel Dashboard → Project Settings → Deployment Protection
2. Select "Standard Protection"
3. Enable "Vercel Authentication"
4. Verify the protection level for Preview Deployments
5. Click "Save"
- Impact: Public access to Preview URLs will be restricted.
What it deliberately does NOT do
The skill has an explicit When NOT to Use section, because an audit tool that overclaims is worse than one with clear limits:
- Runtime testing — this is static analysis only. Pair it with DAST tools like ZAP or Burp Suite.
- Penetration testing — it identifies vulnerabilities; it does not exploit them.
- Compliance certification — findings inform compliance work; they are not a formal audit.
- General code review — use a code reviewer for that.
Where it's going
Since the first release, the roadmap has been moving from "one-shot audit" toward a workflow: CVSS v4.0 scoring for findings (as an evidence-based assessment workflow, with unscored findings reported explicitly rather than guessed), custom user-defined detection rules, and local continuous monitoring. Auto-fix PRs and external scanner integration (Semgrep / CodeQL) are in progress.
Try it, break it, tell me
The skill is MIT-licensed and built for the stacks I work on every day as an SRE — which means it is opinionated, and I'd genuinely like to know where those opinions are wrong for your stack.
- ⭐ GitHub: https://github.com/toshipon/claude-code-security-audit-skill
- Issues and PRs welcome — a new stack usually means adding one reference file
I'm toshipon — an SRE and security-focused indie hacker in Japan, and founder of BUILD GEEKS. I run fixed-scope security audits for teams shipping AI-built software. If your team builds with Claude Code or other AI agents and wants an evidence-based audit — not a generic checklist — DM me on X.
Top comments (5)
The list of rationalisations to reject is what sold me on this. I've heard 'it's behind authentication' and 'the framework handles it' used to wave away real findings more times than I can count, so hard-coding those as things the skill must push back on feels like it comes from actual audit work, not a checklist. The dashboard angle is the part I keep coming back to too — Vercel Deployment Protection and Supabase Auth settings genuinely live where no CLI can see them. How does the Chrome MCP step cope when a dashboard needs an interactive login or MFA? Does it flag that section as unchecked rather than quietly passing it? That's the bit that would decide whether I'd trust a green-looking report.
That's exactly the right question — and the dashboard part only works because it's your browser. The checks run through Chrome MCP in a browser session you control: if a dashboard asks for an interactive login or MFA, you complete that authentication yourself in the browser. The skill doesn't bypass it, and shouldn't.
Anything that still can't be reached after that is reported as unchecked rather than quietly passed — a green section should mean "verified", not "couldn't look".
Glad the rationalizations list landed. Those came from real audits — including excuses I've made myself.
The evidence-first rule is the part I would keep even if I used only a slice of this skill, because a security finding without a file path and a concrete fix tends to get argued about instead of fixed. I also like the explicit rejection of excuses such as "it's behind authentication", since that is exactly how real audit reports get watered down. One practical addition would be to record every unchecked item as an open task rather than letting it disappear from the report, so the next run can show whether coverage actually improved. For readers comparing curated skill collections in Chinese, the repository at github.com/laolaoshiren/claude-cod... is a useful place to see how different skills are organized side by side. That comparison makes it easier to judge whether a single-purpose audit skill or a broader collection fits a team's workflow.
대시보드에서만 확인할 수 있는 설정을 코드 검사와 분리하고, 현재 값과 수동 조치까지 남기는 형식이 실용적이네요. 접근 권한이나 연결 문제로 확인하지 못한 항목도 안전하다고 간주하지 않고 ‘미확인’으로 별도 집계하면 감사 범위를 더 명확히 전달할 수 있겠습니다. 정적 분석과 실제 침투·인증을 구분한 한계 설명도 좋았습니다.
Thanks for the careful read. That's the intent: items that can't be verified — no access, connection issues, an authentication step the user hasn't completed — are tallied separately as "not verified" rather than treated as safe, so the audit scope stays explicit. Same philosophy as the limitations section: static analysis shouldn't borrow credibility from penetration testing it never did.