How to Secure Your Vibe-Coded Project (Before It Secures You)

Look, I’m going to be honest with you. Most of us build our side projects like we’re in a caffeine-fueled montage — fast commits, duct-taped logic, and a silent prayer that it’ll hold together in prod. It’s not engineering. It’s vibe coding.

You tell yourself, “I’ll clean this up later,” but “later” somehow turns into “never.” And before you know it, your vibe-coded masterpiece has a security posture that could double as a horror story.

When was the last time you actually looked at your entire codebase from a security perspective?

And no, that time you grepped for “password” after three beers doesn’t count.

That’s where the /security-audit command comes in — the full paranoia sweep your vibe-coded project never knew it needed. It’s built to scan everything: your code, configs, dependencies, and all those “temporary” secrets you definitely meant to rotate six months ago.

Oh, and by the way — it’s not just for vibe-coded projects. If your repo is more “enterprise production” than “midnight chaos,” you can still use it. Just run /init first to set up your environment, then unleash the audit.

Because vibe-coded or not, your codebase probably has skeletons. /security-audit just helps you find them before someone else does.

If you’re using Claude Code for development, you might already know about Anthropic’s /security-review command. t’s that neat little tool that tells you your PR has SQL injection vulnerabilities right before you hit merge (sorry about that).

But here’s the uncomfortable truth: /security-review only looks at what you’re changing right now. What about that authentication system you copy-pasted from Stack Overflow in 2022? Yeah, that’s still there. Still vulnerable. Still waiting to make you famous on HackerNews for all the wrong reasons.

The Uncomfortable Truth: Your Security Theatre Has Two Acts

Teams typically perform security reviews in two very different contexts, and most of us are only doing one of them:

Act One: The “I Swear I’ll Do It Better Next Time” Review - This is your PR review. You’re checking the code you literally just wrote. Your coffee is still warm. The context is still loaded in your brain’s RAM. This is what /security-review does brilliantly.

Act Two: The “Oh God, What Have We Done” Audit - This is when someone (usually an auditor, your CTO, or that one paranoid investor) asks to see the security posture of your entire codebase. This is usually triggered by:

• Compliance requirements (because your lawyer said so)

• A security incident (translation: you got owned)

• That legacy authentication code you inherited (RIP to whoever wrote that)

• Onboarding actual security practices (welcome to being a real company)

• The calm before the storm (pre-release sanity checks)

Anthropic’s /security-review absolutely nails Act One. It’s like having a paranoid senior developer sitting next to you during code review, but the developer is an AI and doesn’t judge you for that nested ternary operator. It focuses on high-confidence vulnerabilities in your branch changes, which is perfect when you’re iterating fast and need quick feedback.

But Act Two? That’s been a manual nightmare. Until now.

Enter: The Full-Stack Paranoia Command

I built /security-audit because I got tired of pretending my legacy codebases were fine.

Spoiler alert: they were not fine. They were approximately as secure as a screen door on a submarine.

This command does what /security-review does, but for your entire codebase. It’s the difference between checking if your front door is locked versus doing a full security sweep of your house, including that basement you’ve been avoiding.

What Makes It Different? (Or: Why You Need Both)

Let me break this down in a way that won’t put you to sleep:

Scope: /security-review looks at your branch changes. /security-audit looks at everything. Yes, including that utils folder you haven’t touched since the Obama administration.

Use Case: One is for “did I just introduce a vulnerability?” The other is for “how vulnerable is my entire operation?”

Confidence Levels: /security-review only shows you the slam-dunks (≥80% confidence) because during PR reviews, false positives are annoying. /security-audit shows you anything suspicious (≥30% confidence) because when you’re doing a full audit, you actually want to investigate the maybes.

Dependencies: /security-review focuses on your code. /security-audit also scans your dependencies for known CVEs. You know, those 847 npm packages you installed because someone on Twitter said they were cool.

The Security Frameworks (Or: Fancy Names for “Ways Your App Can Get Owned”)

The audit implements the security frameworks that auditors actually care about. Not just random checks, but the industry-standard lists that folks smarter than us spent years compiling:

OWASP Top 10 2021 - The greatest hits of web security failures:

