vulnerability-validation

<!-- GENERATED FROM skill-core/vulnerability-validation.md BY scripts/sync_agent_surfaces.py. --> <!-- Do not edit this generated surface. Edit skill-core/ and run make sync. --> <!-- CANONICAL_SKILL_START -->

Vulnerability Validation

Use this workflow to discover new vulnerabilities (0-days) in a target repository and validate them. By default it runs native discovery: with no findings list it analyzes the code to find vulnerabilities itself; a scanner finding, researcher report, or PoC is only an optional seed. Reduce every candidate to a defensible disposition, fix true issues with minimal idiomatic patches, and leave evidence another engineer can replay.

Quick Start

For target reads, PHASE-0 starts with an external operator-controlled verifier authenticating the whole package outside the target and neutralizing project-local discovery before startup; the loaded package cannot attest itself. Without both proofs, stop at documentation/package compatibility with no target read. After proof and operator authorization, record run-state.bootstrap.json, then search AI-use/security policy, threat model/boundaries, disclosure process, and upstream sources. Collect target repository/branch, latest upstream HEAD, baseline SHA, dirty state, finding source type, frozen snapshot or seed sources/counts, artifact root, local-only validation environment, dependency installation/provisioning method, upstream URL, repo commands, and output mode.

Read references/portable-invariants.md and create run-state.json before triage. For the default native discovery run, load references/discovery-intake.md; optionally run scripts/discovery_engine.py for a first pass,. Load references/artifact-contract.md when needed: references/artifact-index.md, references/controlled-fields.md, references/closure-bundle.md, references/drift-gate.md, references/evidence-bundle.md. Read references/review-lenses.md before claiming review consensus and references/policy-friction.md when the LLM refuses or hedges.

Nonnegotiable Gates

