I Built a Claude Code Slash Command for OWASP Top 10:2025, NIST CSF 2.0 and 850+ Security Checks

--- title: "I Built a Claude Code Slash Command for OWASP Top 10:2025, NIST CSF 2.0 and 850+ Security Checks" published: true description: "A /security-audit slash command for Claude Code that runs white-box and gray-box security analysis mapped to OWASP 2025, NIST CSF 2.0, MITRE ATT&CK, PCI DSS 4.0, ISO 27001 and more. One command, one report." tags: security, claudecode, owasp, devtools cover_image: canonical_url: --- Security audits should happen on every project before every major release. In practice, they happen whenever someone puts it in the budget, which is usually once a year if the project is lucky. I built `claude-security-audit` to close that gap. It is a Claude Code slash command that runs a comprehensive white-box and gray-box security audit on any project, maps every finding to the compliance frameworks your clients and auditors care about and saves the report to your project root. One command. No setup per project. No external service. ## What It Is A Claude Code slash command (`/security-audit`) that: - Reads your entire codebase (or just the diff from a PR) - Runs 850+ security checks across 18 attack categories - Detects your framework and loads tailored checklists - Maps every finding to OWASP Top 10:2025, CWE, NIST CSF 2.0 and more - Outputs a structured report to `./security-audit-report.md` **GitHub:** https://github.com/afiqiqmal/claude-security-audit ## Install ```bash curl -fsSL https://raw.githubusercontent.com/afiqiqmal/claude-security-audit/main/install.sh | bash ``` This installs the slash command globally at `~/.claude/commands/security-audit.md` and the reference files at `~/.claude/security-audit-references/`. Available in every project from that point forward. For per-project install only: ```bash cp -r .claude/commands/security-audit.md /path/to/your-project/.claude/commands/ ``` Then use `/project:security-audit` inside that project. ## Usage ```bash # Full audit: white-box + gray-box + hotspots + code smells /security-audit # Quick scan: CRITICAL and HIGH only, no gray-box /security-audit quick # Diff mode: scan only changed files (good for PR reviews) /security-audit diff /security-audit diff:main /security-audit diff:develop # Focused deep dives /security-audit focus:auth # Auth and authorization /security-audit focus:api # API security and input validation /security-audit focus:config # Config, supply chain, infrastructure # Run individual phases /security-audit phase:1 # Reconnaissance only /security-audit phase:2 # White-box analysis only /security-audit phase:3 # Gray-box testing only /security-audit phase:4 # Security hotspots only /security-audit phase:5 # Code smells only # Include remediation code blocks (off by default) /security-audit --fix /security-audit quick --fix /security-audit diff:main --fix # Lite mode: reduces token usage significantly /security-audit --lite # OWASP + CWE + NIST only /security-audit quick --lite # Cheapest useful scan /security-audit diff:main --lite --fix ``` ## Frameworks Covered Every finding is tagged to one or more of these: | Framework | Version | |-----------|---------| | OWASP Top 10 | 2025 | | CWE | 4.x | | NIST CSF | 2.0 | | SANS/CWE Top 25 | 2024 | | OWASP ASVS | 4.0 | | PCI DSS | 4.0 | | MITRE ATT&CK | v15 | | SOC 2 | 2017 | | ISO 27001 | 2022 | ## OWASP Top 10:2025 Coverage The audit explicitly tests all ten 2025 categories. Two of them are new: | # | Category | OWASP ID | Note | |---|----------|----------|------| | 1 | Broken Access Control | A01:2025 | Now includes SSRF | | 2 | Security Misconfiguration | A02:2025 | Moved up from #5 | | 3 | Software Supply Chain Failures | A03:2025 | **NEW** - expands "Vulnerable Components" | | 4 | Cryptographic Failures | A04:2025 | Moved from #2 | | 5 | Injection | A05:2025 | Moved from #3 | | 6 | Insecure Design | A06:2025 | Moved from #4 | | 7 | Identification and Auth Failures | A07:2025 | Unchanged | | 8 | Software and Data Integrity Failures | A08:2025 | Unchanged | | 9 | Security Logging and Alerting Failures | A09:2025 | Renamed, emphasis on alerting | | 10 | Mishandling of Exceptional Conditions | A10:2025 | **NEW** - fail-open logic, silent failures | ## Framework-Specific Checklists Claude detects your framework and loads a tailored checklist alongside the base checks. Currently supported: - Laravel - Next.js - FastAPI - Express - Django - Rails - Spring Boot - ASP.NET Core - Go - Flask For example, the Laravel checklist covers Eloquent mass assignment vectors, Laravel authorization bypass patterns, `.env` exposure, Sanctum and Passport token handling and queue job deserialization. Generic web checks miss these because they are framework-specific failure modes. ## Gray-Box Testing Beyond static analysis, the audit runs a gray-box phase that looks at your code the way a tester with partial knowledge would: | Area | What It Tests | |------|--------------| | Role-Based Access | Can lower-privilege roles reach higher-privilege endpoints? | | API Probing | Verb tampering, undocumented params, over-fetching, mass assignment | | Credential Boundaries | Expired tokens, revoked sessions, tenant isolation | | Partial Knowledge | Hidden endpoints from routes, IDOR via migration schema | | Rate Limit Verification | Is rate limiting actually enforced or just documented? | | Error Differentials | Do your errors leak resource existence? | The error differential check is one worth calling out specifically. If your application returns "User not found" for a nonexistent user ID and "Access denied" for a valid ID that belongs to someone else, you have just given an attacker a user enumeration tool. The audit flags this even if the authentication logic itself is correct. ## AI/LLM Security Checks If your project includes AI or LLM features, the audit runs additional checks for: - Prompt injection vectors - Output sanitization before rendering - RAG poisoning paths - Tool calling permission scopes - Cost monitoring and DoS via large context inputs This maps to A05:2025 and A01:2025. As more projects add AI features, these attack surfaces are becoming increasingly relevant. ## Report Structure The report at `./security-audit-report.md` is organized for both technical and non-technical readers: 1. Executive Summary (finding counts, risk assessment) 2. OWASP Top 10:2025 Coverage Matrix 3. NIST CSF 2.0 Coverage Matrix 4. Critical and High Findings (with vulnerable code block) 5. Medium Findings 6. Low and Informational 7. Gray-Box Findings (role, endpoint, expected vs actual) 8. Security Hotspots (PR review guidance) 9. Code Smells (patterns that breed security bugs) 10. Recommendations Summary (grouped by OWASP) 11. Methodology By default the report shows findings and descriptions. Append `--fix` to include copy-paste remediation code blocks. This is off by default because it adds roughly 50% to the output token count and is not always needed. ## Token Usage This is a token-intensive command. Be aware of this before running full audits on large codebases. | Mode | Estimated Total Tokens | |------|----------------------| | `quick --lite` | ~30-80K | | `diff --lite` | ~20-40K | | `quick` | ~50-100K | | `focus:auth` | ~40-75K | | `diff` | ~35-60K | | `full --lite` | ~75-170K | | `full` | ~90-190K | | `full --fix` | ~100-210K | **Recommended workflow:** - Use `diff --lite` for every PR review - Use `quick --lite` for regular development checks - Save `full` for pre-release audits or client deliveries ## Custom Checks Add your own security checklists to extend the built-in ones. | Folder | Scope | |--------|-------| | `~/.claude/security-audit-custom/` | Global - all projects | | `.claude/security-audit-custom/` | Project-level only | Format your checks with OWASP and NIST tags: ```markdown ## Internal API Standards [A01:2025, A05:2025 | PR.AA, PR.DS] - [ ] All internal endpoints require service-to-service auth tokens - [ ] Response bodies never include internal database IDs - [ ] Deprecated endpoints return 410 Gone ``` A template file is installed at `~/.claude/security-audit-custom/custom-template.md` during setup. Both global and project-level custom checks run alongside the built-in checks. Project-level checks do not override global ones, they are merged. ## Repository Structure ``` claude-security-audit/ ├── .claude/ │ └── commands/ │ └── security-audit.md # The /security-audit slash command ├── references/ │ ├── attack-vectors.md # 850+ checks tagged to OWASP/NIST/CWE │ ├── nist-csf-mapping.md # OWASP 2025-to-NIST cross-reference │ ├── compliance-mapping.md # CWE, SANS, ASVS, PCI DSS, ATT&CK, SOC 2, ISO 27001 │ ├── custom-template.md # Template for custom checks │ └── frameworks/ # Framework-specific checklists │ ├── laravel.md │ ├── nextjs.md │ ├── fastapi.md │ └── ... ├── security-audit-guidelines.md # Severity ratings and conventions ├── install.sh # One-command installer ├── CLAUDE.md # Project context for Claude Code └── README.md ``` ## What It Is Not This is not a replacement for a proper penetration test done by human security researchers. A skilled pentester will find things a checklist-driven audit will not, because they bring creativity and adversarial thinking that goes beyond predefined checks. What this replaces is the security check you were not doing at all. The code review that focused on feature correctness but skipped the security angle. The audit that was supposed to happen before the release and did not. Running `diff --lite` on every PR is a realistic habit that costs almost nothing and catches the class of vulnerabilities that show up repeatedly in production incidents: missing authorization checks, unvalidated inputs, sensitive data in logs, rate limiting that exists in documentation but not in code. --- **GitHub:** https://github.com/afiqiqmal/claude-security-audit MIT licensed. Pull requests welcome, especially for additional framework-specific checklists. If you build something on top of this or extend it for your stack, open a PR or drop an issue. The reference files are designed to be extended.