Risk Discovery

Use this product-side skill to find the highest-risk areas in a Target without active exploitation. Produce durable Security Signals and Hypotheses that later research turns can use to connect structural weaknesses, logic flaws, and security-critical behavior into plausible attack chains. See GLOSSARY.md for shared terms.

Read risk-taxonomy.md before scoring a new Target or when the user asks why an area is high risk. Read cvss10-backsolve.md before the first pass over a new Target, when doing broad high-severity rediscovery, or when calibrating whether the process covers critical precursor families.

Handoffs: Use bug-hunt-planner to turn ranked areas into experiments. Use reverse-engineering-analysis for binary, bundle, or patch-diff work. Use exploitation-sandbox only after a Hypothesis needs approved local validation.

For services accepting document, image, audio/video or archive uploads, apply the upload processing audit baseline. Trace intake through delayed or optional processing and actual native dependencies; include its chain inventory, control assessment and unresolved edges in the review output. This applies even when the upload handler only stores bytes.

Ground Rules

• Stay passive unless the user explicitly approves active probes, exploit checks, mutation, downloads, shelling into live targets, or destructive calls; active work requires target authorization plus a matching durable approval (docs/durable-approvals.md).
• Treat the provided repository or local checkout as authorized scope only. All network fetches — the repo URL itself, cloning, advisory or registry lookups, version checks — are network operations needing explicit approval or satisfied durable authorization; local checkout analysis is the passive default. Do not pivot to third-party services, real deployments, package registries, or cloud resources unless authorization is explicit.
• Do not produce weaponized exploit instructions. Stop at vulnerable area, bug class, data/control-flow evidence, and safe validation ideas.
• Preserve uncertainty. Distinguish observed code facts from hypotheses and likely attack-chain opportunities.
• Keep examples generic. Do not inject target-specific benchmark answers, known vulnerable paths, exact payload strings, CVE root-cause prose, patch hunks, or previous eval findings into the plan unless the user explicitly asked for known-issue replay.

Workflow

1. Scope the target. Identify repo URL, local path, requested version/hash, language/ecosystem, public-facing surfaces, and whether the task is broad discovery or CVE-style rediscovery. When the starting point is a CVE or patch rather than a broad risk question, start from proactive-security-strategy instead; this skill owns broad structural risk ranking over a Target.
2. Check memory first. Look for prior project memories, risk maps, package notes, advisories, previous high-risk files, and unresolved hypotheses. Reuse stable facts; update stale assumptions.
3. Build the system map. Read manifests, routing/entrypoints, service boundaries, config, auth/middleware, plugin systems, serialization formats, storage layers, job runners, admin surfaces, and test fixtures.
4. Sweep Discovery Lanes. For broad target scanning, sample across input handling; access control and auth/session; information disclosure and debug; exposed files/directories; and browser/API security posture before deepening one area. Aim for 3-5 distinct Evidence-backed lanes when the Target supports them, and put unsupported lanes in Open Questions.
5. Find structural risk. Prioritize chokepoints: parsers, protocol handlers, request dispatch, auth gates, plugin loading, template rendering, sandboxing, shell/process execution, file/archive handling, deserialization, SSRF-capable fetchers, package/model loading, and cross-tenant state.
6. Find logical risk. Look for state-machine gaps, inconsistent authorization checks, confused deputy flows, trust-boundary collapse, TOCTOU, hidden default behavior, partial validation, fallback paths, migration compatibility code, and feature interactions that make a harmless primitive dangerous.
7. Find critical areas. Flag authN/authZ, destructive actions, asymmetric behavior, admin/support features, import/export, backup/restore, webhooks, credentials/secrets, signing/verification, sandbox escapes, dependency install/build steps, and any code path that writes files, spawns processes, evaluates code, or changes privileges.
8. Backsolve against high-severity precursor families. Use the casebook to ask whether this Target has analogous primitives: deserialization of untrusted data, server component/protocol decoding, model or object loading, command construction, auth/audit bypasses, sandbox setup, filesystem mounts, archive extraction, path construction, user/account/role creation, permission checks, plugin/workflow execution, and privileged background jobs.
9. Check patch and drift signals. If the repo has releases or a suspected vulnerable range, inspect nearby commits for security-shaped changes that are not clearly documented: new sanitizers, deny-lists, escaping, auth middleware, path normalization, deserialization guards, sandbox hardening, removed debug endpoints, permission checks, and changes with vague messages like "fix edge case".
10. Rank and remember. Score candidates with the taxonomy. Record any measured or directly seen behavior as a Research Observation via security-observation-intake (record_observation), register measured outputs as Artifacts through the Evidence Interface (src/server/evidence/artifact-service.ts), and store the top areas of interest as concise memory cards that cite those Observation/Artifact IDs — cards are pointers, not evidence owners.

Memory Cards

When memory is available, write or update one card per top area:

Risk area: <short stable name>
Target: <repo/package/version or local path>
Files/functions: <specific symbols or paths>
Risk class: <structural | logical | critical | patch-drift>
Discovery lane: <input handling | access control/auth/session | information disclosure/debug | exposed files/directories | browser/API security posture | other>
Trust boundary: <who controls input/state and what code trusts it>
Why it matters: <one or two concrete facts>
Attack-chain hooks: <safe, non-exploit primitives this could combine with>
Validation idea: <passive or sandbox-only check>
Status: <confirmed | likely | speculative> (glossary Signal labels)
Area status: <active-area | confirmed-area | deprioritized>
Evidence citations: <Observation/Artifact IDs backing the card>
Updated: <YYYY-MM-DD>

Use stable category names like server-protocol-reference-deserialization or webhook-parser-prototype-pollution. Do not store secrets, exploit payloads, live credentials, or unrelated user data.

Output

Return:

• Scope: repo/path, version/hash, constraints, and whether analysis was passive-only.
• Top Areas: ranked table with area, paths, risk class, score, evidence, and next safe validation step.
• Discovery Lane Coverage: which broad lanes have Evidence-backed Signals and which remain open questions.
• Precursor Coverage: which high-severity precursor families were investigated, which files/symbols matched them, and which families had no obvious analogue.
• Memory Cards: the high-signal cards created or updated.
• Patch-Drift Signals: suspicious or security-relevant undocumented changes, if any.
• Deprioritized Areas: notable surfaces that looked risky but had clear guards.
• Open Questions: missing scope, authorization, runtime config, or data needed for deeper validation.

Useful Search Patterns

Start broad, then trace call sites:

rg -n "auth|authorize|permission|role|admin|token|session|jwt|saml|oauth|acl"
rg -n "exec|spawn|shell|eval|Function\(|deserialize|pickle|yaml\.load|template|render"
rg -n "upload|download|import|export|backup|restore|archive|zip|tar|path|filename"
rg -n "webhook|callback|plugin|extension|mcp|tool|connector|workflow|node"
rg -n "sandbox|isolate|mount|chroot|namespace|uid|gid|useradd|role|policy|audit|log"
rg -n "TODO|FIXME|HACK|compat|legacy|fallback|bypass|sanitize|escape|normalize"