Differential Security Review Framework

Focused security review methodology that analyzes code changes (diffs) for security implications, identifying vulnerabilities introduced or fixed in pull requests, commits, and releases.

When to Use This Skill

Choose Differential Security Review when:

• Reviewing pull requests for security implications
• Analyzing changes between release versions for security regressions
• Assessing the security impact of dependency updates
• Reviewing infrastructure-as-code changes for security misconfigurations
• Prioritizing security review effort on high-risk code changes

Consider alternatives when:

• Need comprehensive audit of entire codebase — use full security audit
• Need automated scanning without human review — use SAST/DAST
• Reviewing architecture or design — use threat modeling

Quick Start

Copy
# Activate differential security review
claude skill activate advanced-differential-security-review-framework

# Review a PR for security
claude "Security review the changes in PR #245"

# Compare releases
claude "Differential security review between v2.3.0 and v2.4.0"

Example Security Diff Review

Copy
// Pull Request: "Add user search endpoint"
// Security Review Notes:

+ app.get('/api/users/search', async (req, res) => {
+   const { query } = req.query;
+   // SECURITY ISSUE: SQL injection via string concatenation
-   const users = await db.query(`SELECT * FROM users WHERE name LIKE '%${query}%'`);
+   // FIX: Use parameterized query
+   const users = await db.query(
+     'SELECT * FROM users WHERE name LIKE $1',
+     [`%${query}%`]
+   );
+
+   // SECURITY ISSUE: No rate limiting on search endpoint
+   // RECOMMENDATION: Add rate limiter middleware
+
+   // SECURITY ISSUE: Returns all user fields including password hash
-   res.json(users);
+   // FIX: Select only needed fields
+   res.json(users.map(({ id, name, email }) => ({ id, name, email })));
+ });

Core Concepts

Review Focus Areas by Change Type

Change Type	Security Focus	Risk Level
Authentication code	Credential handling, session management, MFA bypasses	Critical
Authorization logic	Permission checks, role escalation, IDOR	Critical
Input handling	Injection, XSS, path traversal, deserialization	High
API endpoints	Rate limiting, authentication, data exposure	High
Dependencies	Known CVEs, supply chain attacks, version pinning	High
Configuration	Secrets exposure, debug settings, CORS	Medium
Database queries	SQL injection, data leakage, access controls	High
File operations	Path traversal, upload validation, temp file handling	Medium
Error handling	Information leakage, stack traces, error codes	Low
Logging	PII logging, credential logging, log injection	Medium

Diff Analysis Methodology

Step	Action	Output
Scope	Identify changed files and their security relevance	Risk-ranked file list
Context	Understand the purpose and data flow of changes	Change context map
Pattern Match	Check for known vulnerability patterns in new code	Finding list
Regression	Verify existing security controls aren't weakened	Regression checklist
Dependencies	Check for vulnerable dependency additions/updates	Dependency report
Configuration	Review config changes for security implications	Config findings
Summary	Prioritized security findings with remediation	Review report

Copy
# Useful git commands for differential review
# Show changes between branches
git diff main..feature-branch -- '*.ts' '*.js'

# Find security-relevant changes
git diff main..feature-branch | grep -E "(password|secret|token|auth|session|cookie|cors|sql|query)"

# List changed files by risk category
git diff --name-only main..feature-branch | grep -E "(auth|security|middleware|config)"

# Show changes to dependency files
git diff main..feature-branch -- package.json package-lock.json requirements.txt

# Blame specific security-relevant lines
git blame src/middleware/auth.ts

Configuration

Parameter	Description	Default
base_ref	Base commit/branch for comparison	main
head_ref	Head commit/branch to review	Current branch
risk_threshold	Minimum risk level to report	low
check_dependencies	Analyze dependency changes	true
check_configs	Analyze configuration changes	true
file_patterns	File patterns to prioritize	["*auth*", "*security*", "*middleware*"]
output_format	Report format: inline, markdown, sarif	markdown

Best Practices

1. Prioritize review by data sensitivity and exposure — Changes touching authentication, payment processing, and PII handling deserve the most scrutiny. A CSS change doesn't need the same security review depth as an API endpoint modification.

2. Check what the diff removes, not just what it adds — Removed security controls, deleted validation checks, and removed rate limiting are as important as new vulnerabilities. Watch for "simplification" refactors that inadvertently remove security-relevant code.

3. Trace data flow across the entire diff — A new endpoint may look safe in isolation, but trace how user input flows through newly added code. Check where data enters, how it's validated, where it's stored, and what it's used for across all changed files.

4. Review dependency changes with the same rigor as code changes — Check new dependencies against vulnerability databases (npm audit, Snyk). Verify that version bumps don't introduce breaking security changes. Be especially cautious of new transitive dependencies.

5. Document security review decisions in PR comments — When you approve code with noted risks or accepted trade-offs, document the reasoning. Future reviewers and auditors need to understand why security considerations were acknowledged but accepted.

Common Issues

Large PRs make thorough security review impractical. Request that large changes be split into smaller, focused PRs. When splitting isn't possible, start by reviewing the most security-sensitive files (auth, config, API handlers) and flag remaining files for follow-up review with reduced scope.

Security findings are dismissed as "not exploitable" without evidence. For each finding, provide a concrete proof-of-concept showing how the vulnerability could be exploited. Include the specific request, payload, and expected outcome. Theoretical risks are easier to dismiss than demonstrated exploits.

Developers circumvent security review by committing directly to main. Enforce branch protection rules requiring at least one security-aware reviewer approval. Use CODEOWNERS files to auto-assign security reviewers for changes to sensitive paths. Add pre-merge SAST scanning as a required CI check that cannot be bypassed.