# Differential Review

> Security-focused differential code review analyzing git diffs in context of the broader codebase. Part of the Nomark Method Layer 2 security verification. Use whenever reviewing a PR, preparing to merge, or someone asks for a 'security review of this diff', 'review these changes for security', or 'is this PR safe to merge'.

- Skill: `nomarj/differential-review` (Agent Skill)
- Install (CLI): `npx skillmds@latest add nomarj/differential-review`
- Raw SKILL.md: https://api.skillmd.com/api/skills/nomarj/differential-review/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- Author: nomarj (https://skillmd.com/u/nomarj)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/nomarj/differential-review

---


# Differential Security Review

Adapted from Trail of Bits' differential-review skill. Layer 2 analysis — runs on PRs and merges, examining not just what changed but what the change means in context.

## How This Differs from Layer 1

Layer 1 scans look at code in isolation — "is this line dangerous?" Layer 2 looks at the change in context — "does this change create a new attack surface, alter the security model, or introduce a vulnerability path that didn't exist before?"

## Review Methodology

### 1. Change Classification
Before diving into code, classify the change:
- **Security-critical:** Touches auth, authz, crypto, PII, payment, or infrastructure
- **Security-adjacent:** Touches input handling, API endpoints, data storage, or external integrations
- **Security-neutral:** UI changes, documentation, refactoring with no behavioral change

This classification determines review depth. Security-critical changes get line-by-line analysis. Security-neutral changes get a quick scan for accidental security regressions.

### 2. Attack Surface Analysis
For every change, ask:
- **New endpoints?** Every new route/endpoint is a new entry point for attackers
- **New data flows?** Does data move to a new destination? Does sensitive data reach a new component?
- **Changed trust boundaries?** Does this change what code is trusted vs. untrusted?
- **Changed permissions?** Does this alter who can do what?
- **New dependencies?** (Feeds into supply-chain audit)

### 3. Contextual Analysis
Read the diff in context of surrounding code:
- Does the changed function handle user input upstream?
- Are the changed values used in security-sensitive operations downstream?
- Does this change alter assumptions that other code relies on?
- Does the git history show this area has been fixed for security issues before? (Recurrence pattern)

### 4. Common Differential Vulnerabilities
Changes that look innocent but aren't:
- Adding a new API field that exposes internal data
- Changing a default value from deny to allow
- Adding a code path that bypasses existing validation
- Refactoring that removes a security check as "dead code"
- Adding logging that captures sensitive data
- Changing error handling from fail-closed to fail-open

### 5. Confidence Scoring

Every finding MUST receive a confidence score from 1-10:

| Score | Meaning | Action |
|---|---|---|
| 9-10 | Certain exploit path identified | Report as-is |
| 8 | Clear vulnerability pattern with known exploitation methods | Report as-is |
| 7 | Suspicious pattern requiring specific conditions | Include only with documented exploit path |
| 4-6 | Medium confidence, needs investigation | Flag for manual review, do not block |
| 1-3 | Low confidence, likely noise | Exclude from report |

**Hard threshold: ≥ 8.** Findings below 8 are excluded from the final report and do not contribute to the verdict. This prevents theoretical issues from blocking merges.

Run each finding through the `fp-check` skill's hard exclusion rules before scoring. Auto-excluded findings don't need a confidence score.

### 6. Review Artifact

```markdown
# Differential Security Review — PR #[number]

## Change Classification: [Security-critical | Security-adjacent | Security-neutral]

## Attack Surface Changes
- [New endpoints, data flows, trust boundary changes]

## Findings (confidence ≥ 8 only)
### [Finding title]
**File:** [path:line]
**Severity:** [CRITICAL | HIGH | MEDIUM | LOW]
**Confidence:** [8-10]
**Description:** [What the vulnerability is]
**Context:** [Why this matters given the broader codebase]
**Exploit Scenario:** [Concrete attack path]
**Recommendation:** [How to fix it]

## Excluded Findings
[Count] findings excluded by hard exclusion rules
[Count] findings excluded by confidence threshold (< 8)

## Security Checklist
- [ ] No new unauthenticated endpoints
- [ ] Input validation on all new user inputs
- [ ] No sensitive data in logs
- [ ] Error messages don't expose internals
- [ ] New dependencies reviewed
- [ ] Rate limiting on new endpoints (if applicable)
- [ ] RBAC/permissions verified for new operations
- [ ] Tenant isolation maintained (multi-tenant systems)
- [ ] AU Privacy Act / APPs compliance (if PII involved)

## Verdict: [APPROVE | REQUEST CHANGES | BLOCK]
Findings with confidence ≥ 8: [count]
Highest severity: [CRITICAL | HIGH | MEDIUM | NONE]
```