Threat Exposure Management & Retesting

The Customer Problem: The 4 Exposure and Testing Failures

The "clean scan, compromised perimeter" illusion

Off-the-shelf scanners produce hundreds of unvalidated alerts in a long PDF. Engineers triage the noise and the exploitable finding gets lost in it.

Shadow infrastructure and asset drift

Unmonitored cloud assets, forgotten subdomains and stray endpoints run outside the security and compliance perimeter because nobody compares the inventory to what is actually answering.

The retest void

A finding is marked closed in a ticket or spreadsheet with no repeatable record showing the fix worked on the running system.

Unbounded scanning risk

Automated tools run without written authorization, rate limits or concurrency controls, and put production systems that cannot go down at risk.

The Consequential Solution: Operational Acceptance Testing

User Acceptance Testing asks whether a feature works. Operational Acceptance Testing asks how the running system behaves when it is exposed: what an outsider can reach, what answers, and what breaks. The assessment keeps the answer as data you can query again.

Evidence over assertions. Tool output, run parameters and verified findings are kept in a portable, queryable SQLite database instead of a transient alert stream or a one-off PDF.
Scoped, authorized and bounded. Targets, exclusions, rate limits and concurrency live in a reviewed configuration file that matches the signed rules of engagement.
Closed-loop remediation. A finding moves to validated only after a retest confirms the fix, and the before and after records stay side by side for your auditor.

What Netspective Offers: Engineering Responsibility

Strict rules of engagement

Written mutual scoping, explicit inclusions and exclusions, a testing window and conservative rate limits, all agreed and signed before any testing begins. The rules of engagement name the host and source IP the assessment runs from, so your monitoring can tell the test from an attack, and list every injection tool permitted.

Human analyst validation

Qualified engineers read the raw tool output, confirm what is exploitable, rank it by consequence and write remediation guidance your developers can act on.

Evidence into your compliance plan

Verified findings feed Continuous Compliance as a Service as Plan of Action and Milestones items for SOC 2, HIPAA, ISO 27001, CMMC or FedRAMP work.

Product Architecture: The Dual-Engine System

The service pairs an assessment engine that produces evidence with a Threat Exposure Management layer that moves each finding to closure. Both rest on the open-source evidence engine (CLI: surveilr) and its SQLite Resource Surveillance State Database (RSSD).

Engine 1: technical assessment: A container orchestrates recognized open-source tools in stages (DNS resolution, HTTP probing, technology fingerprinting, port and network mapping, template-based checks) against the authorized scope. Each run writes to a timestamped session folder, results/<timestamp>/<tool>/, as JSON, JSONL, XML and text, plus a consolidated SQLite database. The image is amd64 only; the documented VM install path needs root.
Engine 2: Threat Exposure Management (TEM): The evidence engine ingests the session into SQL, and SQLPage dashboards present it: a findings viewer, an interpretation view for analyst triage, and the raw tool data behind each finding.
Asset reconciliation: Expected assets (from your inventory, infrastructure code or architecture documents) are compared with what discovery observes. Assets that are missing or unexpected are flagged as drift. Reconciliation depends on a setup runbook that is not yet public, so it is scoped per engagement.

What the default run sends. The default runbook (eaa-pentest-lite.spry.md) includes injection testing as well as discovery and template checks: sqlmap and Ghauri (SQL injection), Dalfox (cross-site scripting), Commix (command injection) and WAF-Bypass, alongside Nikto, ffuf, Dirsearch and DNS zone-transfer attempts. Injection payloads can change data and trip incident response. They are run only against applications named in the signed rules of engagement, in an agreed window, and never against systems that cannot tolerate data changes.

OpenVerified by an analyst and assigned
In progressYour team is fixing it
RemediatedFix reported, awaiting retest
ValidatedA retest confirms the fix
ClosedBefore and after records kept

The TEM finding lifecycle described in the vendor's public material. A finding is not validated on the strength of a ticket status alone.

Ingestion & Verification Explorer

Four steps from an authorized scope to a question an auditor can re-ask. Every target is a placeholder; replace it only with assets covered by your signed authorization.

Panel 1: Scoped configuration and run

The scope file is the technical half of the rules of engagement: inclusions, exclusions, rate and concurrency limits. The container reads it and writes each session to a local folder.

# scope.env: every target below must be covered by prior written authorization
OPSFOLIO_EAA_TENANT_ID=<tenant-id>
OPSFOLIO_EAA_DOMAINS=<authorized-target.example>
OPSFOLIO_EAA_KEY_URLS=https://<authorized-target.example>
OPSFOLIO_EAA_IP_RANGES=<authorized CIDR or blank>
OPSFOLIO_EAA_EXCLUDES=<out-of-scope hosts>
OPSFOLIO_EAA_RATE_LIMIT=50
OPSFOLIO_EAA_CONCURRENCY=10
OPSFOLIO_EAA_NAABU_PORTS=top-100
OPSFOLIO_EAA_NUCLEI_TEMPLATES=cves,default

