Pentest Skill

---
name: pentest
description: "PTES-aligned adversarial security audit for backend, frontend, and mobile applications. Produces a CVSS-scored Hacker Report with verified PoCs and phased remediation."
metadata:
  internal: true
  triggers:
    keywords:
    - pentest
    - workflow
---
# Pentest Skill

> [!IMPORTANT]
> PTES-aligned adversarial security audit for backend, frontend, and mobile applications. Produces a CVSS-scored Hacker Report with verified PoCs and phased remediation.

Optional args: slug=<feature>, ticket=<id/url>, mode=interactive|autonomous|channel, channel=<id>, auto_continue=true|false, profile=business|hybrid|technical.

## Instructions

When the user asks to perform this workflow, execute the following steps:


# 🕵️‍♂️ Penetration Test (PTES-Aligned)

Goal: Execute a red-team assessment across backend, frontend, and mobile targets with verified PoCs and audit-grade evidence.

## Steps

1. Scope and authorization:
   - Determine mode (`whitebox`, `greybox`, `blackbox`) and targets.
   - Verify explicit, current authorization, target exclusions, permitted techniques, time window and stop contact. Require demonstrated runtime controls for live actions; unsupported controls block execution, not offline planning.

2. Intel and threat model:
   - Identify stack, endpoints, parameters, local storage, schemes, and secrets.
   - Use `common-security-audit`, `common-dast-tooling`, and architecture docs when available.
   - Map trust boundaries, secrets, external integrations, and privileged workflows before exploit attempts.

3. Vulnerability analysis:
   - Run scans and delegate: SAST/SCA to `specialist-aspm-correlator`, dynamic/logic to `specialist-logic-hacker`, binary/mobile to `specialist-mobile-reverser`.
   - Rank targets by `exposure × sensitivity × auth_coverage`.

4. Exploit verification:
   - Confirm findings only with reproducible evidence within scope; never force unsafe exploitation.
   - Optional lab handoff: When verifying an exploit hypothesis against an isolated synthetic lab target, hand off to `cyber-lab-validation` with action-specific authorization and verified host isolation controls.
   - Prohibitions: Never target production/public assets, use real credentials, or exfiltrate real data.
   - If active verification is blocked, refused, or unsupported, record step `blocked` or finding `not-tested`; continue independent threat modeling, code review, and remediation guidance without retrying with disguised prompts.
   - Preserve `suspected`, `blocked`, `not-tested` and `false-positive` dispositions separately from `confirmed`; record missing evidence, preconditions and blast radius.
   - Use synthetic identities/data; no real sensitive-data extraction. Stop on scope drift or impact; obtain approval before restarting.
5. Reporting:
   - Write `artifacts/security-review.md` with assumptions, source provenance, review context, runtime contract, PoCs, blast radius, finding confidence, exploit path, evidence gaps, and handoff notes.
   - Emit `artifacts/security-review.dev.md`, `artifacts/security-review.appsec.md`, or `artifacts/security-review.exec.md` only when leadership, client, or AppSec reporting is in scope.
   - Score from 100: Critical -25 (cap 25), High -15 (cap 40), Medium -8, Low -3.
   - Reuse the existing `security-review.md` record when pentest follows earlier design or PR security review work.
   - Deliver findings in the standard template below.

## Output Template

### Executive Summary

- **Hacker Score**: X/100 ([Critical/Vulnerable/Moderate/Hardened])
- **Target Scope**: [repos, URLs, mobile apps]
- **Findings**: [Critical/High/Medium/Low counts]

### Findings Table

| ID | Title | Platform | Severity | CVSS | CWE | PoC |
| --- | --- | --- | --- | --- | --- | --- |
| SEC-01 | [title] | [backend\|frontend\|mobile] | [Critical\|High\|Medium\|Low] | [score] | [CWE-id] | [Yes\|No] |