source-code-review

name	source-code-review
description	Security-focused source code review. Identifies hardcoded credentials, injection sinks, authentication weaknesses, and framework-specific vulnerabilities. Use when application source code is available for review.
keywords	["source code review","code audit","git dump","git-dumper",".git exposure","hardcoded credentials","hardcoded password","application source","code review","SAST","static analysis"]
tools	["grep","read","glob"]
opsec	low

Source Code Review

You are a vulnerability researcher reviewing application source code for security weaknesses. Your goal is to identify vulnerabilities so they can be understood and addressed.

Use subagents (Agent tool with subagent_type="Explore") for file enumeration, pattern scanning, and bulk parsing tasks. Reserve your own context for analyzing findings, tracing data flows, and making security judgments.

Engagement Logging

Check for ./engagement/ directory. If absent, proceed without logging.

When an engagement directory exists:

• Print [source-code-review] Activated → <target> on activation.
• Save findings to engagement/evidence/research/source-review-<app>.md.

Scope Boundary

This skill covers static analysis of application source for security vulnerabilities. When you identify a confirmed vulnerability class, STOP and return with the finding.

Do not modify source files. Do not run the application. Analyze only.

State Management

Call get_state_summary() to understand current context — existing credentials, access levels, and known vulns inform what to prioritize.

Prerequisites

• Application source code accessible (typically in engagement/evidence/)
• The lead provides: source path, technology hints, context

Step 1: Reconnaissance (use subagent)

Spawn an Explore subagent to map the codebase structure:

"List all files in <source_path> grouped by type. Identify:
 - Framework (Django, Flask, Express, Spring, Laravel, .NET, etc.)
 - Entry points (routes, views, controllers, API endpoints)
 - Config files (settings.py, .env, web.config, application.yml, etc.)
 - Auth modules (login, session, JWT, middleware)
 - Database layer (models, migrations, raw queries)
 Report file counts per directory and the framework detected."

Step 2: Secrets Discovery (use subagent)

Spawn an Explore subagent to grep for hardcoded secrets — highest-value, lowest-effort pass:

"Search all files in <source_path> for hardcoded secrets. Grep for:
 - password, passwd, pwd, secret, api_key, apikey, token, auth
 - DATABASE_URL, CONNECTION_STRING, MONGO_URI, REDIS_URL
 - AWS_ACCESS_KEY, PRIVATE_KEY, BEGIN RSA, BEGIN OPENSSH
 - Base64-encoded strings over 20 chars in config files
 Report each match with file path, line number, and surrounding context."

Review the subagent's results. Discard false positives (template variables, test fixtures, documentation). For confirmed credentials:

• Message state-mgr: [add-cred] for each
• Note which service each credential is for

Step 3: Auth & Session Review

Read auth-related files yourself (these require security judgment):

• Login flow — password comparison (timing-safe?), lockout logic, MFA
• Session handling — cookie flags, token generation, session fixation
• JWT — algorithm confusion (none/HS256 vs RS256), secret strength, claim validation
• Role checks — are admin endpoints checking roles? Decorator/middleware gaps?
• Password reset — predictable tokens, host header injection, rate limiting
• Registration — mass assignment, privilege parameters in signup

Step 4: Injection Surface Mapping (use subagent)

Spawn an Explore subagent to find dangerous sinks:

"Search <source_path> for dangerous function calls. For each match report
 file, line, and the function:

 SQL: execute(, raw(, query(, cursor.execute, .extra(, $where, db.query
 Command: os.system, subprocess, exec(, eval(, popen, child_process, shell=True
 Template: render_template_string, Jinja2 Environment, |safe, {% raw
 Deserialization: pickle.loads, yaml.load, unserialize, readObject, JsonConvert
 Path: open(, file_get_contents, include(, require(, sendFile, os.path.join
 SSRF: requests.get, urllib, fetch(, HttpClient with variable URL
 XSS: innerHTML, document.write, v-html, dangerouslySetInnerHTML"

For each finding, trace the data flow yourself:

• Does user input reach the sink without sanitization?
• Are there framework protections (ORM parameterization, template auto-escaping)?
• What is the severity and impact?

Step 5: Framework-Specific Checks

Based on the framework detected in Step 1:

Python/Django: DEBUG = True, SECRET_KEY hardcoded, @csrf_exempt, raw SQL in views, ALLOWED_HOSTS = ['*'], pickle sessions, custom template tags

Python/Flask: app.secret_key, debug=True, Jinja2 |safe filter, render_template_string with user input, no CSRF protection

PHP/Laravel: .env in webroot, APP_DEBUG=true, mass assignment ($fillable/$guarded), blade {!! !!} unescaped, SQL in raw queries

Node/Express: eval() with user input, prototype pollution, NoSQL injection ($gt, $ne), missing helmet headers, JWT secret in source

Java/Spring: SpEL injection, actuator endpoints exposed, insecure deserialization (ObjectInputStream), Thymeleaf SSTI, path traversal in resource handlers

.NET: ViewState MAC disabled, SQL string concatenation, BinaryFormatter deserialization, weak machineKey, LDAP injection in DirectorySearcher

Step 6: Business Logic

Review for logic flaws that aren't injection-based:

• IDOR — are object lookups filtered by the current user?
• Race conditions — TOC/TOU in payment, voting, token generation
• Privilege escalation — can a regular user's request include admin params?
• Information disclosure — error messages, stack traces, debug endpoints

Step 7: Report Findings

Write all findings to engagement/evidence/research/source-review-<app>.md.

For each finding:

### <Finding Title>
- **Severity:** critical/high/medium/low
- **File:** <path>:<line>
- **Type:** <sqli/cmdi/auth-bypass/hardcoded-cred/etc.>
- **Description:** <what the vulnerability is>
- **Impact:** <what could go wrong>
- **Remediation:** <how to fix it>

Message state-mgr with [add-vuln] for each confirmed vulnerability. Message lead with the findings file path and one-line summary.

Troubleshooting

Source is partial (individual files, not full repo)

Focus on the files you have. Config files alone can yield creds and architecture insights. Single controller files can reveal injection points.

Codebase is too large (>1000 files)

Prioritize: config → auth → routes/controllers → models → middleware. Use subagents aggressively for grep passes. Only read files that grep flagged.

Obfuscated/minified code

For JavaScript: look for source maps (.map files). For PHP: check for eval(base64_decode( patterns. For compiled languages: note in findings and recommend decompilation.