risk-discovery

name

risk-discovery

description

Passive, pattern-calibrated risk discovery for authorized security research over an open-source project, repository URL, dependency, release, or local checkout. Use when the security research agent needs to find highest-risk areas, map attack surface, identify likely bug-hunting targets, prioritize security review, inspect structural/logical/security-critical code, compare vulnerable versus patched versions, reason from broad high-severity vulnerability families, or remember areas of interest for later attack-chain research.

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.

Ground Rules

• Stay passive unless the user explicitly approves active probes, exploit checks, mutation, downloads outside the repo, shelling into live targets, or destructive calls.
• Treat the provided repository or local checkout as authorized scope only. 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.
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. Store the top areas of interest as concise memory cards so later turns can connect new primitives to existing risk.

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: <unconfirmed | likely | confirmed-area | deprioritized>
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"