proactive-security-strategy

name	proactive-security-strategy
description	Turn a specific vulnerability, patch, CVE, Version Diff, or Changelog Claim into a proactive security exploration plan. Use when the user wants research angles, lateral target discovery, patch/CVE strategy, new surface discovery, or hypothesis generation from vulnerability intelligence.

Proactive Security Strategy

Use this skill to move from a concrete vulnerability input into bounded, high-leverage research work. See GLOSSARY.md for shared term definitions.

The output is a set of Security Signals, ranked Hypotheses, and optional Subject relation updates. Keep work oriented toward authorized investigation, passive analysis, local reproduction, public sources, and clearly scoped captures.

Starting Inputs

Start from one or more of:

• CVE, advisory, commit, release, or emergency patch.
• Version Diff between affected and fixed versions.
• Changelog Claim that hints at a security fix.
• Public exploit writeup, crash report, PoC, or maintainer discussion.
• A user-supplied Subject such as a product, library, protocol, or subsystem.

Normalize the input into:

• Affected Subjects and versions.
• Vulnerability class and likely root cause.
• Patched behavior, removed behavior, or newly added guardrail.
• Primitives implied by the patch: parsing, authz, deserialization, template rendering, request routing, sandbox escape, cache poisoning, or file handling.
• Evidence quality: confirmed source, inferred clue, or speculative angle.

Exploration Angles

Present these options to the user unless they gave a narrow instruction. Default to passive paths when no preference is stated:

Angle	Description	Risk
software-class	Find lateral Targets by software class: sibling products, forks, plugins, SDKs	Passive
usage-patterns	Find projects using the patched API, library version, or dangerous call pattern	Passive
official-surface	Review releases, advisories, docs, changelogs, and package metadata	Passive
unofficial-surface	Look for pre-release branches, feature flags, source maps, beta docs, emergency patches	Passive
patch-diff	Compare vulnerable and fixed versions to extract the vulnerable primitive	Passive
exploit-chain	Map how this primitive could chain into broader impact	Passive/Speculative
local-repro	Build a bounded local reproduction in a Workspace Container and capture Evidence	Requires isolation

Flag any angle that requires active probing, network access, or touching systems outside the user's scope before proceeding. Describe the risk and wait for explicit approval.

When interactive choices are supported, present the exploration angles as a concise multi-select decision with a short description, risk, and approval state for each option. Make the passive defaults clear and preserve the same decision-ready content in plain text when interactive output is unavailable. Choose the available presentation mechanism from the active response contract; do not expect the user to name an internal UI component.

Workflow

1. Anchor the facts. Identify the exact advisory, CVE, affected and fixed versions, and upstream wording. Separate confirmed facts from inferences.

2. Extract the primitive. Read the patch or diff first when available. Name the vulnerable behavior in concrete terms: input shape, trust boundary, parser, permission check, race, memory lifetime, request path, dependency behavior, or environmental assumption.

3. Generate Security Signals. Turn each clue into a concise signal with source, confidence label, affected Subject, and why it may produce research work.

4. Offer exploration angles. Present the table above, note which are passive versus active, and ask the user which to pursue. Default to passive-only when uncertain.

5. Explore lateral targets.

   • By software class: sibling products, frameworks, plugins, appliances, hosted services, SDKs, and forks that solve the same problem.
   • By code/library usage: search for the patched function, dependency version, API pattern, parser configuration, copy-pasted code, vendored library, or equivalent anti-pattern.
   • By deployment shape: CLIs, daemons, web routes, workers, mobile clients, browser code, or infrastructure glue.

6. Discover new surface area.

   • Official: releases, advisories, docs, API references, changelogs, migration guides, package metadata, container tags, and deprecation notices.
   • Unofficial but public: pre-release branches, feature flags visible in client assets, beta docs, source maps, public staging references, issue comments, emergency patch commits, backports, hotfix branches, and distribution-specific patches.
   • Treat emergency patches as clues to public-observable behavior, not permission to access private systems.

7. Rank Hypotheses. Prefer testable ideas with a clear first step, scoped Subject, likely impact, and cheap falsification. Queue Sub-hypotheses breadth-first instead of recursively expanding.

8. Capture Evidence. Record diffs, source links, local repro output, screenshots, traces, and reasoning as durable Evidence. Store large bodies as Artifacts and link them.

Output Shape

• Security Signals: clue, source, confidence label, affected Subject, and why it matters.
• Hypotheses: ranked title, target surface, rationale, first step, expected Evidence, and stop condition.
• Subject relations: affects, uses, patched_by, exposes, or chains_to edges to add.
• Safety notes: any angle that needs explicit approval before active testing, and why.

Handoffs

• Use bug-hunt-planner to turn ranked Hypotheses into a full staged hunting plan.
• Use web-inspection-forensics for passive surface mapping of a web Target.
• Use reverse-engineering-analysis when the patch touches a binary, native library, or JavaScript bundle.
• Use exploitation-sandbox to safely develop and verify a PoC once a Hypothesis is well-founded.

Guardrails

• Do not propose uncontrolled scanning, credential harvesting, persistence, stealth, destructive actions, or access to non-public systems.
• Prefer passive discovery, public artifacts, local reproduction, and scoped Captures.
• Redact secrets and sensitive tokens from Evidence summaries and previews.
• Use confidence labels — "confirmed", "likely", "speculative" — on every Signal and Hypothesis.