docker run --rm -it --env-file scope.env \
  -v "$(pwd)/scope.env:/opt/eaa/.env" \
  -v "$(pwd)/results:/opt/eaa/sessions/" \
  fleetfolio/fleetfolio            # default runbook: discovery, template checks and injection tests (see the rules of engagement)

# Output: results/<ISO-timestamp>/<tool>/*.{json,jsonl,xml,txt}
#         results/<ISO-timestamp>/*.sqlite.db

Public sample From the public assessment-toolkit Pentest quick start (docs.opsfolio.com) and the fleetfolio/fleetfolio container image, with placeholder targets. It runs from the host and source IP named in the rules of engagement; the image is amd64 only. The rate and concurrency values are a conservative choice for this sample, lower than the documented defaults.

Panel 2: Session evidence into the RSSD

The evidence engine walks the session folder into its SQLite database, so raw output and the run that produced it can be queried together.

surveilr ingest files -r ./results/<ISO-timestamp>/
surveilr shell --output table --cmd \
  "SELECT uri, nature FROM uniform_resource ORDER BY uri LIMIT 20;"

Writes: one uniform_resource row per output file (uri, content, nature) in resource-surveillance.sqlite.db. Commands from the public surveilr CLI reference.

Panel 3: Asset reconciliation query

Compares the expected inventory with endpoints observed in the last two days and labels each gap.

-- Synthetic illustration: expected inventory vs. observed endpoints
CREATE TEMP TABLE expected_asset (asset_tag TEXT PRIMARY KEY, hostname TEXT NOT NULL, boundary TEXT);
CREATE TEMP TABLE observed_endpoint (hostname TEXT NOT NULL, ip_address TEXT, tool TEXT, last_seen TEXT);

SELECT e.hostname, e.boundary, 'missing' AS drift
FROM expected_asset e
WHERE NOT EXISTS (SELECT 1 FROM observed_endpoint o WHERE o.hostname = e.hostname)
UNION ALL
SELECT o.hostname, NULL, 'unexpected'
FROM observed_endpoint o
WHERE NOT EXISTS (SELECT 1 FROM expected_asset e WHERE e.hostname = o.hostname)
  AND o.last_seen >= datetime('now', '-2 days')
GROUP BY o.hostname
ORDER BY drift, hostname;

Synthetic illustration Table names are illustrative, not the toolkit's schema. The query runs as written in SQLite 3.

Panel 4: TEM lifecycle query

Counts findings by severity and state, and shows any finding closed without a retest on record.

-- Synthetic illustration: finding states by severity, and retest proof
CREATE TEMP TABLE finding (
  finding_id TEXT PRIMARY KEY,
  severity TEXT CHECK (severity IN ('critical','high','medium','low')),
  state TEXT CHECK (state IN ('open','in_progress','remediated','validated','closed')),
  retest_session TEXT,      -- session that confirmed the fix, if any
  updated_at TEXT
);

SELECT severity,
       SUM(state = 'open')                               AS open,
       SUM(state = 'in_progress')                        AS in_progress,
       SUM(state = 'remediated')                         AS awaiting_retest,
       SUM(state IN ('validated','closed'))              AS retest_confirmed,
       SUM(state = 'closed' AND retest_session IS NULL)  AS closed_without_retest
FROM finding
GROUP BY severity
ORDER BY CASE severity WHEN 'critical' THEN 1 WHEN 'high' THEN 2 WHEN 'medium' THEN 3 ELSE 4 END;

Synthetic illustration A non-zero closed_without_retest is the retest void from section 1, made visible. Runs as written in SQLite 3.

Verified Proof Ledger (Engineering Ground Truth)

Proof ledger: each claim, its status and what it rests on
Claim	Status	What it rests on
Containerized assessment writing timestamped findings to SQLite	Designed and documented	The public assessment image (fleetfolio/fleetfolio) and Pentest documentation. No recorded run yet.
Session output kept as JSON, JSONL, XML and text in timestamped folders	Designed and documented	The public Pentest quick start (results/<timestamp>/<tool>/). No recorded run yet.
SQLPage dashboards for findings, triage and raw tool data	Designed and documented	The vendor's TEM page and its dashboard screenshots. No recorded run yet.
Expected-versus-discovered asset reconciliation	Designed and documented	The vendor's asset reconciliation page, shown on demo data; the setup runbook is in a private repository. No recorded run yet.
Analyst verification and retest of remediated findings	Designed and documented	Delivered per engagement by Netspective analysts under the signed rules of engagement. No recorded run yet.
Automatic POA&M generation and retest triggers	Designed and documented	Described in documentation; no public configuration yet.
Two-way ticket sync with Jira or ServiceNow	Designed and documented	Listed on the vendor site; no published configuration. Scoped per engagement.
Continuous multi-cloud cost drift reconciliation	Designed and documented	A vendor dashboard shown on a single demo scan; not offered as a continuous service.
Endpoint detection and response (EDR) agent	Not established	Not offered. The toolkit collects evidence; it does not block activity.
A guarantee of zero disruption from active testing	Not established	Not offered. Scoping and rate limits reduce risk; they cannot remove it.
Automated compliance certification	Not established	Not offered. Assessors and auditors decide outcomes.