• PHASE-0 Bootstrap Gate (before the AI Policy Gate / any target read): an external verifier rooted in operator-pinned evidence authenticates the whole outside-target package and proves project-local skill and instruction discovery disabled before agent startup. Only then record run-state.bootstrap.json (references/shadow-skill-bootstrap.md). That record and its validator witness consistency only; they cannot self-attest pre-load trust. Missing external authenticity or neutralization proof means documentation/package compatibility with no target read, not internal_triage, source-only, empirical, or autonomous execution. Implicit activation is passive: until an operator-originated record binds target and scope, do not read the target, write artifacts, run tools, access the network, or provision anything.
• AI Policy Gate: after PHASE-0, the first target-repository documentation action is AI-use policy discovery. If documented policy prohibits or restricts AI use, stop before triage, cite the source, inform the user, and ask for direction. A maintainer-facing disclosure carries the ai_disclosure_mode the discovered policy requires: named-agent attribution where the project asks for it, a human-authored verified/unverified-split disclosure where the project treats AI reports as low-trust ("slop") — which an autonomous run stops for a human to author rather than self-writing — or a brief honest one-line notice otherwise; a missing, policy-mismatched, or autonomously self-authored-split notice blocks FILE-READY (references/controlled-fields.md).
• Project Plan Gate: before validating findings or writing patches, create a project plan covering every item in references/project-plan-gate.md (the full nonnegotiable checklist). Optimize for correctness, then simplicity, then speed.
• Finding Completeness Gate: before severity-based ordering, validation, PoCs, or patches, build a complete worklist from original finding artifact(s). Unless the user explicitly scopes smaller, include every finding in the original artifact across all severities, confidences, components, and disposition guesses. Every original in-scope row needs a stable ID, verification row, queue or status row, initial threat-model or security-boundary gate, upstream-correlation path, owner or lane, next action, and closure path. Severity may drive ordering and batching only after the worklist exists; it must not silently exclude rows. Normalize every original in-scope row; do not drop lows, informationals, duplicates, or scanner-confidence outliers without explicit closure or scoped-out rationale. Counts must reconcile through closure-count total.
• Empirical Progress Rule: do not halt because full validation may take a long time or because tooling is missing. For each in-scope executable finding, run the smallest safe local empirical step that can increase certainty: source reachability, existing focused test, tiny harness, local fixture, then isolated dependency provisioning. Time cost, missing tools, and unfamiliar setup are planning inputs. Use bounded attempts with timeouts, install only the next required dependency, and continue queued work when an attempt needs later follow-up.
• Latest-HEAD Filing Gate: do not file, publish, or hand off a maintainer-facing vulnerability claim until it is validated against the target repository's latest upstream target-branch HEAD. Use git ls-remote or an equivalent remote lookup and record target remote URL, branch, HEAD SHA, lookup command or source, timestamp, dirty state, and validation environment. Also re-validate on the latest released toolchain/runtime and the latest released dependency/module the finding touches (e.g. latest Go+module@latest, or JDK+Maven Central) from its own authoritative source — or, where the ecosystem lacks package modules, the affected component or a not-applicable rationale; record exact versions and authoritative source, and if it no longer reproduces on latest use the matching closure and adjust the affected- version claim. Immediately before filing or maintainer handoff, recheck the target upstream HEAD. Missing, stale, blocked, or changed latest-HEAD proof blocks filing. If the issue no longer reproduces or claimed code is absent, use the matching closure status instead of filing. If target branch, source commit, or any artifact labeled latest changes during a long run or resume, pause affected closure or publication work and reconcile before continuing. The pre-filing recheck is a behavior re-proof, not a SHA-equality check: re-run the finding's reachability or PoC oracle (or re-grep the sink and any new in-path guards) against the freshly-fetched HEAD; route to a fixed or not_present closure only when the primitive no longer fires or the claimed code is absent — a newly-present guard, mitigation, or partial fix that does not neutralize the primitive is never by itself a closure but stays an incomplete-fix or residual-hardening candidate, re-scoped to what still fires. Record demonstrated_impact per references/controlled-fields.md and propose the minimum severity tier whose CVSS vector derives from it; a higher claimed tier blocks filing absent a reviewer-resolved override. Subtract a precondition from the tier only when the attacker must additionally acquire it and it is out of scope per the target's published security policy (an out-of-scope attacker-acquired precondition); never subtract the in-scope untrusted-input channel that is the vulnerability itself. The floor binds the reporter's claim only; the maintainer may rate higher. A maintainer-facing finding is additionally blocked from filing unless it ships the three-part Evidence Bundle of ## Evidence Bundle (mandatory for FILE-READY), with its captured stdout re-fired at this freshly-fetched HEAD. Filing additionally requires the finding sit inside the project's published threat model, security boundary, and intended usage (threat_model_fit); an out-of-model or by-design behavior routes to the matching closure (risk_accepted_design_contract, risk_accepted_documented_opt_in, or policy_excluded) instead of a filing.
• Source-Identity & Provenance Gate: before normalizing or assigning any disposition, establish and record the authoritative upstream — discover it explicitly (a popular host may be a stale/read-only mirror) and record the authoritative remote URL, branch, HEAD SHA, the SHA of the tree under validation, and its ancestry to that branch. Never validate, close, or carry forward a finding against a local fork, patched working tree, mirror, or non-target branch as the authoritative upstream; a validated_fixed closure or prior_fix_status=exact_fix proven on a fork-with-patch or a different branch is invalid until re-proven on the authoritative tree. When a source cites commit identifiers, confirm they exist in authoritative history; if a meaningful fraction are absent (a synthetic, poisoned, or fork-only source), quarantine the source, record the verdict, and ask the user before validating it. Ingest a prior maintainer rejection of an equivalent report as maintainer_rejected_prior: it blocks re-filing absent new evidence and reviewer consensus and is not itself a closure.
• Not-Already-Open-Upstream Gate: before filing or maintainer handoff, search the authoritative upstream's open and recently-closed issues and pull requests, and any project advisory list, for an existing report or fix of the same primitive; a report match records prior_report_status, a fix match prior_fix_status (references/controlled-fields.md), then routes by state — the fix-based closure once it no longer fires, else a supplementary note on the existing thread or the reopen/incomplete-fix path — never a

---

Content truncated.