defining-pentest-scope

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 <[e-mail]>
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:

1. 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.
2. 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.).
3. 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)