Differential Review
Trail of BitsOfficialPublished by Trail of Bits
- Skill
- Review and audit
- Security
- CC-BY-SA-4.0
- No issues found
AutoGineer summary
Written by AutoGineer from the skill’s own files, not by the author
Differential Review provides a structured, risk-based methodology for auditing code changes. It helps developers and security engineers identify potential vulnerabilities by analyzing git history, assessing test coverage, and calculating the blast radius of modifications. The skill is designed to scale its analysis depth based on codebase size and risk level, ensuring that critical changes receive rigorous scrutiny while maintaining efficiency. It produces comprehensive markdown reports that document findings, evidence, and potential attack scenarios.
What it does
- Performs security-focused differential analysis on PRs, commits, and diffs
- Adapts analysis depth based on codebase size and risk level
- Uses git history to identify regressions and security-related code removals
- Calculates blast radius by identifying transitive callers of modified code
- Checks test coverage for modified code to identify untested security risks
- Generates structured markdown reports with concrete findings and evidence
When to use it
- When reviewing PRs or commits for potential security vulnerabilities
- When assessing the impact of refactors on existing security invariants
- When investigating whether a change re-introduces previously fixed bugs
- When determining if modified code lacks sufficient test coverage
- When performing deep audits on critical system changes like authentication rewrites
Advantages
- Risk-first approach prioritizes critical areas like auth and crypto
- Evidence-based findings linked to git history and line numbers
- Scalable methodology suitable for small PRs or large-scale audits
- Quantifiable blast radius analysis reduces blind spots
- Standardized reporting ensures consistent and actionable audit documentation
Usage examples
- “Review this PR for security vulnerabilities and generate a report.”
- The agent analyzes the diff, checks git history for removed security code, calculates the blast radius, and outputs a markdown report detailing any identified risks.
- “Does this refactor introduce any security regressions?”
- The agent performs a differential review, focusing on the refactored logic and comparing it against historical git blame data to identify potential regressions.
- “Perform a deep audit on this authentication system rewrite.”
- The agent applies the surgical strategy, building baseline context, performing deep analysis on auth changes, and conducting adversarial modeling to identify potential exploits.
Install
Download the skill as a ZIP:
https://autogineer.com/agent-skills/trailofbits/differential-review/downloadUnzip it into the cross-client skills folder of your project:
mkdir -p .agents/skills && unzip differential-review.zip -d .agents/skills
Documentation by Trail of Bits
Differential Security Review
Security-focused code review for PRs, commits, and diffs.
Core Principles
Risk-First: Focus on auth, crypto, value transfer, external calls
Evidence-Based: Every finding backed by git history, line numbers, attack scenarios
Adaptive: Scale to codebase size (SMALL/MEDIUM/LARGE)
Honest: Explicitly state coverage limits and confidence level
Output-Driven: Always generate comprehensive markdown report file
Rationalizations (Do Not Skip)
| Rationalization | Why It's Wrong | Required Action |
|---|---|---|
| "Small PR, quick review" | Heartbleed was 2 lines | Classify by RISK, not size |
| "I know this codebase" | Familiarity breeds blind spots | Build explicit baseline context |
| "Git history takes too long" | History reveals regressions | Never skip Phase 1 |
| "Blast radius is obvious" | You'll miss transitive callers | Calculate quantitatively |
| "No tests = not my problem" | Missing tests = elevated risk rating | Flag in report, elevate severity |
| "Just a refactor, no security impact" | Refactors break invariants | Analyze as HIGH until proven LOW |
| "I'll explain verbally" | No artifact = findings lost | Always write report |
Quick Reference
Codebase Size Strategy
| Codebase Size | Strategy | Approach |
|---|---|---|
| SMALL (<20 files) | DEEP | Read all deps, full git blame |
| MEDIUM (20-200) | FOCUSED | 1-hop deps, priority files |
| LARGE (200+) | SURGICAL | Critical paths only |
Risk Level Triggers
| Risk Level | Triggers |
|---|---|
| HIGH | Auth, crypto, external calls, value transfer, validation removal |
| MEDIUM | Business logic, state changes, new public APIs |
| LOW | Comments, tests, UI, logging |
Workflow Overview
Pre-Analysis → Phase 0: Triage → Phase 1: Code Analysis → Phase 2: Test Coverage
↓ ↓ ↓ ↓
Phase 3: Blast Radius → Phase 4: Deep Context → Phase 5: Adversarial → Phase 6: ReportDecision Tree
Starting a review?
├─ Need detailed phase-by-phase methodology?
│ └─ Read: methodology.md
│ (Pre-Analysis + Phases 0-4: triage, code analysis, test coverage, blast radius)
│
├─ Analyzing HIGH RISK change?
│ ├─ Read: adversarial.md
│ │ (Phase 5: Attacker modeling, exploit scenarios, exploitability rating)
│ └─ Or delegate to: differential-review:adversarial-modeler agent
│ (Autonomous attacker modeling with concrete exploit scenarios)
│
├─ Writing the final report?
│ └─ Read: reporting.md
│ (Phase 6: Report structure, templates, formatting guidelines)
│
├─ Looking for specific vulnerability patterns?
│ └─ Read: patterns.md
│ (Regressions, reentrancy, access control, overflow, etc.)
│
└─ Quick triage only?
└─ Use Quick Reference above, skip detailed docsAgents
differential-review:adversarial-modeler — Models attacker perspectives and
builds exploit scenarios for HIGH RISK code changes. Follows the 5-step
adversarial methodology (attacker model, attack vectors, exploitability rating,
exploit scenario, baseline cross-reference) and produces structured vulnerability
reports. Delegate to this agent when Phase 5 analysis is needed on high-risk
changes, passing that full namespaced name as subagent_type — a bare
adversarial-modeler is unregistered and the dispatch fails at runtime.
Quality Checklist
Before delivering:
[ ] All changed files analyzed
[ ] Git blame on removed security code
[ ] Blast radius calculated for HIGH risk
[ ] Attack scenarios are concrete (not generic)
[ ] Findings reference specific line numbers + commits
[ ] Report file generated
[ ] User notified with summary
Integration
audit-context-building skill:
Pre-Analysis: Build baseline context
Phase 4: Deep context on HIGH RISK changes
issue-writer skill:
Transform findings into formal audit reports
Command:
issue-writer --input DIFFERENTIAL_REVIEW_REPORT.md --format audit-report
Example Usage
Quick Triage (Small PR)
Input: 5 file PR, 2 HIGH RISK files
Strategy: Use Quick Reference
1. Classify risk level per file (2 HIGH, 3 LOW)
2. Focus on 2 HIGH files only
3. Git blame removed code
4. Generate minimal report
Time: ~30 minutesStandard Review (Medium Codebase)
Input: 80 files, 12 HIGH RISK changes
Strategy: FOCUSED (see methodology.md)
1. Full workflow on HIGH RISK files
2. Surface scan on MEDIUM
3. Skip LOW risk files
4. Complete report with all sections
Time: ~3-4 hoursDeep Audit (Large, Critical Change)
Input: 450 files, auth system rewrite
Strategy: SURGICAL + audit-context-building
1. Baseline context with audit-context-building
2. Deep analysis on auth changes only
3. Blast radius analysis
4. Adversarial modeling
5. Comprehensive report
Time: ~6-8 hoursWhen NOT to Use This Skill
Greenfield code (no baseline to compare)
Documentation-only changes (no security impact)
Formatting/linting (cosmetic changes)
User explicitly requests quick summary only (they accept risk)
For these cases, use standard code review instead.
Red Flags (Stop and Investigate)
Immediate escalation triggers:
Removed code from "security", "CVE", or "fix" commits
Access control modifiers removed (onlyOwner, internal → external)
Validation removed without replacement
External calls added without checks
High blast radius (50+ callers) + HIGH risk change
These patterns require adversarial analysis even in quick triage.
Tips for Best Results
Do:
Start with git blame for removed code
Calculate blast radius early to prioritize
Generate concrete attack scenarios
Reference specific line numbers and commits
Be honest about coverage limitations
Always generate the output file
Don't:
Skip git history analysis
Make generic findings without evidence
Claim full analysis when time-limited
Forget to check test coverage
Miss high blast radius changes
Output report only to chat (file required)
Supporting Documentation
methodology.md - Detailed phase-by-phase workflow (Phases 0-4)
adversarial.md - Attacker modeling and exploit scenarios (Phase 5)
reporting.md - Report structure and formatting (Phase 6)
patterns.md - Common vulnerability patterns reference
For first-time users: Start with methodology.md to understand the complete workflow.
For experienced users: Use this page's Quick Reference and Decision Tree to navigate directly to needed content.
Files
- ATTRIBUTION.mdAdded by AutoGineer951 B
- LICENSELicence file added by AutoGineer19.7 KiB
- SKILL.md7.3 KiB
- adversarial.md4.9 KiB
- agents/openai.yaml245 B
- assets/trail-of-bits-mark.svg3.0 KiB
- methodology.md6.6 KiB
- patterns.md6.8 KiB
- reporting.md6.8 KiB
adversarial.md
Adversarial Vulnerability Analysis (Phase 5)
Structured methodology for finding vulnerabilities through attacker modeling.
When to use: After completing deep context analysis (Phase 4), apply this to all HIGH RISK changes.
1. Define Specific Attacker Model
WHO is the attacker?
Unauthenticated external user
Authenticated regular user
Malicious administrator
Compromised contract/service
Front-runner/MEV bot
WHAT access/privileges do they have?
Public API access only
Authenticated user role
Specific permissions/tokens
Contract call capabilities
WHERE do they interact with the system?
Specific HTTP endpoints
Smart contract functions
RPC interfaces
External APIs
2. Identify Concrete Attack Vectors
ENTRY POINT: [Exact function/endpoint attacker can access]
ATTACK SEQUENCE:
1. [Specific API call/transaction with parameters]
2. [How this reaches the vulnerable code]
3. [What happens in the vulnerable code]
4. [Impact achieved]
PROOF OF ACCESSIBILITY:
- Show the function is public/external
- Demonstrate attacker has required permissions
- Prove attack path exists through actual interfaces3. Rate Realistic Exploitability
EASY: Exploitable via public APIs with no special privileges
Single transaction/call
Common user access level
No complex conditions required
MEDIUM: Requires specific conditions or elevated privileges
Multiple steps or timing requirements
Elevated but obtainable privileges
Specific system state needed
HARD: Requires privileged access or rare conditions
Admin/owner privileges needed
Rare edge case conditions
Significant resources required
4. Build Complete Exploit Scenario
ATTACKER STARTING POSITION:
[What the attacker has at the beginning]
STEP-BY-STEP EXPLOITATION:
Step 1: [Concrete action through accessible interface]
- Command: [Exact call/request]
- Parameters: [Specific values]
- Expected result: [What happens]
Step 2: [Next action]
- Command: [Exact call/request]
- Why this works: [Reference to code change]
- System state change: [What changed]
Step 3: [Final impact]
- Result: [Concrete harm achieved]
- Evidence: [How to verify impact]
CONCRETE IMPACT:
[Specific, measurable impact - not "could cause issues"]
- Exact amount of funds drained
- Specific privileges escalated
- Particular data exposed5. Cross-Reference with Baseline Context
From baseline analysis (see methodology.md), check:
Does this violate a system-wide invariant?
Does this break a trust boundary?
Does this bypass a validation pattern?
Is this a regression of a previous fix?
Vulnerability Report Template
Generate this for each finding:
## [SEVERITY] Vulnerability Title
**Attacker Model:**
- WHO: [Specific attacker type]
- ACCESS: [Exact privileges]
- INTERFACE: [Specific entry point]
**Attack Vector:**
[Step-by-step exploit through accessible interfaces]
**Exploitability:** EASY/MEDIUM/HARD
**Justification:** [Why this rating]
**Concrete Impact:**
[Specific, measurable harm - not theoretical]
**Proof of Concept:**
```code
// Exact code to reproduceRoot Cause: [Reference specific code change at file.sol:L123]
Blast Radius: [N callers affected] Baseline Violation: [Which invariant/pattern broken]
---
## Example: Complete Adversarial Analysis
**Change:** Removed `require(amount > 0)` check from `withdraw()` function
### 1. Attacker Model
- **WHO:** Unauthenticated external user
- **ACCESS:** Can call public contract functions
- **INTERFACE:** `withdraw(uint256 amount)` at 0x1234...
### 2. Attack Vector
**ENTRY POINT:** `withdraw(0)`
**ATTACK SEQUENCE:**
1. Call `withdraw(0)` from attacker address
2. Code bypasses amount check (removed)
3. Withdraw event emitted with 0 amount
4. Accounting updated incorrectly
**PROOF:** Function is `external`, no auth required
### 3. Exploitability
**RATING:** EASY
- Single transaction
- Public function
- No special state required
### 4. Exploit Scenario
**ATTACKER POSITION:** Has user account with 0 balance
**EXPLOITATION:**
```solidity
Step 1: attacker.withdraw(0)
- Passes removed validation
- Emits Withdraw(user, 0)
- Updates withdrawnAmount[user] += 0
Step 2: Off-chain indexer sees Withdraw event
- Credits attacker for 0 withdrawal
- But accounting thinks withdrawal happened
Step 3: Accounting mismatch exploited
- Total supply decremented
- User balance not changed
- System invariants brokenIMPACT:
Protocol accounting corrupted
Can be used to manipulate LP calculations
Estimated $50K impact on pool prices
5. Baseline Violation
Violates invariant: "All withdrawals must transfer non-zero value"
Breaks validation pattern: Amount checks present in all other value transfers
Regression: Check added in commit abc123 "Fix zero-amount exploit"
Next: Document all findings in final report (see reporting.md)
Requirements and compatibility
Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta
“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.
Needs: Declares allowed tools
Security
No issues found by our static scan· No issues found
A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.
Attribution and licence
- Published by
- Trail of Bits
- Publisher
- Trail of Bits (Official)
- Source
- trailofbits/skills · plugins/differential-review/skills/differential-review · commit e4dd0bb
- Licence
- Creative Commons Attribution-ShareAlike 4.0 International (redistribution allowed)
- LICENSE (added by AutoGineer from LICENSE)
- ATTRIBUTION.md (written by AutoGineer)
- Synced
AutoGineer is not affiliated with or endorsed by Trail of Bits or Trail of Bits.
Download ZIP
The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download differential-review.zip