• Broken Access Control (AKA “oops, anyone can access anyone’s data”)

• Cryptographic Failures (AKA “we’re using MD5 in 2025”)

• Injection vulnerabilities (AKA “Little Bobby Tables strikes again”)

• Security Misconfiguration (AKA “debug mode is still on in prod”)

• And six more exciting ways your app is probably broken

OWASP API Security Top 10 2023 - Because your REST API is probably broken too:

• Broken Object Level Authorization (fancy way of saying “your API doesn’t check who’s asking”)

• Unrestricted Access to Sensitive Business Flows (NEW! Now you can accidentally DOS yourself)

• Server-Side Request Forgery (NEW! Let attackers use your server as a proxy)

• Unsafe Consumption of APIs (NEW! Trust issues, but for APIs)

• Plus six more creative ways to expose your data

Plus the Usual Suspects:

• Cloud Security (your S3 bucket is public again)

• Infrastructure & DevOps (yes, your Docker containers need updates)

• Supply Chain Security (that npm package was hijacked 3 months ago)

• Dependency vulnerabilities (remember when you pinned that version in 2022?)

How This Thing Actually Works

Usage is straightforward. Run this bad boy in your claude code session:

/security-audit

Then Claude Code turns into that friend who starts pointing out every health code violation when you take them to your favorite restaurant. Except instead of restaurants, it’s your codebase. And instead of health code violations, it’s security vulnerabilities. Here’s what happens:

Step 1: Reconnaissance - Claude maps your tech stack. It’s like those heist movies where they study the building blueprints, except the building is your application and the heist is finding all the ways it’s broken.

Step 2: Code Analysis - Every. Single. File. Gets examined. Yes, even that one. Especially that one.

Step 3: Configuration Review - Checks your environment variables, deployment configs, and all those “temporary” configurations that became permanent.

Step 4: Dependency Scanning - Looks at every library you’re using. Spoiler: at least three of them have known vulnerabilities and one hasn’t been maintained since the pandemic.

Step 5: The Reckoning - Generates a comprehensive report that you’ll either immediately share with your team or bury deep in your file system depending on how bad the results are.

What You Actually Get (Sample Output)

The report doesn’t sugarcoat things:

# Security Audit Report
**Date**: 2025-10-30
**Files Analyzed**: 247

## Executive Summary
Found 3 critical, 8 high, 12 medium severity issues.
(Translation: Drop everything and fix the critical ones yesterday.)

## Critical Findings (Fix These Before Your Next Standup)
### 1. SQL Injection in User Search
- **Location**: `api/users/search.js:45`
- **Severity**: CRITICAL (as in, stop reading this and fix it now)
- **OWASP Category**: A03:2021 - Injection
- **Exploit Scenario**: Attacker can extract entire database 
  (including your production passwords table you forgot to hash)
- **Remediation**: Use parameterized queries
  (like you learned in that tutorial you bookmarked in 2019)

[More bad news with specific line numbers and fixes...]

## Dependency Vulnerabilities
- express@4.16.0 - CVE-2022-24999 (HIGH)
  ↪ That version is from 3 years ago. Upgrading takes 5 minutes.
  
- lodash@4.17.15 - CVE-2021-23337 (MEDIUM)
  ↪ Everyone uses lodash. Everyone forgets to update lodash.

Every finding includes:

• Exact file and line number (no hide and seek)

• Severity level (so you can prioritize or panic accordingly)

• OWASP category (for your compliance paperwork)

• Exploit scenario (so you can explain to your boss why this matters)

• Actual remediation steps (not just “fix it”)

Real Humans, Real Vulnerabilities, Real Relief

The Compliance Scramble: “We got SOC 2 certified and the auditor wanted a security assessment. I ran /security-audit on Friday afternoon thinking I’d have a chill weekend. I did not have a chill weekend. But we passed the audit, so there’s that.”

The Legacy Code Nightmare: “Our authentication system was written by a contractor in 2022 who is now unreachable. The audit found three different crypto vulnerabilities and dependencies that were literally marked as ‘critical security advisory’ on npm. We fixed everything over a weekend and slept much better afterward.”

