Vulnerability Review

Overview

Use this skill to perform a focused vulnerability review of a codebase or folder. Prioritize real security weaknesses and plausible exploit paths over style, generic hardening advice, or broad architecture critique.

Prefer a useful partial review with grounded findings over an exhaustive but weakly supported list.

Workflow

1. Establish the review scope

Choose the smallest meaningful slice before reading everything.

Start with:

• the README and architecture docs
• dependency manifests and framework config
• obvious entrypoints, privileged workflows, external integrations, storage paths, and automation scripts

If the codebase is large, choose one of these scopes and say which one you chose:

• one request path
• one privileged workflow
• one integration or data path
• one script, job, or subsystem

2. Identify attack surfaces

Look for:

• untrusted inputs from users, files, APIs, queues, webhooks, CLI args, or environment
• trust boundaries between components, tenants, services, or operators
• secrets, tokens, credentials, and identity material
• privileged operations, admin tooling, and automation
• storage, transport, execution, and serialization boundaries

Prefer code search over assumptions. Follow concrete routes, handlers, scripts, subprocess calls, storage writes, client calls, and policy checks.

3. Trace plausible exploit paths

Trace attacker-controlled input to sensitive operations such as:

• command execution
• file access
• database queries
• template rendering
• deserialization
• authentication and authorization decisions
• external API calls
• storage writes and object access
• privileged state changes

Capture where validation is missing, weak, bypassable, or inconsistent.

4. Review the key functions

For every important function in the chosen flow, review the function instead of only naming it. Capture:

• file path
• function or method name
• role in the exploit path
• direct callers and important callees, if visible
• expected inputs
• sensitive operations performed
• validation, sanitization, or policy enforcement
• side effects and downstream impact
• failure modes, hidden assumptions, and security concerns

Prioritize functions that:

• execute commands or scripts
• parse untrusted data
• trust headers, claims, files, or upstream systems
• use secrets or privileged credentials
• read or write sensitive data
• bypass normal checks in support, internal, debug, or batch paths

5. Surface vulnerability findings

Call out issues that materially affect security, especially:

• injection paths
• broken or weak authentication
• broken or inconsistent authorization
• insecure secret handling
• disabled TLS or weak transport trust
• insecure deserialization or parsing
• path traversal or arbitrary file access
• SSRF, unsafe callbacks, or over-trusted integrations
• unsafe defaults, privilege escalation paths, or broad trust zones
• audit, logging, or failure behavior that hides compromise

Separate confirmed findings from open questions.

6. Deliver a concise report

Default to this structure:

1. Findings
2. Open questions
3. Summary

Reporting Rules

• Lead with findings ordered by severity.
• Include file and line references when they are available.
• For each finding, explain the exploit path or plausible risk in one or two short paragraphs.
• Give a concrete fix or mitigation direction.
• Distinguish between confirmed, likely, and open question where confidence differs.
• If no material issues are found, say so explicitly and mention any context gaps that limit confidence.

Use this report shape by default:

Findings
- High: <issue> — <file:line>
  Why it matters: <exploit path or impact>
  Fix: <concrete remediation direction>

Open questions
- <only include when they materially affect confidence>

Summary
- <1-2 sentence overall risk assessment>

Search Strategy

Use fast repository discovery first:

• rg --files for project shape
• rg for signals such as exec, subprocess, system, shell, eval, pickle, yaml.load, jwt, token, secret, password, key, verify=False, auth, role, permission, upload, download, template, sql, query, path, open(, requests, callback, webhook
• framework-specific files such as routes, controllers, handlers, clients, middleware, guards, workers, jobs, scripts, db, storage, auth, security

Prioritize these signals:

• files that connect untrusted input to sensitive operations
• code that handles secrets, privilege, storage, or network trust
• code that performs writes, execution, policy checks, or external calls
• scripts and workflows that operators may trust without realizing their security impact

Output Rules

Be explicit about evidence quality:

• say confirmed when the code directly shows the vulnerability
• say likely when the weakness is plausible but depends on runtime assumptions
• say open question when missing infrastructure, framework, or deployment details limit confidence

Do not drown real findings in minor style issues.

Do not recommend rewrites when targeted fixes or containment steps are enough.

Example Requests

• Review this repo for vulnerabilities.
• Inspect this folder and find the most important security weaknesses.
• Perform a vulnerability review of this import pipeline.
• Audit these scripts for exploitable security issues.