I Taught Claude Code to Be a Security Auditor.

Let me paint you a picture.

You have been building a Laravel API for six months. You know this codebase. You wrote most of it. You are proud of it. It has tests. It has a proper folder structure. The README is actually up to date, which alone puts you in the top five percent of developers.

Then you run /security-audit on it.

And Claude comes back with a CRITICAL finding. SQL injection vector. In code you wrote. Three months ago. Code you reviewed. Code you merged yourself.

You stare at it. You close the laptop. You go make coffee. You come back. It is still there.

This is what security audits are for.

Why I Built This

I am a Laravel Technical Lead. Most of my projects touch sensitive data. Water utility billing systems. Government platforms. Payment flows. The kind of stuff where a security failure is not just embarrassing, it is a problem that involves lawyers.

I have always known that proper security audits should happen on these projects. I have also always known that proper security audits are expensive, slow and usually happen once a year if you are lucky. The rest of the time you are trusting that your developers are writing secure code and that your code reviews are catching the bad patterns.

They are not. Not consistently. Not across 850 possible attack vectors.

So I built a Claude Code slash command that does it for you.

What It Does

claude-security-audit is a slash command you install into Claude Code. You type /security-audit in any project and Claude reads your entire codebase, runs it against a comprehensive security checklist and produces a structured report mapped to the frameworks your clients and compliance teams actually care about.

One command. One report. Done.

The frameworks covered:

OWASP Top 10:2025 (all ten categories, including the two new ones in 2025). NIST CSF 2.0. CWE. SANS/CWE Top 25. OWASP ASVS 4.0. PCI DSS 4.0. MITRE ATT&CK v15. SOC 2. ISO 27001:2022.

Every finding is tagged to the relevant framework IDs. So when your client asks whether you are compliant with ISO 27001 Annex A, you have an actual answer backed by analysis, not just “yes we follow best practices” said with the confidence of someone who has not actually checked.

The checks:

850+ individual checks across 18 attack categories. The obvious stuff is in there: SQL injection, XSS, CSRF, authentication failures, broken access control. But also things that often get missed: prompt injection if you are building AI features, WebSocket security, gRPC security, serverless misconfigurations, supply chain failures and business logic flaws.

There is even a gray-box testing phase that probes role-based access, checks whether your rate limiting is actually enforced and looks for error differential leaks, which is when your application returns different error messages for valid versus invalid usernames, which tells an attacker exactly which accounts exist.

The Bit That Makes It Actually Useful

Security tools that produce fifty-page reports are not useful. They are anxiety documents. You read them once, feel terrible about everything and then do nothing because you do not know where to start.

This report is structured differently:

Executive Summary with finding counts and a risk assessment you can actually hand to a client
OWASP and NIST coverage matrices
Critical and High findings first, with the vulnerable code block and what to fix
Medium findings
Low and informational
Gray-box results
Security hotspots for PR reviews
Code smells that breed security bugs over time

If you run it with --fix, it adds copy-paste remediation code blocks. If your codebase is large and you just want to know if your latest PR introduced anything bad, you run /security-audit diff:main and it scans only the changed files. Fast. Cheap on tokens. Focused.

The framework detection is also worth mentioning. If you are running Laravel, it loads the Laravel-specific checklist. Eloquent mass assignment. Laravel authorization bypass patterns. Config exposure via .env. The things that are specific to how Laravel projects break, not just generic web security checks. Same goes for Next.js, FastAPI, Express, Django, Rails, Spring Boot, ASP.NET Core, Go and Flask.

The Token Situation (Be Honest About This)

This is a token-intensive tool. I am not going to pretend otherwise.

A full audit on a large project can use up to 210K tokens. That is real money if you are hitting the API directly. On Claude Pro or Max with the subscription, it digs into your usage limit.

This is why I built multiple modes:

quick --lite is your everyday sanity check. Around 30-80K tokens. OWASP, CWE and NIST only, Critical and High findings. Good for catching the serious stuff fast.
diff --lite is for PR reviews. Scans only changed files. Around 20-40K tokens. This is the one you should be running before every merge.
full is for thorough audits before major releases or client deliveries. Save it for when it matters.

The --lite flag strips out the extra compliance mapping for SANS, ASVS, PCI DSS, MITRE ATT&CK, SOC 2 and ISO 27001. If you do not need those frameworks, skip them. Use --fix only when you actually want remediation code because it adds roughly 50% to your report output tokens.

Installing It

curl -fsSL https://raw.githubusercontent.com/afiqiqmal/claude-security-audit/main/install.sh | bash

That is it. One line. The installer puts the slash command at ~/.claude/commands/security-audit.md and the reference files in ~/.claude/security-audit-references/. Available in every project globally from that point.

If you want it scoped to a single project only, copy the command file into .claude/commands/ in that project and use /project:security-audit.

What It Keeps Finding

I have been running this on my own projects since I built it. The findings that keep appearing, the ones that show up in codebase after codebase, are not the exotic ones.

They are the boring ones.

Logging of sensitive data. The application logs request bodies for debugging. The request body contains passwords, tokens and sometimes credit card numbers. Classic. Embarrassing. Found in almost everything.

Overly broad role permissions. The admin check is there but it is checking is_admin on the user object instead of going through a proper authorization layer. Works fine until someone finds a way to set is_admin: true through a mass assignment vulnerability. Which the tool also finds.

Missing rate limiting. Documented in the code comments, referenced in the README, not actually implemented in the middleware.

Error messages leaking information. The 404 response for a valid user ID that does not match the authenticated user returns a different error than a completely nonexistent user ID. Your attacker now has a user enumeration tool.

None of these are sophisticated attacks. They are the kind of thing that should be caught in code review. The problem is that code review is done by developers who are tired, who are focused on whether the feature works and who are not running through an 850-point security checklist before approving the PR.

Claude is not tired. Claude does not approve PRs to be polite. Claude will find the logging vulnerability at 3am on a Sunday with the same cheerfulness it brings to everything.

Custom Checks

If you have company-specific security standards or internal API rules, you can add your own checklists. Drop .md files into ~/.claude/security-audit-custom/ for global rules or .claude/security-audit-custom/ inside a project for project-specific ones.

The format is straightforward. Headings with OWASP and NIST tags, checklist items under each heading. The tool merges your custom checks with the built-in ones and runs them together.

For shops that need to enforce specific compliance rules on every project, this is the bit that makes it genuinely useful as a team tool rather than a personal one.

Is This a Replacement for a Real Security Audit?

No.

A real penetration test, done by actual humans who are trying to break your system, is different. They will find things Claude will not find because they are creative and adversarial in ways that a checklist-driven audit cannot fully replicate.

What this is a replacement for is the security check you were not doing at all. The code review that skipped the security angle because you were behind on the deadline. The audit you planned to schedule and never scheduled. The OWASP review that was supposed to happen before launch and happened in no one’s calendar.

Running this is better than not running anything. Running it on every PR is dramatically better than running a real penetration test once a year and assuming you are fine in between.

Good security is boring, repetitive and consistent. That is exactly what a slash command is good at.

The repo is at github.com/afiqiqmal/claude-security-audit. MIT licensed. Pull requests welcome, especially framework-specific checklists for anything I have missed.

And if you run it on your codebase and find something embarrassing, do not worry. We all have the logging vulnerability. You are not alone.