Security Code Audit (FIND phase)
Overview
Read source code and find vulnerabilities by pattern. No running app required — works in any
AI coding tool. Trace untrusted input from its source (where it enters) to its sink
(where it's used dangerously).
Core principle: A vulnerability is untrusted data reaching a dangerous sink without
adequate validation/encoding in between. Find the source→sink paths.
Method: source → sink tracing
- From the threat model (or by scanning entry points), pick a source of untrusted input.
- Follow the data through the code to where it's used (the sink).
- Ask: is it validated, sanitized, parameterized, or encoded for that sink? If not → finding.
- Record severity,
file:line, the exact data path, and how to exploit it.
OWASP Top 10 — what to grep for
| Risk |
Smell / sink to search |
| Injection (SQL/NoSQL/cmd) |
string-built queries, exec, eval, system, template interpolation in queries |
| Broken access control (IDOR) |
object lookups by user-supplied id with no ownership check |
| Broken auth |
custom crypto, weak session handling, missing MFA, token in URL |
| Cryptographic failures |
md5/sha1 for passwords, hardcoded keys, Math.random for tokens, no TLS |
| SSRF |
server fetches a user-supplied URL (requests.get(input), fetch(input)) |
| Security misconfig |
debug=true, default creds, permissive CORS *, verbose errors |
| XSS |
innerHTML, dangerouslySetInnerHTML, v-html, unescaped template output |
| Insecure deserialization |
pickle.loads, yaml.load, native deserialize on input |
| Vulnerable dependencies |
check lockfiles vs advisories (npm audit, pip-audit, osv) |
| SSTI / path traversal |
template render of input, ../ in file paths from input |
Domain references (load the ones that match your stack)
references/web-frontend.md — XSS, CSRF, CSP, client-side secrets, clickjackingreferences/api-backend.md — authz/IDOR, injection, SSRF, JWT, rate limiting, mass assignmentreferences/database.md — SQLi/NoSQLi, access control, data exposure, ORM pitfalls
Output: findings register
| ID |
Severity |
Title |
Location |
Source→sink |
Exploitability |
Fix pointer |
| F1 |
High |
SQLi in user search |
api/users.py:42 |
?q= → raw SQL |
Unauth, dumps DB |
parameterize → security-hardening |
Severity = the threat-model risk score, adjusted for how exploitable the code actually is.
Hand-off
High-severity findings on a running app → active-pentest to validate.
All findings → security-hardening to fix.
Common mistakes
- Pattern-matching sinks without confirming input is actually attacker-controlled (false positive).
- Stopping at the first sink — one source often reaches several.
- Trusting client-side validation — it's bypassable; the server must validate.
- Ignoring authorization: most real-world breaches are access control, not exotic injection.
1---2name: security-code-audit3description: Use when you have application source code and want to find security vulnerabilities by reading it — covers OWASP Top 10 across frontend, backend API, and database. Produces a findings register with severity, file:line, and exploitability.4---56# Security Code Audit (FIND phase)78## Overview9Read source code and find vulnerabilities by pattern. No running app required — works in any10AI coding tool. Trace untrusted input from its **source** (where it enters) to its **sink**11(where it's used dangerously).1213**Core principle:** A vulnerability is *untrusted data reaching a dangerous sink without14adequate validation/encoding in between*. Find the source→sink paths.1516## Method: source → sink tracing171. From the threat model (or by scanning entry points), pick a **source** of untrusted input.182. Follow the data through the code to where it's **used** (the sink).193. Ask: is it validated, sanitized, parameterized, or encoded *for that sink*? If not → finding.204. Record severity, `file:line`, the exact data path, and how to exploit it.2122## OWASP Top 10 — what to grep for23| Risk | Smell / sink to search |24|------|------------------------|25| Injection (SQL/NoSQL/cmd) | string-built queries, `exec`, `eval`, `system`, template interpolation in queries |26| Broken access control (IDOR) | object lookups by user-supplied id with no ownership check |27| Broken auth | custom crypto, weak session handling, missing MFA, token in URL |28| Cryptographic failures | `md5`/`sha1` for passwords, hardcoded keys, `Math.random` for tokens, no TLS |29| SSRF | server fetches a user-supplied URL (`requests.get(input)`, `fetch(input)`) |30| Security misconfig | debug=true, default creds, permissive CORS `*`, verbose errors |31| XSS | `innerHTML`, `dangerouslySetInnerHTML`, `v-html`, unescaped template output |32| Insecure deserialization | `pickle.loads`, `yaml.load`, native deserialize on input |33| Vulnerable dependencies | check lockfiles vs advisories (`npm audit`, `pip-audit`, `osv`) |34| SSTI / path traversal | template render of input, `../` in file paths from input |3536## Domain references (load the ones that match your stack)37- `references/web-frontend.md` — XSS, CSRF, CSP, client-side secrets, clickjacking38- `references/api-backend.md` — authz/IDOR, injection, SSRF, JWT, rate limiting, mass assignment39- `references/database.md` — SQLi/NoSQLi, access control, data exposure, ORM pitfalls4041## Output: findings register42| ID | Severity | Title | Location | Source→sink | Exploitability | Fix pointer |43|----|----------|-------|----------|-------------|----------------|-------------|44| F1 | High | SQLi in user search | `api/users.py:42` | `?q=` → raw SQL | Unauth, dumps DB | parameterize → `security-hardening` |4546Severity = the threat-model risk score, adjusted for how exploitable the code actually is.4748## Hand-off49High-severity findings on a running app → **`active-pentest`** to validate.50All findings → **`security-hardening`** to fix.5152## Common mistakes53- Pattern-matching sinks without confirming input is actually attacker-controlled (false positive).54- Stopping at the first sink — one source often reaches several.55- Trusting client-side validation — it's bypassable; the server must validate.56- Ignoring authorization: most real-world breaches are *access control*, not exotic injection.
mn-youssef