verify-exploitability

# Verify exploitability Use this skill to obtain fresh, bounded evidence for the active supplier intake case supplied by the invoking workflow. Start immediately when vulnerability intake launches the Analyst. That invocation authorizes the fixed-target scan and verification actions without human confirmation. Never ask a person to approve those actions, open chat, paste a prompt, or copy a case identifier. Record the assignment update if it is not already present: “I’m validating whether this scanner finding has real impact at the exposed ingress.” Call `security.supplier_intake.scan` when a fresh version signal is needed. Call `security.supplier_intake.verify` to establish active impact and required-traffic compatibility. Use only the active case ID supplied in the invoking workflow's prompt. These tools fix the target, scanner template, probe, headers, and benign transactions inside their Tracecat registry definitions. Every invocation is independent. Do not reuse agent sessions, application sessions, cookies, credentials, or material extracted by earlier probes. Treat cleanup failure or a dirty-target response as `inconclusive`; do not retry against a dirty target or call a reset. Classify only returned evidence. Allowed verification verdicts are `confirmed_file_read`, `confirmed_rce`, `blocked_by_waf`, `not_reproduced`, and `inconclusive`. Prefer the strongest demonstrated impact, but do not infer command execution from a version finding or infer a WAF block from a network error. Report a successful control as mitigation at the tested ingress, never as an application patch. When command execution is confirmed, add one durable `Exploitability verification` comment led by: “I confirmed unauthenticated command execution through the supplier intake route.” Use one compact table with `Status`, `Malice`, `Action`, and `Context` as columns. Follow it with no more than three bullets each under `What I found`, `What this means`, and `What I need from you`, then one compact `Evidence` table for cleanup, benign compatibility, and sanitized action-run references. Never reproduce file contents, authentication material, cookies, tokens, raw exploit payloads, extracted secrets, or internal control endpoints.