skills/tahr-audit-secrets-config/references/exploitability-research.md

# Exploitability Research

Use advisories and exploit intelligence as bounded navigation, never proof.

## Search only after detection

Start with exact product, resolved version, platform, configuration, and affected feature evidence. Search official advisories, vendor release notes, and primary vulnerability records first. Record the source and publication/fix version.

Avoid broad product-name searches that produce unrelated versions or modules. Do not download or run public exploit code merely because it exists.

## Build a reachability record

For each advisory, record:

- package/image/action/plugin and exact resolved version;
- affected version range and backport status;
- vulnerable function, protocol, endpoint, parser, configuration, or feature;
- first-party import or invocation path;
- attacker-controlled input and required privileges;
- deployment prerequisites and platform assumptions;
- compensating controls and whether the feature is enabled;
- fixed version or minimal compatible mitigation;
- state: `version-candidate`, `reachable-candidate`, `attempted`, `proven`, or `not-applicable`.

Only `proven` supports a runtime exploit claim. `reachable-candidate` can support a concrete validation target. A version-only match is dependency hygiene unless the risk is independently actionable.

## Validate safely

Prefer a focused unit or integration test against a local/disposable instance. Use a benign marker and the least privilege needed. Do not run destructive, persistence, credential-theft, or third-party exploit actions. Preserve exact observations and negative controls; a timeout or tool failure is a limitation, not disproof.