| name | defining-pentest-scope |
| description | Parse the ROE scope definition, enumerate every in-scope target
(hostnames, IPs, CIDRs, URLs, cloud accounts, SaaS tenants),
validate syntax, detect overlap with out-of-scope or known
third-party SaaS ranges, and emit a normalized target list plus
IP allowlist for scanning tools. Runs after confirming-pentest-
authorization and before any cluster 1-4 scan.
Use when: starting an engagement, expanding scope mid-engagement,
validating that a target list matches the ROE, or generating an
allowlist for an external scanner.
Threshold: malformed syntax, in-scope overlap with out-of-scope,
reserved or third-party SaaS ranges without acknowledgement.
Trigger with: "define scope", "enumerate targets", "validate
target list", "generate IP allowlist".
|
| allowed-tools | ["Read","Bash(python3:*)","Glob"] |
| disallowed-tools | ["Bash(rm:*)","Bash(curl:*)","Bash(wget:*)","Bash(nmap:*)","Write(.env)","Edit(.env)"] |
| version | 3.30.0 |
| author | Jeremy Longshore <jeremy@intentsolutions.io> |
| license | MIT |
| compatibility | Designed for Claude Code |
| tags | ["security","engagement-governance","scope","target-enumeration","pentest"] |
Defining Pentest Scope
Overview
A pentest scope is a list of permission boundaries. Get it wrong
and you either (a) miss real exposure by failing to test something
the customer expected covered, or (b) probe something you weren't
allowed to touch and turn the engagement into a liability event.
Both failure modes share a root cause: the scope list was a vague
narrative ("test the marketing site and the API") rather than a
machine-readable, syntactically-validated, conflict-checked
artifact.
This skill takes the in-scope and out-of-scope sections from a ROE
and produces three deliverables:
- Normalized target list — every entry parsed into a
structured form (host vs CIDR vs URL path vs cloud account vs
SaaS tenant), with explicit type tagging. Downstream cluster
1-4 skills consume this list rather than raw strings.
- IP allowlist — flat list of IPv4 and IPv6 addresses /
CIDRs ready to paste into scanner configurations (nmap target
list, Burp scope file, AWS WAF allowlist, etc.).
- Conflict report — Findings flagging syntactically-malformed
entries, overlap between in-scope and out-of-scope, inclusion
of reserved ranges (RFC1918, link-local, multicast), and known
third-party SaaS infrastructure that needs separate authz.
The skill does NOT perform DNS resolution or network probing —
that would itself be a "first probe" of the target, which by the
governance model must happen AFTER scope is locked.
When the skill produces findings
| Finding | Severity | Threshold | Affected control |
|---|
| Malformed target syntax | HIGH | Entry doesn't parse as host / CIDR / URL / account-id | (legal) |
| In-scope overlaps out-of-scope | CRITICAL | An in-scope target falls within an out-of-scope CIDR | (legal) |
| Reserved range without acknowledgement | HIGH | RFC1918, link-local (169.254/16), multicast (224/4), broadcast in in-scope list | (operational) |
| Known third-party SaaS in scope | HIGH | In-scope IP matches a known SaaS range (AWS, Cloudflare, GitHub, etc.) without separate authz | (legal) |
| Duplicate target | INFO | Same target appears multiple times | (operational) |
Wildcard subdomain (e.g. *.acme.example) |
