Skip to content
BSWEN
Blog

How to Run Security Review Before Pull Requests with Claude Code

Cowrie
Cowrie
Dev @ Bswen

Problem

I know I should run security reviews before merging code. But traditional tools are slow:

  • Full codebase scans take 10-30 minutes
  • Hundreds of false positives
  • Separate workflow from development

So I skip security reviews on “small” changes. Then I ship vulnerabilities.

Environment

  • Claude Code CLI
  • Git-based workflow
  • Feature branch development

The Solution: /security-review

Claude Code’s /security-review command analyzes your git diff for vulnerabilities. It only looks at changed code, so it’s fast - seconds, not minutes.

Basic usage
/security-review


# Output:
# HIGH: SQL injection risk in user_search()
# Location: app/services/user_service.py:45
# Recommendation: Use parameterized query

Step-by-Step Pre-PR Workflow

Step 1: Complete Your Feature

Commit your changes
git add .
git commit -m "feat: add user profile update endpoint"

Step 2: Review Changes First

Check what changed
/diff


# Shows all modified files with changes highlighted

Step 3: Run Security Review

Analyze for vulnerabilities
/security-review


# Analyzes only your git diff
# Returns findings with severity levels

Step 4: Address Findings

  • Critical: Fix immediately before PR
  • High: Evaluate and fix if handling user data
  • Medium/Low: Document rationale or fix

Step 5: Rollback if Needed

If security issues indicate design flaws:

Safe rollback
/rewind


# Revert to known-good state
# Redesign with security in mind

Step 6: Create PR with Confidence

Merge with security verified
gh pr create --title "feat: secure user endpoint" --body "
## Security Review
- Completed with Claude Code /security-review
- No critical or high severity issues found
"

Real-World Example

I recently added a user search feature. Here’s what happened:

Security review caught this issue
/security-review


# Output:
# HIGH: SQL injection risk in user_search()
# Location: app/services/user_service.py:45
#
# The 'name' parameter is concatenated directly into query
# Recommendation: Use parameterized query


# I checked the code:
query = f"SELECT * FROM users WHERE name = '{name}'"


# Fixed it:
cursor.execute("SELECT * FROM users WHERE name = ?", (name,))

Without this check, I would have shipped a SQL injection vulnerability.

Why This Matters

Speed

Traditional SAST: 10-30 minutes for full codebase /security-review: Seconds for changed code only

Precision

No false positives from unrelated code. Only flags issues in your changes.

Integration

No context switching to separate security tools. Run it right in your development flow.

Prevention

Catch vulnerabilities before they reach staging, let alone production. The cost of fixing security bugs in production is 10x higher than pre-merge.

What It Catches

Based on my experience and the Reddit discussion:

  • SQL injection in modified queries
  • Input validation issues in new code paths
  • Authentication bypasses in changed logic
  • Exposed secrets in configuration changes
  • XSS vulnerabilities in updated templates

The Reddit commenter reported catching 3 subtle input handling issues they would have shipped.

Common Mistakes

Mistake 1: Skipping “small” changes

Even 5-line changes can introduce vulnerabilities. The Reddit commenter catches issues in seemingly minor changes.

Mistake 2: Only running on production branches

Run on feature branches. Catch issues early when they’re cheaper to fix.

Mistake 3: Ignoring low-severity findings

Low severity issues can compound. Document why you’re not fixing, don’t just dismiss.

Mistake 4: Not using /rewind when needed

If security issues reveal design flaws, don’t patch. Rollback and redesign.

Mistake 5: Relying solely on automated tools

AI catches common patterns. Complement with code review for business logic flaws.

Complete Pre-Merge Checklist

Before every PR
# 1. Review changes
/diff


# 2. Security analysis
/security-review


# 3. For code handling user data, verify:
# - Input validation
# - Authentication checks
# - Authorization logic
# - Data sanitization


# 4. All checks pass?
gh pr create

Summary

In this post, I showed how to use Claude Code’s /security-review command before pull requests. The key points are:

  1. Fast - Analyzes only changed code, not entire codebase
  2. Effective - Catches subtle issues like input handling problems
  3. Integrated - No context switching from development workflow
  4. Prevention-focused - Catches vulnerabilities before they ship

The workflow is simple: /diff to review, /security-review to analyze, fix issues, then PR with confidence.

For code handling user data, this should be non-negotiable. The few seconds it takes prevents hours of dealing with security incidents in production.

Final Words + More Resources

My intention with this article was to help others share my knowledge and experience. If you want to contact me, you can contact by email: Email me

Here are also the most important links from this article along with some further resources that will help you in this scope:

Oh, and if you found these resources useful, don’t forget to support me by starring the repo on GitHub!

Comments

Tags: