Claude Code just shipped a built-in security-guidance plugin — a 3-layer review that runs a pattern check, a model review, and a commit check before code lands. It's a real upgrade. But here's the catch: generic security review doesn't know your project.
It doesn't know which fields are nullable. It doesn't know that one of your APIs is deprecated and must never be called again. It doesn't know your auth layer, your tenant isolation, or the one query path that must stay read-only. The built-in review catches the textbook stuff. The bugs that actually ship are the project-specific ones.
The fix is your CLAUDEmd file. A few targeted rules turn that 3-layer review from "generic linter" into "senior security engineer who knows this codebase." Below are 10 copy-paste rules to drop in today, plus stack-specific sections for Node.js, Python, and databases.
Want the complete set? The CLAUDEmd Rules Pack has 27 production-tested rules covering security, workflow, commits, testing, and code quality → oliviacraftlat.gumroad.com/l/skdgt ($27)
Why generic security review misses your bugs
The new plugin reviews against patterns it already knows: hardcoded secrets, eval(), unparameterized SQL, disabled TLS. Great defaults. But three categories slip through every time:
- Your domain invariants. "This balance field can never go negative." "This endpoint is internal-only." The reviewer has no way to know.
- Your deprecated surface. That old token-minting helper you replaced last quarter — the model will happily reach for it again unless you tell it not to.
- Your architecture. Which layer owns auth? Which credentials are read-only? Where does untrusted input enter? Without that map, the review treats every file as a blank slate.
CLAUDEmd is where you write the map. The plugin reads it as context on every review.
The fix: 10 core rules to make review project-specific
Drop this block into your CLAUDEmd. It works for any stack and gives the security review concrete things to enforce.
# Security
- Never hardcode secrets, API keys, tokens, or credentials — use environment variables
- Never log sensitive data: passwords, tokens, PII, financial data, or anything with "key", "secret", "token", "password" in the field name
- Always validate and sanitize user input before using it in SQL queries, shell commands, file paths, or HTML
- Never use eval(), exec(), or equivalent dynamic code execution with user-controlled input
- Use parameterized queries — never string-concatenate SQL with user data
- When generating file paths from user input, validate against a whitelist of allowed directories
- Never disable SSL/TLS verification, even in development scripts
- Before adding a new dependency, check it has recent commits and >1 maintainer
- Never store sensitive data in localStorage, sessionStorage, or browser cookies without encryption
- When a function touches auth, payments, or user data — stop and ask before proceeding
The last rule is the one that pays for itself. "Stop and ask before proceeding" turns the AI from a confident guesser into a collaborator on exactly the code paths where a wrong guess is most expensive.
Web / API projects
If you ship HTTP endpoints, add this. The built-in review won't enforce your header policy or your upload validation strategy unless you state it.
# Security — Web
- Set Content-Security-Policy, X-Frame-Options, and HSTS headers on all responses
- Rate-limit authentication endpoints — never allow unlimited login attempts
- Use CSRF tokens on all state-changing forms and API endpoints
- Never trust user-supplied Content-Type — validate file uploads by content, not extension
- Redirect after POST — never render sensitive data in GET URLs
Stack-specific sections
Node.js / backend
# Security — Node.js
- Use helmet() middleware on all Express apps
- Never use child_process.exec() with unsanitized input — use execFile() with argument arrays
- Set NODE_ENV=production before running security-sensitive processes
- Never expose stack traces or error internals to API responses
- Use crypto.randomBytes() for tokens — never Math.random()
The exec() vs execFile() rule is a perfect example of project-specific value: a generic reviewer might flag some command injection, but stating the preferred API means the AI writes the safe version the first time instead of getting corrected on review.
Python
# Security — Python
- Use subprocess.run() with a list of arguments — never shell=True with user input
- Use secrets module for tokens — never random module
- Never use pickle.loads() on untrusted data
- Use django.utils.html.escape() or equivalent before inserting user content into templates
- Run bandit on any security-sensitive module before committing
That last line wires a real tool into the loop. Telling Claude Code to run bandit before committing means the model review and your static analyzer agree on what "secure" means for this repo.
Database
# Security — Database
- Use ORM methods or parameterized queries — never f-strings or .format() in SQL
- Never SELECT * in queries that return to the API — enumerate required columns
- Use read-only database credentials for query-only operations
- Never store plaintext passwords — use bcrypt, argon2, or scrypt
Never SELECT * is the kind of rule no generic security plugin will ever enforce — it's a data-exposure guardrail specific to how your API serializes rows. Write it down once; the reviewer enforces it forever.
How to roll this out
- Paste the core block into your CLAUDEmd today.
- Add the stack sections that match your project.
- Append 3–5 rules that encode your invariants — deprecated functions, internal-only endpoints, fields that must never be logged.
- Let the security-guidance plugin do the rest. It now reviews against rules that actually describe your codebase.
The plugin is the engine. CLAUDEmd is the steering. Generic review keeps you off the obvious cliffs; project-specific rules keep you out of the ditches only you know about.
Get the full 27-rule set
These 10 rules are the security slice. The complete CLAUDEmd Rules Pack adds 17 more covering workflow, commit hygiene, testing discipline, and code quality — all tested on real projects so the AI writes code you'd actually merge.
By @OliviaCraftLat. Building tools that make AI coding agents write code you can ship.
Top comments (0)