# Code Review Methodology

> Systematic manual source-code security review — how to find bugs by reading code. Load on "review this code/repo", a source-available target, whitebox testing, or auditing a PR/app for vulnerabilities. Signals: a codebase in scope, "SAST", "secure code review", a language repo.

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

---


# Source-code security review — methodology

## When it applies
You have (some of) the source. Whitebox review finds classes that blackbox misses — it follows
data from where it enters to where it's dangerous, across the whole codebase at once.

## Why it works
Vulnerabilities are source → sink flows with missing sanitization in between. Reading code lets
you see the sink (dangerous function), trace back to a user-controlled source, and confirm
nothing safe happens on the path — far faster and more complete than guessing from outside.

## Method
1. **Map the app**: entry points (routes/controllers/handlers), auth/authz middleware, the ORM/
   DB layer, config, and where user input enters. Note the framework — its defaults decide a lot.
2. **Sink-first sweep**: grep for dangerous functions per language (see `code-review-dangerous-sinks`)
   and for each hit, trace the argument back to a source. `semgrep --config auto` for a fast first pass.
3. **Source-to-sink for each class**: injection (query/exec/template), authz (missing owner
   checks → IDOR/BOLA), deserialization, SSRF (URL fetchers), file ops (path traversal/upload),
   crypto misuse, secrets in code.
4. **Auth & access control**: verify every sensitive route re-checks identity AND object ownership,
   not just "logged in". This is where the highest-impact bugs hide.
5. **Track findings** with `file:line`, the data path, and a PoC request; confirm dynamically where possible.

## Gotchas
- A dangerous sink with a constant/allowlisted argument isn't a bug — confirm the source is user-controlled.
- Framework auto-escaping (ORM params, template autoescape) can neutralize an apparent sink — check config.
- Don't drown in `semgrep` noise; triage by exploitable source→sink, not raw hit count.

## Verify success
For each finding: a concrete source→sink path with missing sanitization, ideally reproduced
with a request/input that triggers it.

## References
OWASP Code Review Guide; Semgrep rules; "Micro-methodology for code review" (GitHub Security Lab).