Claude Code has been part of my regular toolkit since not long after it launched as a research preview last year, and it's grown a real security feature set since. I think it's worth a specific, honest look at what's actually built in, because the pattern here is a little different from the publish-time scans I've written about on other platforms.
What's actually available
By August last year, Anthropic had added a /security-review slash command directly into Claude Code, along with an open-source GitHub Action version of the same check anyone can drop into their own CI pipeline. Run the command and it reviews your code for security issues the way you'd ask a knowledgeable colleague to look something over: real reasoning about your specific code, not just a pattern match against a fixed list.
More recently, in the last few weeks, a deeper capability called Claude Code Security entered limited research preview for Enterprise and Team customers, using more extensive reasoning to find less obvious vulnerabilities and suggest patches. It's new enough, and limited enough in availability right now, that I'd treat it as something to watch rather than something most people building solo or on a smaller plan can rely on yet.
The pattern that's different from Lovable or Bolt
Lovable and Bolt both run their security checks automatically, at the moment you publish, whether you think to ask for it or not. Claude Code's /security-review is opt-in: it's a real, useful command, and it does nothing until you actually type it. That's a meaningful difference for exactly the audience I usually write for. A builder who doesn't know to ask for a security review is in a different position with Claude Code than they are with a tool that checks automatically regardless.
Why this matters more than it might sound like it should
Nearly everything on this blog traces back to the same root cause: a check that existed but didn't get run, because nobody thought to run it. A powerful, well-built /security-review command changes nothing for someone who doesn't know that command exists, or doesn't think of security as a step to reach for deliberately. The tool being capable and the tool actually getting used are two different things, and the gap between them is exactly where most of the incidents I write about live.
What I'd actually recommend
- Run /security-review as a deliberate, standing habit, ideally before every meaningful deploy, not just when something already feels risky.
- If you're technical enough to set up CI, add the GitHub Action version so the check runs automatically on every pull request, removing the 'did I remember to ask' problem entirely.
- Don't wait for a fully automatic, always-on check to exist before you start using what's already there. The command works today, for free, and it works well.
- If you're on an Enterprise or Team plan, keep an eye on the newer, deeper capability as it moves out of limited preview. It's aimed at exactly the kind of less obvious vulnerability a simpler check can miss.
A genuinely good tool that requires you to remember to reach for it is still better than no tool at all. It's just a different kind of responsibility than a check that happens automatically whether you remember or not, and it's worth building the habit on purpose rather than assuming the tool is watching for you.