Regulated Use Cases

Where the evidence goes. A control mapping shows which requirement a record supports; it is not an audit determination, and your assessor decides the outcome.

SOC 2

Verified findings and their retest records, each dated, as evidence your assessor can use for the criteria in scope. People map findings to Trust Services Criteria per engagement; no mapping table is published.

FedRAMP

Verified findings carried into the Plan of Action and Milestones, with retest records an assessor can trace to each closed item. Mapping to NIST SP 800-53 control families is done by people per engagement.

CMMC

For defense contractors: records of active monitoring and tested remediation that an assessor can query against the practices in scope.

ISO 27001

Dated findings and retest records that accumulate between audits, mapped by people to the Annex A controls in scope per engagement.

Engagement detail

What does Netspective penetration testing produce?

Eight test types, from web application to red-team simulation, are mapped to the framework a client is assessed against: SOC 2, ISO 27001, CMMC, HIPAA, or OWASP. Each produces risk-ranked, developer-ready findings and a retest for 100% of findings remediated within the agreed retest window.

Eight test types — web application, mobile, external network, internal network, wireless, cloud, API, and red-team simulation — each producing risk-ranked, developer-ready findings, timestamped artifacts, and before/after retest verification, mapped to the compliance framework a client is actually assessed against: SOC 2, ISO 27001, CMMC, HIPAA, or OWASP.

Eight test types, one evidence standard

Every engagement produces risk-ranked findings with developer-ready remediation guidance, a timestamped and signed record of what was tested and when, and a before/after retest that verifies a remediated finding is actually closed — not just reported as closed.

Evidence-Grade Reports: Timestamped, signed findings mapped directly to the control framework a client is assessed against.
Scoped to Minimize Disruption: Manual, human-led testing scoped to avoid outages on systems that cannot go down.
Retest Verification: For SOC 2 and CMMC assessments of GovCon systems, a before/after retest confirms that 100% of findings remediated within the agreed retest window are actually closed, not just reported closed.
Framework Mapped: Findings mapped to SOC 2, ISO 27001, CMMC, HIPAA, or OWASP — whichever a client is assessed against.

ARCH-SPEC 01: Evidence-Grade Penetration Testing Architecture

OWASP ISO/IEC 27001 DETERMINISTIC VERIFICATION

Eight test types

Web Application Testing (OWASP)

OWASP-aligned assessment of application logic and controls, from authentication flow to business-logic abuse cases.

OWASP Top 10 Coverage
Authentication & Session Testing
Business Logic Abuse Cases

Mobile Application Testing (iOS/Android)

iOS and Android assessment including local storage, API communication, and platform-specific attack surfaces.

Local Storage & Keychain Review
API Communication Testing
Platform-Specific Attack Surfaces

Cloud Infrastructure Review (AWS/Azure/GCP)

Configuration and identity-boundary review across AWS, Azure, and GCP, including IAM privilege-escalation paths.

IAM Privilege-Escalation Paths
Storage & Bucket Exposure
Network Boundary Configuration

API & Microservices Testing

REST and GraphQL endpoint authorization and input-handling testing across a service mesh's actual trust boundaries.

REST & GraphQL Authorization Testing
Input-Handling & Injection Testing
Service-to-Service Trust Boundaries

External Network Testing

Internet-facing hosts and services assessed from outside the perimeter, against the scope and rules of engagement you authorize in writing.

Exposed Service Enumeration
TLS & Certificate Review
Perimeter Access-Control Testing

Wireless Network Testing

On-site assessment of wireless networks for weak encryption, rogue access points and guest-to-corporate segmentation gaps.

Encryption & Authentication Review
Rogue Access Point Detection
Guest Network Isolation

Internal Network Segmentation

Post-breach lateral-movement and segmentation testing to verify a compromised host actually stays contained.

Lateral-Movement Testing
Network Segmentation Verification
Internal Access-Control Review

Red Team Adversary Simulation

Objective-based, multi-vector adversary simulation testing detection and response, not just exploitability.

Objective-Based Engagement Design
Detection & Response Evaluation
Multi-Vector Adversary Simulation

This complements Cybersecurity Evidence & Threat Modeling for Connected Devices — the threat-modeling discipline that should inform what a penetration test actually targets, not replace it.

SOC 2 TYPE 1 & 2 ATTESTED OWASP ISO/IEC 27001

Ready to Build?

Discuss which test type fits a specific system and compliance framework.

Start a Conversation → Schedule Engineering Call

Engineering reference only. Testing is manual, human-led, with tooling in support — not an automated scan sold as a penetration test. Every engagement starts with signed, written authorization and agreed rules of engagement for each target in scope.