Offense Verification (NAPAD)

Not theoretical. Not a CVSS score. Controlled verification against your actual environment.

Standard severity scores cannot tell you whether a vulnerability is exploitable in your environment. A CVSS 9.8 on a service that is not reachable from any realistic attacker path is lower priority than a CVSS 6.0 on a service that is publicly exposed, exploitable without authentication, and directly connected to a sensitive data store. Standard scoring models cannot see this — they score the vulnerability in the abstract, not in the environment.

SPNT's offense module (NAPAD) closes the gap. It runs controlled exploit verification against the actual target, in the actual network topology, with the actual service configuration. The verdict — confirmed exploitable, confirmed not exploitable, or indeterminate — is written back into the substrate as a first-class data point that improves priority scoring, governance evidence, and reasoning quality for every other module.

How it works

Attack chain composition. NAPAD reads the substrate and composes candidate attack chains from related findings. A chain is not a generic exploit sequence — it is built from the specific findings on a specific asset, using the evidence that proves those findings exist. A web-application finding that exposes an authentication endpoint, combined with an infrastructure finding showing a sensitive service is reachable from that endpoint, composes into a chain that the verification engine can evaluate as a whole.

Controlled verification. The engine runs the chain as a bounded, scoped operation against the live target. Bounded by explicit caps (maximum steps, maximum cost, maximum duration, maximum recursion depth) that are enforced by the execution engine, not by an analyst or a model. Scoped to the specific findings — the verification does not deviate from the chain composed from substrate evidence. Auditable by design — every step is recorded with timing, parameters, and results.

Verdict written to the substrate.The result — confirmed exploitable, confirmed not exploitable, or indeterminate — is written back. A confirmed-exploitable verdict significantly raises the finding's priority. A confirmed-not-exploitable verdict lowers it. An indeterminate result (cap reached, network conditions blocked verification, etc.) is flagged for manual review and includes the partial steps taken.

Why bounded caps matter

Every security architect asks the same question about active verification: what stops this from causing unintended effects?

The caps are enforced by the platform, not by the model or the analyst. Every verification run that completes has an auditable record of what it attempted, what it found, and what its resource consumption was. Enterprise customers can configure cap profiles per asset class — tighter caps for production systems, more permissive caps for dedicated test environments.

NAPAD is not a general-purpose exploitation tool. It is not a replacement for a human penetration test. It is a bounded verification capability whose only job is to answer the question: is this specific finding actually exploitable in this specific environment, right now?

What changes when exploitability is known

Without verification, a team prioritising 500 findings is making a probabilistic guess based on severity scores and manual research.

With verification:

• Findings confirmed exploitable in your environment are immediately separated from theoretical risks.
• Governance evidence is stronger — auditors receive a verification record, not just a scanner output.
• The decision intelligence layer can distinguish "theoretically severe" from "verified exploitable here, today" in its prioritisation outputs.
• Remediation sequencing becomes environment-specific: fix the verified-exploitable findings first, in the order that reduces the most actual risk.

Tier availability

NAPAD is available on Enterprise and Sovereign tiers only.

Common questions