pentest-specialist

name	pentest-specialist
description	Authorization-gated white-hat penetration testing against an owned or explicitly authorized target. Follows find → validate → fix → regress. Requires the authorization gate before any active testing (crafted requests, exploit runs, scanning, fuzzing). Use for "pentest my app", "test this endpoint for vulnerabilities", or validating an owned finding is truly exploitable.

Pentest Specialist

Trigger

Use this skill when the user wants active security testing of a target they own or are authorized to test — validating that a vulnerability is really exploitable, probing an endpoint, or a scoped pentest — and then fixing it.

If the work is static-only (reading code, threat modeling, dependency review), use adversarial-security-sweep instead; it needs no authorization gate.

Authorization Gate (first step, mandatory)

Before any active testing, confirm and record from SECURITY_AND_PENTEST.md:

1. Target identity (exact repo/service/host/account).
2. Ownership or explicit written authorization.
3. Blast radius (prefer non-production; production requires explicit operator confirmation and a stop condition).
4. Scope boundary (in/out of scope, what is destructive).

If authorization cannot be established, stop and report authorization gate blocked. Do not proceed.

Scope Boundary

In scope: proof-of-concept exploitation just far enough to prove a finding is real, then a fix and a regression test. Out of scope regardless of framing: DoS, mass-targeting, offensive/self-propagating/evasive tooling, testing unauthorized systems, or exfiltrating real secrets/data. Demonstrate reach without harvesting.

Workflow (vulnerability lifecycle)

1. Recon (authorized surface only). Map endpoints, inputs, auth boundaries, dependencies, and trust boundaries. STRIDE the surface.
2. Discover. Identify candidate weaknesses across the OWASP/ASVS categories, supply-chain first.
3. Validate. Build the minimal proof-of-concept needed to prove reachability and exploitability after existing mitigations (residualize — causal protocol). If not reachable or already mitigated, downgrade or drop.
4. Rate. Severity on residual exposure and blast radius, with preconditions.
5. Fix. Remediate at the correct trust boundary (server-side, framework-level, secure default). Avoid new dependencies without approval.
6. Regress. Add a test or CI guard that fails if the vulnerability returns; re-run the proof to confirm it no longer works.
7. Report per references/security-review-contract.md.

Guardrails

• Authorization gate passes before any active testing.
• Keep proof-of-concept minimal and convert it to a fix plus regression.
• Security judgment (exploitability, severity, fix design) stays on the strongest reasoning path; delegate only bounded, verifiable sub-tasks.
• Stop and escalate on destructive potential, scope expansion, production impact, or evidence of an active compromise (switch to incident response and the post-compromise checklist in references/supply-chain-iocs.md).

Output

Findings in the output-contract shape: confirmed and severity-ordered with validation evidence, fixes, and regression protection; refuted candidates separately; authorization basis, scope, not-examined surfaces, and residual risk.