Code Vulnerability Review

Code Vulnerability Review

Use this skill after engagement-scope has established the authorized target, scope evidence, impact tolerance, and desired deliverable. If no engagement brief is present, infer the local/read-only scope from the provided repository or ask only for the missing boundary that changes the review.

Review Modes

Choose one primary mode:

• Broad audit: review a codebase or subsystem for likely vulnerability classes.
• Targeted class review: focus on one class such as IDOR, SSRF, injection, deserialization, upload handling, or secrets exposure.
• Patch review: inspect a diff for introduced, fixed, or bypassable security behavior.
• Finding validation: decide whether a suspected issue is reachable, exploitable, duplicate, or mitigated.
• Remediation: implement a minimal fix and tests for a confirmed issue.
• Report prep: turn evidence into a clear bounty, advisory, or internal security report.

Workflow

1. Restate the engagement brief in working terms: target paths, in-scope components, objective, impact tolerance, and deliverable.
2. Inventory the codebase before drilling down. Identify languages, frameworks, entry points, routes, handlers, jobs, parsers, privileged actions, auth middleware, storage layers, external calls, and security helpers.
3. Build a trust-boundary map. Track actors, authentication state, authorization context, tenant or object ownership, sensitive data, secrets, filesystem access, network egress, command execution, dynamic evaluation, and persistence.
4. Trace attacker-controlled input from entry points to security-sensitive decisions and sinks. Prefer concrete call chains over isolated pattern matches.
5. Validate each candidate. Establish reachability, controllability, missing or bypassable checks, realistic preconditions, impact, and existing mitigations.
6. Check tests, framework defaults, configuration, and deployment assumptions before deciding severity.
7. Produce the requested deliverable: findings, patch, tests, lab reproduction notes, or report text.

Search Strategy

Use fast local discovery first:

• Use rg --files to inventory files and identify manifests, routing, auth, config, migrations, tests, and generated code.
• Use targeted rg searches for security-sensitive APIs, framework handlers, validation helpers, and vulnerability-class keywords.
• Read nearby code, tests, and callers before forming a finding.
• Use repo-native test commands and static analysis only when they are already present or cheap to run. Do not treat raw scanner output as a finding without manual triage.

For broad or unfamiliar reviews, read references/vulnerability-patterns.md for vulnerability classes, review prompts, and grep seeds. Load only the parts relevant to the codebase or requested class.

Subagent Support

When the user explicitly asks for subagents, use subagent-orchestration to split broad source review into bounded workstreams. Good splits include one subsystem per auditor, one vulnerability class per auditor, one entry-point family per mapper, or one debater per candidate finding. Keep the parent agent responsible for final severity, deduplication, tracker updates, and proof handoff.

When the user asks for one subagent per vulnerability family, use subagent-orchestration family fan-out. Select only families that fit the target unless the user explicitly wants all-family coverage, and batch the resulting family auditors when the set exceeds the active subagent thread budget.

Evidence Standard

Treat a candidate as confirmed only when the review can explain:

• Entry point: how an attacker or lower-privileged actor reaches the code.
• Control: which values they control and how validation transforms them.
• Missing guard: the authorization, validation, sandboxing, escaping, or lifecycle check that should exist.
• Impact: what confidentiality, integrity, availability, account, tenant, or business boundary is affected.
• Constraints: required privileges, feature flags, environment, timing, configuration, or victim interaction.
• Fix path: the smallest robust change and the tests that would fail before the fix.

Use Potential or Needs validation for plausible issues missing one of these links. Do not bury uncertainty; name it.

Output Format

For review findings, lead with findings ordered by severity and confidence:

Finding: <short title>
Severity: <critical/high/medium/low/info>
Confidence: <high/medium/low>
Affected code: <file and line>
Entry point: <route/API/job/parser/CLI/etc.>
Issue: <why the security boundary fails>
Impact: <what can happen>
Evidence: <call chain, code facts, test or reproduction notes>
Fix: <specific remediation>
Tests: <coverage to add or update>

When the host app supports inline code review comments, emit tight comments only for confirmed issues or highly actionable risky code. Keep summaries secondary to findings.

If no issues are found, state that clearly and include the reviewed scope, important assumptions, and remaining test or coverage gaps.

Remediation

When asked to fix a confirmed issue:

• Keep the patch scoped to the vulnerable behavior and nearby tests.
• Preserve existing architecture, framework conventions, and error handling.
• Add regression tests that demonstrate the security boundary, not only the happy path.
• Prefer allowlists, centralized authorization checks, canonical parsing, parameterized queries, safe escaping APIs, explicit tenant/object ownership checks, and least-privilege defaults.
• Re-run the narrowest meaningful tests first, then broader tests when the touched surface is shared.

Handoff

Use web-app-security-inspection when source review needs browser or HTTP runtime validation. Use cve-research for dependency advisories or affected-version analysis. Use fuzz-harness-builder when parser or protocol risk needs systematic input generation. Use binary-debugging or binary-reversing when source is unavailable or native behavior depends on compiled artifacts.