Challenge
Segmentation testing needs a repeatable source boundary, bounded probes, and evidence that can be reviewed later. A broad scan alone does not show where the test started or support a defensible retest.
Project case study
seg-test
A scoped CDE reachability evidence runner for authorized PCI DSS segmentation-testing workflows.
Context
Why it exists and what I built.
Design decision
Treat source validation, dry-run visibility, bounded execution, and evidence packaging as part of the test itself. Leave effectiveness and compliance conclusions to qualified human review.
Contribution
Designed and built the source-CIDR guard, dry-run plan, scoped Nmap, netcat, and curl checks, prior-finding retest path, and timestamped evidence archive.
Outcome
The utility produces a consistent reachability evidence package with a SHA-256 sidecar while keeping pass, fail, and compliance decisions outside the script.
How it works
Four stages from input to evidence.
Validate source
Confirm that the runner is executing from the authorized source boundary.
Preview scope
Show the planned targets and checks before any probe is sent.
Test routes
Run bounded TCP, UDP, and application-layer reachability checks.
Package evidence
Archive timestamped outputs and create a SHA-256 integrity sidecar.
Evidence and limits
What the source supports.
What the project demonstrates
- The Bash workflow passes syntax validation.
- A source-CIDR guard and dry-run preview are present in the reviewed source.
- The workflow packages timestamped evidence with a SHA-256 sidecar.
What the project does not claim
- There is no public automated test suite or tagged release.
- Reachability evidence does not by itself prove segmentation effectiveness or PCI DSS compliance.
- The utility is intended only for explicitly authorized and carefully bounded testing.
CyberKareem/seg-testSource snapshot at commit db8d0cce2c3a06af20d3974a9cc59611f4415099. Later repository changes are outside this case study.
Inspect pinned revision opens in a new tab