Secure Coding Before the First Keystroke
When did a security review ever arrive early enough to matter? By the time it shows up, the architecture is poured, the threat model is whatever the developer imagined in their head, and the fix costs ten times what it would have cost on day one. We all know this. We keep doing it anyway.
Here’s the moment that finally got under my skin.
I watched an AI coding assistant cheerfully write me a SQL query by gluing user input straight into a string. No hesitation, no warning, just a friendly little SELECT * FROM users WHERE id = + whatever the browser sent. The kind of thing that gets you pwned before lunch. And the assistant was proud of it.
So I built claude_secure_coder.
The old way: security at the end
The default Claude Code workflow puts security last. Write the code, then run a review pass over the wreckage. By then the vulnerabilities are baked in and expensive.
Mature security teams work the other way around. They teach the patterns first, design with threats in mind, get feedback while the code is being typed, and let review catch only the leftovers. That’s the whole idea of “shift left” — and this is shift-left taken to its logical end. The review happens before the first keystroke lands.
The new way: four layers, each covering the last one’s blind spot
claude_secure_coder wraps Claude Code in four layers, and each one exists to catch what the previous one misses.
- Teach. At session start, it injects the OWASP Top 10:2025, the CWE Top 25, the OWASP AST10 for agentic AI, and per-language rules into Claude’s context — before you’ve typed a word. The model walks in already knowing what not to do.
- Design. A
ThreatModelskill runs at planning time: STRIDE for traditional apps, MAESTRO for agentic AI. You model the threats before you model the database. - Write. This is the part I love. A PreToolUse hook fires on every single edit in under 200 milliseconds and hard-blocks literal secrets and flags dangerous APIs and weak crypto. Then a PostToolUse pass runs semgrep, trufflehog, and gitleaks and feeds whatever it finds back as rewrite guidance.
- Review. Your existing review tooling stays — but now it’s a backstop, not the primary defense.
The split matters: PreToolUse hard-blocks, PostToolUse advises. Blocking has to be instant and certain, so only the deterministic stuff (literal keys, banned imports) lives there. The slow, thoughtful scanners run after and suggest.
The details that make it livable
Security tooling that cries wolf gets turned off. So test files, specs, and fixtures only get advisories on secret findings — your fake test key doesn’t halt the build. And when a match really is a false positive, a // nosec: <rule_id> on the line makes it go away. On purpose, documented, in the diff.
It works with stock Claude Code or with Daniel Miessler’s PAI, and it’s Apache 2.0 — because the explicit patent grant actually matters for security tooling that ends up inside somebody’s commercial product.
Stop finding your SQL injection in review. Teach the model not to write it.