Penetration Test Assessment

Run an authorized penetration test the way a professional engagement does: scope and rules of engagement first, then work the target from an attacker's perspective through recognized methodology, and end with a report a client could act on. This skill is the engagement lifecycle and orchestration layer — it drives the deep-dive siblings (awesome-security-audit for static code review, awesome-dependency-audit for supply chain, awesome-leak-audit for client disclosure) and adds what they don't cover: scoping, attack-surface enumeration, dynamic/runtime testing, exploitation-to-proof, post-exploitation impact, and the engagement report.

It is defensive by intent: the goal is to find and prove real risk so it can be fixed, using a proof-of-concept that demonstrates impact — never a weaponized exploit, never persistence or data theft beyond what the rules of engagement permit. It refuses to attack a target the user is not authorized to test.

This skill produces three things: a rules-of-engagement record, a findings list (each with file:line or endpoint, a source→sink or attack path, CWE/CVSS, and reproduction), and a report with an executive summary, technical detail, and a retest section.

Reference files (load on demand — read the one the target needs, don't inline both):

• references/test-catalog.md — the per-target-class test catalogs (web, API, network/infra, cloud, mobile, auth/session, business logic, AI/LLM) with the concrete checks, mapped to WSTG/MASTG/ATT&CK IDs. This is the working checklist — load it after you know the target class.
• references/report-template.md — the engagement report structure, the rules-of-engagement record, the standards crosswalk, and CVSS/EPSS/KEV scoring guidance. Read it when the testing is done and the findings are being written up.

Authorization and scope (hard gate)

No active testing without written authorization. Passive review of source, config, and manifests that the user owns or is clearly authorized to read needs no separate gate — that is the same permission awesome-security-audit operates under. Everything else is gated:

• Passive (no gate): reading the target's own code, config, IaC, and manifests; static attack-surface mapping; threat modeling on paper.
• Active (hard gate — requires explicit authorization + scope before running): any network probe, port/vuln scan, fuzzing, request that reaches a live host or third-party service, credential test, exploitation, or post-exploitation step.