The “This Could’ve Been Us” Moment: “We had a security incident with one of our API endpoints. After fixing the immediate issue, we ran /security-audit and found the exact same vulnerability pattern in four other places. Those would’ve been four more incidents if we hadn’t caught them.”

Installation: Less Painful Than Your Last Dentist Visit

For Global Use (All Your Projects Get the Benefit):

# Clone it
git clone https://github.com/badri/claude-code-security-audit.git

# Install it globally
mkdir -p ~/.claude/commands
cp claude-code-security-audit/.claude/commands/security-audit.md ~/.claude/commands/

# Now every project gets paranoia-checked

For One Specific Project (Just This One Needs Help):

# Put it in your project
mkdir -p .claude/commands
cp claude-code-security-audit/.claude/commands/security-audit.md ./.claude/commands/

# Commit it so your team can’t ignore security anymore

The Optimal Security Workflow (Or: How to Sleep at Night)

Use both commands like they’re peanut butter and jelly. They’re better together:

Daily/Weekly PR Reviews with /security-review:

• Fast feedback while context is hot

• Catches issues before they hit main

• High-confidence findings only (no noise during iteration)

• Your team doesn’t hate you for blocking their PRs with false positives

Monthly/Quarterly Audits with /security-audit:

• Comprehensive sweep of everything

• Catches the stuff that slipped through PR reviews

• Dependency updates and configuration drift

• The stuff that compliance auditors care about

• Lower-confidence findings that deserve investigation

Think of it this way: /security-review is your daily vitamins. /security-audit is your annual physical. You need both.

The Awkward Conversations This Tool Starts

After running your first audit, you’ll probably need to have some conversations:

With your team: “Hey, remember that authentication system we copied from that tutorial? Yeah, about that...”

With your boss: “Good news! We found all our security vulnerabilities. Bad news? There were vulnerabilities to find.”

With yourself: “I am never again installing a package without checking when it was last updated.”

What Comes Next

The tool is open source at github.com/badri/claude-code-security-audit because I believe in radical transparency about security tooling. Plus, I want your contributions:

• More security frameworks (SANS Top 25, CWE Top 25)

• Language-specific patterns (your Python is different from my Node.js pain)

• Better remediation guidance (not just “fix it” but “here’s how”)

• Real-world examples (show me your audit wins)

Key Takeaways (The TL;DR You Were Looking For)

1. /security-review is your PR security guardian. Use it daily.

2. /security-audit is your periodic reality check. Use it monthly.

3. Together they form a complete security workflow that doesn’t require hiring a security team (yet).

4. Both leverage Claude Code’s ability to actually understand your code context, not just run regex patterns.

5. Built on frameworks that auditors recognize (OWASP, CVE databases, the fancy acronyms).

The Part Where I Tell You to Try It

Whether you’re:

• Preparing for a compliance audit (welcome to enterprise life)

• Haven’t done a security review in [checks calendar] way too long

• Just acquired a legacy codebase and need to assess the damage

• Want to sleep better knowing your security posture isn’t complete fiction

Give /security-audit a try. Install it. Run it. Maybe pour a drink first. The truth can be uncomfortable, but it’s better than learning about your vulnerabilities from a HackerNews post titled “How I Hacked [Your Company Name].”

---

Useful Links for Your Journey:

• /security-audit on GitHub

• Anthropic’s /security-review

• Claude Code Docs

• OWASP Top 10 2021 (your bedtime reading)

• OWASP API Security Top 10 2023 (more bedtime reading)

---

Found something interesting when you ran the audit? Have war stories about security vulnerabilities? I want to hear them. The schadenfreude sustains me. (Also, we all learn from each other’s mistakes, which is the professional way to say it.)

P.S. - The Thing Nobody Wants to Admit

We all ship code with security issues. Every single one of us. The difference between a secure codebase and an insecure one isn’t whether vulnerabilities exist—it’s whether you’re actively looking for them and fixing them when you find them.

This tool makes it easier to look. The fixing part is still on you(Psst, in case you didn’t realize by now, claude code can fix it for you, and that will be a future post). But at least now you’ll know what needs fixing before someone else does.

Now go run that audit. I’ll wait.