How I Built a Full-Stack Security Audit Skill for Claude Code
I got tired of starting security audits from scratch every time.
My stack spans Next.js, Vercel, Supabase, and iOS, and each layer has different security concerns. OWASP is comprehensive, but remembering what to check — and in what order — was becoming its own problem.
So I turned the process into a Claude Code Skill.
It runs a 6-phase audit across the stack and combines:
- CLI checks
- SQL checks
- Chrome MCP for dashboard-only settings
That last part was important for things like:
- Vercel Deployment Protection
- Git Fork Protection
- Supabase Auth settings
- Supabase Security Advisor findings
A few design decisions made it much more usable than one long prompt:
- Progressive disclosure → keep SKILL.md small, move details into references
- Evidence-first → every check should point to actual code, config, grep output, or SQL results
- OWASP-aligned structure → easier to reason about and easier to share with other engineers
The main benefit wasn’t convenience — it was repeatability.
Instead of relying on memory, I can now start from a standard entry point and run the same full-stack audit process whenever I need it.
Wrote it up here:
https://dev.to/toshipon/how-i-built-a-full-stack-security-audit-skill-for-claude-code-4nkk
Curious how other people here approach security reviews in small teams or solo projects.
Do you rely on checklists, prompts, automation, or mostly manual review?
This is a great approach. The repeatability piece is the key insight, most security misses on solo projects happen because reviews only happen once at launch, not after every big feature push. One thing worth layering on top of an LLM-based audit: a dedicated Security Analysis tool that does not rely on the model remembering to check certain patterns. LLMs are surprisingly good at finding logic issues but can miss lower-level injection vectors. Running both together catches more of the surface area.