Skip to content

Between your scanner and your annual pentest

Cut the most paths with the fewest fixes.

Your scanners list findings. An intruder chains them into attack flow — routes that end at your crown jewels. SCARP maps that flow, finds where it converges, and names the fewest changes that cut the most of it — then re-checks until each route is verified closed.

Twenty minutes, bring a domain. We scope one assessment together: one path, the change that cuts it, and the re-check that proves it.

  • Read-only by default
  • Active checks only with your approval
  • OIDC SSO

Animated demo of a SCARP run against a typical first-run attack surface: SCARP maps four routes to prod-data. Three public entry routes — VPN portal, legacy webmail, and direct SSO — share one sign-in policy at workforce identity, and a password-only SSO edge grants a session to the admin console that can reach prod-data. The fourth route is a staging admin host with separate local credentials, outside that policy. SCARP proposes requiring MFA at workforce identity and waits on your approval. After your team deploys the change, the re-check confirms the three shared sign-in routes are closed and reports that staging still reaches prod-data — one route open, named and counted, queued for the next run.

First runTypical B2B SaaSillustrative data

One change set · illustrative, not customer data

What the report says after the change ships.

4 paths from 7 findings, one change, and the route it did not close. The projection and the re-check are both on the page — a remainder nobody names is how a prioritization claim escapes being checked.

Read the whole report →

CS-1042 · Admin takeover

Require MFA and trusted network access

Partially verified
Owner
Platform engineering
Effort
1–2 days
Disruption
Medium
Re-check
Direct-origin denial, gateway authentication, and alternate-host reachability
Why this changeCuts the three sign-in routes that share the workforce identity policy. The alternative on the table, retire the legacy administration endpoint, was projected to cut 2 for 1–2 sprints at high disruption.
Still reachable after the re-checkstaging-admin.example still reaches the customer administration plane: it authenticates against separate local credentials, outside the identity policy the change tightened.
Projected
4
paths the change was expected to close
Verified
3
confirmed closed by the re-check
Open
1
route still reaching the asset

01The change

Cut where the flow converges — fewest changes, most flow severed.

Instead of a ranked backlog, you get the shortest list worth making — each one named to the owner who has to make it, with the evidence attached and the routes it is expected to cut.

02The proof

A path is closed when the re-check says so.

After the change ships, SCARP re-runs the original route. Your report says how many paths are gone and which are still open — dated, counted numbers you can hand to an auditor or a customer’s security review.

03The map underneath

Ports, subdomains, leaked credentials — connected, not listed.

Discovery is how the first two are earned, not the product. SCARP connects what it observes into one map of the routes that reach your critical assets, and marks the dead ends as noise.

How it compares

Five tools, five different questions.

Scanners list, pentests sample, inventories count, path platforms model. SCARP asks which changes cut the most attack flow to what matters — then proves it.

  • SCARP

    Core question
    Which changes remove the most reachable paths?
    Unit of work
    The fewest changes that cut the most paths
    What ranks first
    Paths severed per change
    What closure means
    Each route re-checked and confirmed gone
    What it needs from you
    Verified domains. Nothing installed, nothing in your estate
  • Vulnerability scanner

    Core question
    Which findings exist?
    Unit of work
    A finding
    What ranks first
    Severity score
    What closure means
    Ticket marked resolved
    What it needs from you
    Credentials, scan windows, and someone to triage the queue
  • Annual pentest

    Core question
    What could be exploited that week?
    Unit of work
    An engagement
    What ranks first
    Consultant judgment
    What closure means
    Report delivered; retested at the next engagement
    What it needs from you
    A scoping window and staff time for the engagement
  • EASM inventory

    Core question
    What is exposed to the internet?
    Unit of work
    An asset
    What ranks first
    Exposure count
    What closure means
    Asset rescored on the next scan
    What it needs from you
    Domains, and a plan for the inventory it returns
  • Attack-path platform

    Core question
    Which paths exist across the estate?
    Unit of work
    A modelled path
    What ranks first
    Path criticality inside the model
    What closure means
    Re-modelled on the next data refresh
    What it needs from you
    Internal collectors or cloud read access, and a platform to live in

Evidence

Every finding carries its own case file.

A score is only worth as much as the observation underneath it. This is the record behind the one route that stayed open in CS-1042.

staging-admin.exampleobserved

Administration host with separate local credentials

Stage
exposure
Source
Passive external observation
Confidence
98%
Last observed
12 min ago
Change set
CS-1042
Re-check
Direct-origin denial, gateway authentication, and alternate-host reachability

Observed directly, not inferred — which is why it could be counted against the change instead of quietly dropped from the total.

What changes

  • Spreadsheet finding trackersFindings chained into paths, each with a named owner
  • Disconnected scanner consolesOne map of the routes that reach your data
  • Manual report assemblyDated, counted numbers produced by the run itself

Built to be checked

Take nothing on faith.

Most exposure reports ask you to take theirs. Every score here traces back to an observation you can inspect, every recommended change carries the evidence that produced it, and a path is only marked closed once a re-check confirms the route is gone.

Why the fix at the shared hop beats the worst finding →What a run actually touches →How SCARP checks its own work →

Questions

Before you ask.

Scope, safety, and what a run actually touches.

Does SCARP make changes to production systems?

No. SCARP recommends and verifies changes while your existing owners and work systems govern implementation. A ticket, deployment, or claimed fix never changes measured security state until a re-check observes the result.

Who is SCARP for?

Security leaders who already pay for a scanner and an annual penetration test, answer SOC 2 and customer security questionnaires, and depend on engineering, platform, or IT teams — teams that do not report to them — to change the controls around their critical assets.

Who is SCARP not for?

If what you need is a signed attestation letter for a specific framework, SCARP is not that deliverable. If nobody can get a control change shipped, a shorter list of changes will not help. And if what you want is a complete asset inventory, an EASM product is the better purchase.

What do you need from us to start?

Domains you have verified you own, and the assets that matter most — named by you, or inferred from what the run finds and confirmed with you. Nothing is installed, no agents or collectors run in your estate, and nothing is written to your systems.

How is this different from a vulnerability scanner?

Scanners tell you what they found. SCARP shows how an attacker can use those findings to move toward critical assets, then turns that view into a mitigation plan: the smallest set of changes that disconnects those routes, followed by a re-check.

Is active scanning safe to run against production?

Active scanning is operator-gated and off by default. Per-target throttling and scan-intensity controls keep authorized assessments inside approved boundaries, and requests are confined to your verified domains — never steered at internal addresses.

Where does the evidence come from?

Every finding keeps replayable scanner evidence, observation timestamps, and exploitability context, so reports stay tied to the observations that produced them.

How do we know which findings to trust?

Each finding shows the observations behind it — what was seen, when, and how — so you can weigh something SCARP watched directly against a connection it inferred. A report that distinguishes the two is one you can act on; a flat list of scores is not.

Can we bring your last pentest to the walkthrough?

Yes — bring the report and we will map its findings onto your path graph with you on the call, so the paths you already paid to have found are part of the first assessment. Automated third-party pentest import is on the roadmap; until it ships, that mapping is done with you rather than by the pipeline.

How is our data separated from other customers?

Each customer's data is isolated per tenant, enforced in the application and again by row-level security in the database. Access is governed by OIDC SSO and role-based permissions, and every report is scoped to the tenant that owns it.

See how attackers reach your crown jewels — before one does.

The first assessment is the land: verified domains in, a counted path report out. What keeps it useful is the re-check — every time a fix ships, and every time a route you closed comes back. SCARP runs with a small group of invited design partners, and we scope the first assessment together.