Differential Review
Security-focused code review that adapts depth to codebase size and change risk. Goes beyond style -- finds vulnerabilities, logic errors, and blast radius.
Review Depth Modes
DEEP (Small codebase, < 5K lines changed)
- Line-by-line analysis of every changed file
- Full control flow tracing through changed paths
- Cross-reference every function call to its definition
- Check all error paths and edge cases
FOCUSED (Medium codebase, 5K-50K lines)
- Prioritize files touching auth, crypto, input parsing, state mutation
- Trace data flow from inputs to outputs through changed code
- Skip cosmetic changes (formatting, comments, renames)
- Deep-dive only on security-sensitive paths
SURGICAL (Large codebase, > 50K lines)
- Review only the diff, not surrounding code
- Focus exclusively on: new attack surface, removed security controls, changed trust boundaries
- Flag anything that needs a separate deep review
Review Process
Phase 1: Blast Radius Assessment
Before reading any code:
# What changed?
git diff --stat <base>...<head>
# How much changed?
git diff --shortstat <base>...<head>
# Which files are security-sensitive?
git diff --name-only <base>...<head> | grep -iE '(auth|crypto|token|secret|permission|middleware|validator|sanitiz)'
Classify the change:
- Surface area: How many files, functions, modules touched?
- Trust boundary crossing: Does data flow between trust levels?
- Security control modification: Are auth/authz/validation/crypto paths changed?
- Data model change: Are schemas, types, or storage formats modified?
Phase 2: Git History Correlation
Check if the changed code has a history of bugs:
# How often has this file been changed? (churn = risk)
git log --oneline --follow <file> | wc -l
# Were there recent security fixes in this area?
git log --oneline --grep="fix\|vuln\|security\|CVE" -- <file>
# Who else has touched this code?
git log --format='%an' -- <file> | sort | uniq -c | sort -rn
High churn + security fix history = increase review depth.
Phase 3: Structured Review
For each changed file, analyze in this order:
- Input validation: Are new inputs validated? Are existing validations preserved?
- Authentication/Authorization: Do access controls apply to new code paths?
- Data flow: Can untrusted data reach sensitive operations?
- Error handling: Do error paths leak information or skip cleanup?
- State mutation: Are state changes atomic? Race conditions possible?
- Crypto usage: Correct algorithms, key sizes, modes, IVs?
- Logging: Are sensitive values logged? Are security events NOT logged?
Finding Format
## [SEVERITY] Finding Title
**Location**: file.ts:42-58
**Category**: [Input Validation | Auth | Crypto | Data Flow | State | Logic]
**Confidence**: [HIGH | MEDIUM | LOW]
**Description**:
What the vulnerability is, in one paragraph.
**Impact**:
What an attacker can achieve by exploiting this.
**Proof**:
The specific code path or data flow that demonstrates the issue.
**Recommendation**:
Concrete fix with code example if possible.
Severity Classification
| Severity |
Criteria |
Examples |
| CRITICAL |
Remote exploitation, no auth required, data breach |
SQL injection, auth bypass, RCE |
| HIGH |
Requires some access, significant impact |
Privilege escalation, IDOR, stored XSS |
| MEDIUM |
Limited impact or complex exploitation |
Reflected XSS, info disclosure, CSRF |
| LOW |
Minimal impact, defense-in-depth |
Missing headers, verbose errors, weak config |
| INFO |
Best practice, no direct vulnerability |
Code quality, missing rate limit, logging gap |
Rationalizations to Reject
Common excuses that lead to missed findings. Do NOT accept these:
| Rationalization |
Why It's Wrong |
Required Action |
| "It's behind auth" |
Auth can be bypassed |
Verify auth is enforced AND correct |
| "We trust this input" |
Trust boundaries change |
Validate at every boundary |
| "It's just internal" |
Internal networks get compromised |
Apply defense in depth |
| "Nobody would do that" |
Attackers do unexpected things |
Test the unexpected case |
| "We'll fix it later" |
Later never comes in security |
Flag it NOW with severity |
| "The framework handles it" |
Frameworks have bypasses |
Verify the framework actually applies |
| "It's the same as before" |
Before might have been wrong too |
Review the original if suspicious |
Anti-Hallucination Rules
- Never say "It probably..." -- say "Unclear; need to inspect X"
- Never assume a function is safe without reading its implementation
- Never skip a finding because it seems minor -- document everything
- Every claim must reference a specific file and line number
- If you haven't read the code, say so -- don't infer behavior from names
Diff Review Checklist
[ ] Blast radius assessed (files, trust boundaries, security controls)
[ ] Git history checked for churn and past security fixes
[ ] All new inputs validated
[ ] Auth/authz applied to new endpoints/paths
[ ] Error handling doesn't leak sensitive info
[ ] No hardcoded secrets or credentials
[ ] State mutations are atomic
[ ] Crypto usage follows current best practices
[ ] Logging doesn't include sensitive data
[ ] Removed code didn't contain security controls that are now missing
[ ] Dependencies added/updated are from trusted sources
[ ] Test coverage exists for security-critical paths
Integration with vibecosystem
- code-reviewer agent: Use this skill for security-focused review depth
- security-reviewer agent: Primary consumer of this skill
- coroner agent: Use blast radius analysis for post-mortem propagation
- /review skill: Automatically applies differential review to PRs
Inspired by Trail of Bits differential-review plugin.
1---2name: differential-review3description: Security-focused differential code review with blast radius analysis, risk-adaptive depth (DEEP/FOCUSED/SURGICAL), git history correlation, and structured finding format. Adapted from Trail of Bits. Use when reviewing PRs, commits, or code changes for security implications.4---56# Differential Review78Security-focused code review that adapts depth to codebase size and change risk. Goes beyond style -- finds vulnerabilities, logic errors, and blast radius.910## Review Depth Modes1112### DEEP (Small codebase, < 5K lines changed)13- Line-by-line analysis of every changed file14- Full control flow tracing through changed paths15- Cross-reference every function call to its definition16- Check all error paths and edge cases1718### FOCUSED (Medium codebase, 5K-50K lines)19- Prioritize files touching auth, crypto, input parsing, state mutation20- Trace data flow from inputs to outputs through changed code21- Skip cosmetic changes (formatting, comments, renames)22- Deep-dive only on security-sensitive paths2324### SURGICAL (Large codebase, > 50K lines)25- Review only the diff, not surrounding code26- Focus exclusively on: new attack surface, removed security controls, changed trust boundaries27- Flag anything that needs a separate deep review2829## Review Process3031### Phase 1: Blast Radius Assessment32Before reading any code:3334```bash35# What changed?36git diff --stat <base>...<head>3738# How much changed?39git diff --shortstat <base>...<head>4041# Which files are security-sensitive?42git diff --name-only <base>...<head> | grep -iE '(auth|crypto|token|secret|permission|middleware|validator|sanitiz)'43```4445Classify the change:46- **Surface area**: How many files, functions, modules touched?47- **Trust boundary crossing**: Does data flow between trust levels?48- **Security control modification**: Are auth/authz/validation/crypto paths changed?49- **Data model change**: Are schemas, types, or storage formats modified?5051### Phase 2: Git History Correlation52Check if the changed code has a history of bugs:5354```bash55# How often has this file been changed? (churn = risk)56git log --oneline --follow <file> | wc -l5758# Were there recent security fixes in this area?59git log --oneline --grep="fix\|vuln\|security\|CVE" -- <file>6061# Who else has touched this code?62git log --format='%an' -- <file> | sort | uniq -c | sort -rn63```6465High churn + security fix history = increase review depth.6667### Phase 3: Structured Review6869For each changed file, analyze in this order:70711. **Input validation**: Are new inputs validated? Are existing validations preserved?722. **Authentication/Authorization**: Do access controls apply to new code paths?733. **Data flow**: Can untrusted data reach sensitive operations?744. **Error handling**: Do error paths leak information or skip cleanup?755. **State mutation**: Are state changes atomic? Race conditions possible?766. **Crypto usage**: Correct algorithms, key sizes, modes, IVs?777. **Logging**: Are sensitive values logged? Are security events NOT logged?7879## Finding Format8081```82## [SEVERITY] Finding Title8384**Location**: file.ts:42-5885**Category**: [Input Validation | Auth | Crypto | Data Flow | State | Logic]86**Confidence**: [HIGH | MEDIUM | LOW]8788**Description**:89What the vulnerability is, in one paragraph.9091**Impact**:92What an attacker can achieve by exploiting this.9394**Proof**:95The specific code path or data flow that demonstrates the issue.9697**Recommendation**:98Concrete fix with code example if possible.99```100101## Severity Classification102103| Severity | Criteria | Examples |104|----------|----------|---------|105| CRITICAL | Remote exploitation, no auth required, data breach | SQL injection, auth bypass, RCE |106| HIGH | Requires some access, significant impact | Privilege escalation, IDOR, stored XSS |107| MEDIUM | Limited impact or complex exploitation | Reflected XSS, info disclosure, CSRF |108| LOW | Minimal impact, defense-in-depth | Missing headers, verbose errors, weak config |109| INFO | Best practice, no direct vulnerability | Code quality, missing rate limit, logging gap |110111## Rationalizations to Reject112113Common excuses that lead to missed findings. Do NOT accept these:114115| Rationalization | Why It's Wrong | Required Action |116|----------------|---------------|-----------------|117| "It's behind auth" | Auth can be bypassed | Verify auth is enforced AND correct |118| "We trust this input" | Trust boundaries change | Validate at every boundary |119| "It's just internal" | Internal networks get compromised | Apply defense in depth |120| "Nobody would do that" | Attackers do unexpected things | Test the unexpected case |121| "We'll fix it later" | Later never comes in security | Flag it NOW with severity |122| "The framework handles it" | Frameworks have bypasses | Verify the framework actually applies |123| "It's the same as before" | Before might have been wrong too | Review the original if suspicious |124125## Anti-Hallucination Rules126127- **Never say "It probably..."** -- say "Unclear; need to inspect X"128- **Never assume a function is safe** without reading its implementation129- **Never skip a finding** because it seems minor -- document everything130- **Every claim must reference a specific file and line number**131- **If you haven't read the code, say so** -- don't infer behavior from names132133## Diff Review Checklist134135```136[ ] Blast radius assessed (files, trust boundaries, security controls)137[ ] Git history checked for churn and past security fixes138[ ] All new inputs validated139[ ] Auth/authz applied to new endpoints/paths140[ ] Error handling doesn't leak sensitive info141[ ] No hardcoded secrets or credentials142[ ] State mutations are atomic143[ ] Crypto usage follows current best practices144[ ] Logging doesn't include sensitive data145[ ] Removed code didn't contain security controls that are now missing146[ ] Dependencies added/updated are from trusted sources147[ ] Test coverage exists for security-critical paths148```149150## Integration with vibecosystem151152- **code-reviewer agent**: Use this skill for security-focused review depth153- **security-reviewer agent**: Primary consumer of this skill154- **coroner agent**: Use blast radius analysis for post-mortem propagation155- **/review skill**: Automatically applies differential review to PRs156157Inspired by [Trail of Bits](https://github.com/trailofbits/skills) differential-review plugin.
vibeeval