Your scanner ranks findings. Vappler ranks the paths between them.

A severity score tells you how bad a vulnerability is in theory. It doesn't tell you whether anyone can reach it, what sits behind it, or what an attacker gains by taking it. Vappler measures the routes through your network, ranks every asset by what an attacker reaches from it, and shows you the evidence behind each step.

Measured reachability, never assumed Findings verified on the host Multi-tenant from the first table

attack path · blast radius illustrative

0.0 blast radius, 0–10

0 edges behind it

Illustrative hosts. The edge types, the scoring inputs and the fallback behaviour are the real ones.

Severity tells you how bad it is, not what it reaches

Every scanner on the market is good at the same thing: producing a list. Sorted by CVSS, that list sends you after a critical on a host nobody can route to while a medium on the box adjacent to your finance database sits at position four thousand.

Reachability changes the answer, and so does exploitation in the wild, what an attacker gains at each hop, and how critical the asset on the other side is. Vappler holds all of it at once and asks a different question — not how severe is this, but where does this go.

Findings in one five-host scan280

Rated critical by CVSS32

Known to be exploited in the wild3

Real figures from a single scan of Vappler's own lab environment.

What Vappler does

Blast radius, from the entry point to the crown jewel

Vappler traverses the measured routes out of every vulnerable asset toward the ones you've marked as crown jewels, and scores each by what an attacker reaches from there — exploitability, distance along real edges, and the criticality of what's on the other side.

The arithmetic is published. Every input and every constant is stated in the report, so a client can reproduce the number rather than take it on faith. Where no measured route exists, the score falls back to asset-local exploitability and says exactly that, instead of inventing a path to justify itself.

Attack paths built from measured network edges

Routes come from traceroute hops and ARP resolutions — evidence that traffic actually moved — with routing-table entries carried separately as declared intent. Nothing on the map asserts a connection nobody observed.

Findings verified on the host, not guessed from a port

An agent reports real distribution and package versions, checked against a live security tracker that knows which fixes were backported. A port match alone never produces a confirmed verdict, and an unproven finding says so with its reason.

A remediation queue with owners and deadlines

Findings move through assignment, remediation and verification rather than sitting open forever. Accepted risk carries an approver and an expiry; a re-scan that no longer finds the vulnerable version proposes the close for a human to confirm.

One console, many tenants

Built from the first table for MSSPs and teams answering for more than one network — separate tenants, separate data, one deployment, with inventory and findings rolling up automatically once a workspace outgrows a readable view.

Compliance mapping from published sources

Findings map to CIS Controls, NIST 800-53 and PCI DSS through versioned, citable mappings. Where an authoritative mapping doesn't exist for a framework, that framework says so rather than offering a guess in a compliance table.

Disagreement surfaced instead of smoothed over

When the scanner's banner, the agent's process and the installed package don't agree, that contradiction is shown with both values, both sources and both timestamps. A listener the operating system can't account for is a finding, not a rounding error.

Three moves to your first attack path

Nothing to rack and nothing to route through a broker. Start with a scan, then add host-level truth where it earns its keep.

Scan the network

Point a scan at the targets in scope, bounded by a subnet policy you control. Discovery, service and version detection, and the routes between hosts all come out of the same pass — and every invocation's command line, timing and outcome is recorded next to the results.

Install agents where it matters

Agents run per host and supply what a scan can't see: real package versions, port-to-process attribution, and the host's own view of who it can reach. Hosts without one still appear, marked as network-only visibility rather than quietly treated the same.

cosign verify-blob --certificate vappler-agent.pem --signature vappler-agent.sig vappler-agent

Work the queue, not the list

Assets rank by blast radius, findings rank known-exploited first, and each one opens onto the evidence that produced it. Assign it, fix it, and let the next scan verify the close.

A security product should be able to show its own work

Vappler holds a map of how to move through your network. That deserves a straight answer about how it's built, so here is the state of the platform — no badges, no adjectives.

Tenant isolation: Enforced in the database, not in application code. Row-level security is enabled and forced, so a bug in an API handler can't hand one tenant another's rows.
Authentication: Multi-factor required at AAL2, checked at both the application layer and the database policy layer rather than trusted from the client.
Evidence: An append-only ledger beneath the product. Every fact is written once with its basis, and every screen and report resolves through it — so a number can be re-checked rather than believed.
Scoring: The blast-radius formula is published with its constants. A client who disagrees with a ranking can recompute it and argue with the inputs.
Confidence: Every rendered fact carries a tier — measured, enriched, derived or modeled — as a visible attribute next to the fact, not a disclaimer at the end of the document.
Secrets: Held in Docker secrets, never in environment files or the image. Service credentials are not readable from an application container's environment.
Agent trust: Agents are server-authoritative — an agent cannot nominate its own stream endpoint or scope. Release binaries are signed and verified before install, enrollment is revocable, and a retired agent re-enrolls cleanly.
Change control: Tests written before the fix, enforced CI gates on merge, and a live-surface gate suite that runs against real data rather than fixtures.

What we don't have yet: Vappler has no SOC 2 Type II report and no ISO 27001 certificate. Those audits haven't been done, so there are no badges on this page. When they exist you'll see the report, not a logo.

Parts of what's described here are landing across the current release cycle. Early access means watching them arrive with your own data underneath them.

Common questions

How is Vappler different from a vulnerability scanner?

A scanner produces findings. Vappler measures how those findings connect — which assets can reach which, and what an attacker gains by moving between them — then ranks remediation by blast radius rather than by severity alone. The scan is an input, not the product.

Does Vappler need an agent on every host?

No. A scan alone gives you discovery, services, versions and the routes between hosts. An agent adds what only the host knows: installed package versions, port-to-process attribution, and its own view of its neighbours. Assets without one are labelled network-only, so coverage is never implied where it doesn't exist.

How does the attack path analysis work?

Edges come from observed network evidence — traceroute hops and ARP resolutions — with routing-table entries recorded separately as declared rather than measured. Paths traverse that graph toward crown-jewel assets, and the ranking uses known-exploited status, severity, CVSS, EPSS and asset criticality rather than a model's opinion of which route sounds worst.

Can one team manage multiple clients?

Yes. Vappler is multi-tenant by design, with per-tenant isolation enforced in the database rather than in application code. MSSPs and internal teams running several networks work from one console and one deployment, with per-client workspaces, posture trends and report history.

What platforms do the agents run on?

Linux hosts today, installed as a systemd service with signed binaries you can verify before install. Package-level verification currently covers Debian-family distributions through a live security tracker, including backported fixes.

What does early access include?

A tenant of your own, the current platform, and a direct line to the people building it. Access opens in waves to a small number of teams so that feedback actually changes what ships next.