product-pentest

name	product-pentest
description	Produces a PENTEST-PLAN.md then PENTEST-FINDINGS.md for your OWN app's attack surface (each finding reproduced, non-destructive, with remediation) after a blocking authorization+ownership check. Use to test an owned app's attack surface defensively.

product-pentest

The attack-surface producer of the security-testing pack (D5, opt-in). It tests your own authorized application — injection, auth/session, access control, secrets, misconfiguration — writes a PENTEST-PLAN.md (scope, method, expected evidence), and on an authorized run records PENTEST-FINDINGS.md (each finding reproduced against the app, non-destructive, with a remediation owner). It is defensive: find-and-fix on an app you own, never intrusion on someone else's. Authorization plus ownership is the blocking precondition — no owned scope, no test.

A pre-execution plan verifies by Review (sound, scoped, safe, non-destructive); the live findings verify by Audit on the authorized run (real, reproduced, remediable). The verifier never fabricates a "tested / clean" for a test that did not run.

What this does / does not do

Does: confirm authorization + ownership first (blocking); scope the attack surface + boundary (in/out); choose a non-destructive test method + the expected evidence; write PENTEST-PLAN.md; on an authorized run, reproduce each finding against the app and record PENTEST-FINDINGS.md with severity + remediation owner; write a receipt. Does not: test an app it does not own or is not authorized for, exceed the agreed scope, run a destructive test, move data off the system, produce a reusable exploit/intrusion kit, or claim a result for an unrun test.

When NOT to use

• No confirmed authorization + ownership of the app — that is blocking; stop and get it, do not test.
• The request is static analysis over source — that is sast-scan; or probing an AI model — that is ai-red-team. This sub_target tests the running app's surface.
• The ask is a reusable exploit, an intrusion against a third party, or a destructive test — refuse; the scope-frame + ai + security gates reject it regardless of framing.
• The work is auditing controls/design rather than testing the live surface — that is security-review.

Reference Routing

Situation	Reference
Thin inputs / no scope / weaponization or third-party ask	rules/cold-start.md
Per-sub_target must-declares · overlay · vocabulary	../acceptance/sub-targets.md · ../acceptance/overlay.md · ../vocabulary.md
Sibling sub_targets (owned source / AI model)	sast-scan · ai-red-team

Inputs

• The owned application + the authorization/ownership evidence (system, boundary, sign-off).
• The attack surface in scope (endpoints, auth flows, inputs) and what is explicitly out of scope.
• The security-testing pack (../vocabulary.md, ../acceptance/) + state/intake.json.

How to do it

1. Authorization + ownership (blocking). Confirm the requester owns/controls the app and has authorized the test — system, boundary, sign-off, evidence. Without it, stop and record the gap; no owned scope, no test.
2. Scope the surface. State what is in scope (which endpoints/flows/inputs), what is out, and the boundary the test will not cross. Declare the non-destructive posture — no data loss, no denial of service.
3. Choose the method + expected evidence. For each attack class (injection, broken auth, access control, secrets, misconfig), name the test method and what evidence would confirm a weakness. This is the plan.
4. Write PENTEST-PLAN.md. Scope + boundary + method + expected evidence + the non-destructive rule. The plan verifies by Review; the live run is deferred until authorized.
5. On the authorized run, reproduce. Execute the plan within scope; reproduce each candidate against the app before it is a finding. Stay non-destructive and inside the boundary; an unreproduced candidate is a hypothesis, not a finding.
6. Rate + remediate. Severity + remediation owner per finding; findings and any captured data handled safely (least-privilege, nothing exfiltrated). Redact secrets.
7. Write PENTEST-FINDINGS.md — reproduced findings + remediation + the coverage vs the planned surface.

Gate (before marking complete)

• Authorization + ownership confirmed and recorded (blocking) — no owned scope, no test.
• Scope + boundary declared; the test posture is non-destructive (no data loss / no DoS).
• The plan names method + expected evidence per attack class; it verifies by Review.
• On an authorized run, every reported finding was reproduced against the app; hypotheses listed apart.
• Severity + remediation owner per finding; secrets redacted; nothing exfiltrated (security gate).
• The output is a plan + defensive findings — no reusable exploit/intrusion kit (ai gate); an unrun test is recorded as deferred, never as "clean".

A gate failure is fixed before lock, not waived — these mirror the authorization/testing/engineering gates.

Output

• PENTEST-PLAN.md (and, on an authorized run, PENTEST-FINDINGS.md) at the product root (or under security-test/ if that dir exists) — persistence: Spec-Anchored. Authorized scope + boundary · method + expected evidence · non-destructive rule · findings (reproduced, severity, remediation owner) · coverage.
• receipt (<workspace>/receipts/product-pentest-receipt-<ts>.json): base schema + sub_target, authorization_confirmed, scope, attack_classes, non_destructive, findings_count, run_status, plan_path, findings_path, gate_checks. persistence: Spec-Anchored.

Completion Criteria

Done when: authorization + ownership were confirmed (blocking), a non-destructive PENTEST-PLAN.md scopes the surface with method + expected evidence (Review-verified), and — on an authorized run — every reported finding was reproduced within scope with severity + remediation, secrets redacted, and a receipt records the gate checks.

Not done if: any test ran without confirmed authorization/ownership; the test exceeded scope or was destructive; an unreproduced candidate is reported as a finding; data was exfiltrated; a reusable exploit was produced; or an unrun test is reported as "clean".

Next step: remediation owners fix the findings; a re-test confirms closure. sast-scan covers owned source; ai-red-team covers an AI model.

Related Skills

• sast-scan / ai-red-team: sibling security-testing sub_targets — static over owned source / an owned AI model. product-pentest tests the running app's surface.
• security-review: audits controls + design. product-pentest actively tests the live surface; the review reasons about the controls around it.
• verifier: Reviews the plan (sound / scoped / non-destructive) and Audits the run's findings; it never fabricates a "tested / clean" for an unrun test.