What is a self-hosted pentest platform?

Definition

A self-hosted pentest platform is penetration testing software that you deploy and run inside infrastructure you control, rather than sending your targets to a vendor-operated cloud. The scanning engine, the exploitation tooling, the findings database and the generated reports all live on your own servers. Nothing about the target, the credentials used to reach it, or the evidence captured during exploitation is transmitted to a third party. This matters because a penetration test produces exactly the kind of artifact an attacker would want: a catalogued list of the weaknesses in a system, often with working proof of how to abuse them. Self-hosting keeps that artifact inside the same trust boundary as the system it describes.

Why teams move off SaaS scanners

Most teams start with a hosted scanner because it takes ten minutes to set up. The friction usually appears later, and it tends to appear for one of four reasons.

Data residency and regulation

Finance, healthcare, defence and public-sector work frequently prohibit sending system details to an external processor, or require that any processor be contractually enumerated. A scanner that uploads your endpoints, headers and stack fingerprints is a processor, whether or not it is described that way.

Scope of what is being sent

Static analysis in particular means uploading source code. For many organisations that is a harder conversation than the security finding it produces.

Internal and non-routable targets

Staging environments, internal admin panels, management interfaces and multi-tenant hypervisor hosts are often unreachable from the public internet by design. A hosted scanner needs a tunnel or an agent to see them; a self-hosted engine is simply already inside.

Evidence handling

A platform that actually exploits findings captures shells, file reads and database output. That evidence is sensitive in its own right and is usually easier to govern when it never leaves the network.

Self-hosted vs SaaS: the practical differences

Neither model is universally correct. The trade-off is real and worth stating plainly.

Scanning is not the same as proving

The single largest source of wasted time in application security is the unvalidated finding. A scanner observes a signal — a version banner, a reflected parameter, an error message — and reports a probable vulnerability. Somebody then has to determine whether it is real. In a large estate this triage load can exceed the effort of the scan itself.

Exploitation closes that loop. Instead of reporting that a parameter looks injectable, the platform attempts the injection and records what came back. Instead of noting that a login form may be bypassable, it attempts the bypass. The output is no longer a probability, it is an artifact: a captured shell, a file that should not have been readable, a database row that should not have been reachable. A finding that carries reproducible evidence does not need triage, and it does not get argued about in a remediation meeting.

This is also what makes a report usable outside the security team. An executive summary that says "we obtained administrative access through this endpoint, here is the transcript" communicates risk in a way that a CVSS score does not.

The five layers of an attack surface

A finding rarely lives in one place. A hardcoded credential in source becomes an authentication bypass on the live application, which becomes a database pivot, which becomes host access. Tools that test a single layer see fragments of that chain. Covering all five, and correlating between them, is what turns fragments into an attack path.

Source code (SAST)

Injection sinks, weak cryptography, hardcoded secrets and unsafe patterns, traced statically before anything is deployed.

Live web (DAST)

SQL injection, XSS, SSRF, IDOR, XXE, authentication and JWT handling, request smuggling, cache poisoning, GraphQL exposure and current n-day CVEs, tested against the running application.

Dependencies (SCA)

Known CVEs in libraries, ideally mapped to exploitation-likelihood feeds such as CISA KEV and EPSS rather than raw CVSS, so that remediation is ordered by what is actually being exploited.

Server and infrastructure

Privilege escalation paths, multi-tenant isolation boundaries, and hardening of nginx, TLS, databases, mail and SSH.

Secrets

Keys, tokens and credentials leaked into repositories, build artifacts and container images.

What to look for when evaluating one

If you are comparing platforms, these are the questions that separate them in practice.

Does it prove, or only report?

Ask specifically how many modules perform exploitation rather than detection, and ask to see the evidence format.

How is exploitation constrained?

Automated exploitation without guardrails is a production incident waiting to happen. Look for a command gate that rejects destructive or out-of-scope actions by default, per-step timeouts, rate limiting and circuit breakers.

Is the tooling isolated?

Offensive tooling should run in a container or VM boundary, not directly on a host you care about.

Does it correlate across layers?

A platform that reports SAST and DAST findings in separate lists has not saved you the hardest part of the work.

What comes out at the end?

A human-readable report for the client and a machine-readable format such as SARIF or JSON for the pipeline. If it only produces a PDF, it cannot gate a build.

How is intelligence kept current?

Version detection is only useful when matched against live vulnerability feeds. Ask how often those are refreshed.

Operating one responsibly

Two constraints apply to every deployment, and neither is optional.

The first is authorization. Running an offensive platform against a system you do not own or have written permission to assess is a criminal offence in most jurisdictions, and the fact that a tool automates it changes nothing. Scope should be defined before a scan starts and enforced by the platform, not by the operator remembering.

The second is blast radius. Exploitation modules by definition change state: they write files, create sessions, and sometimes crash services. Production testing needs rate limiting, circuit breakers that halt on repeated failures, and a clear rollback story. A platform that cannot be throttled is a platform that can only be run against staging.