Fleetfolio: Threat Exposure Management & Operational Acceptance Testing
Move beyond the annual penetration-test scramble to Operational Acceptance Testing (OAT): authorized, human-led testing whose findings land as structured records in a SQLite evidence database, with a retest that shows each remediation worked.
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. Fleetfolio 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.
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 Opsfolio CaaS as Plan of Action and Milestones items for SOC 2, HIPAA, ISO 27001, CMMC or FedRAMP work.
Product Architecture: The Dual-Engine System
Fleetfolio pairs an assessment engine that produces evidence with a Threat Exposure Management layer that moves each finding to closure. Both rest on 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. - Engine 2: Threat Exposure Management (TEM)
- surveilr 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.
- 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
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 "lite" profile
# Output: results/<ISO-timestamp>/<tool>/*.{json,jsonl,xml,txt}
# results/<ISO-timestamp>/*.sqlite.db
Public sample From the public Fleetfolio Pentest quick start (docs.opsfolio.com) and the fleetfolio/fleetfolio container image, with placeholder targets. The rate and concurrency values are a conservative choice for this sample, lower than the documented defaults.
Panel 2: Session evidence into the RSSD
surveilr 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 TABLE expected_asset (asset_tag TEXT PRIMARY KEY, hostname TEXT NOT NULL, boundary TEXT);
CREATE 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 Fleetfolio'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 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)
| Claim | Status | What it rests on |
|---|---|---|
| Containerized assessment writing timestamped findings to SQLite | Built and tested | The public fleetfolio/fleetfolio image and Pentest documentation. |
| Session output kept as JSON, JSONL, XML and text in timestamped folders | Built and tested | The public Pentest quick start (results/<timestamp>/<tool>/). |
| SQLPage dashboards for findings, triage and raw tool data | Built and tested | The fleetfolio.dev TEM page and its dashboard screenshots. |
| Expected-versus-discovered asset reconciliation | Built and tested | The fleetfolio.dev asset reconciliation page, shown on demo data. |
| Analyst verification and retest of remediated findings | Built and tested | Netspective's engagement practice, under the signed rules of engagement. |
| Automatic POA&M generation and retest triggers | Designed | Described in documentation; no public configuration yet. |
| Two-way ticket sync with Jira or ServiceNow | Designed | Listed on fleetfolio.dev; no published configuration. Scoped per engagement. |
| Continuous multi-cloud cost drift reconciliation | Designed | A fleetfolio.dev dashboard shown on a single demo scan; not offered as a continuous service. |
| Endpoint detection and response (EDR) agent | Not established | Not offered. Fleetfolio 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
Posture and exposure checks written as SQL and mapped to Trust Services Criteria, such as disk encryption against CC6.1, so each run is a dated evidence record instead of a screenshot.
FedRAMP
Continuous-monitoring evidence for NIST SP 800-53 control families, with verified findings carried into the Plan of Action and Milestones.
CMMC
For defense contractors: records of active monitoring and tested remediation that an assessor can query against the practices in scope.
ISO 27001
Annex A controls expressed as queries, so monitoring evidence accumulates between audits rather than being assembled for them.
Request an Exposure Assessment
The 2-week external exposure and attack surface assessment
Week 1: scope and test
Signed rules of engagement, authorized reconnaissance, vulnerability identification and analyst triage.
Week 2: evidence and retest
SQLite evidence delivery, remediation alignment with your team, and a retest of 100% of findings remediated within the agreed retest window.
Boundaries
- No testing starts without signed, written authorization covering every target.
- We minimize disruption through scoping and rate limits, but no active test can guarantee zero impact; fragile systems are excluded or tested in an agreed window.
- Fleetfolio is not a blocking endpoint detection and response (EDR) agent, and we do not provide legal counsel or certify compliance.
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 and signed 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.
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.
Ready to Build?
Discuss which test type fits a specific system and compliance framework.
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.