01
Attack path
SCARP shows how an attacker can move from a foothold through your environment to the assets that matter.
About SCARP
Built to be checked.
Most exposure reports ask you to take their word for it. SCARP is built the opposite way: every score traces back to an observation you can inspect, every recommended change comes with the evidence behind it, and a path is only marked closed once a re-check confirms it. SCARP runs with a small group of invited design partners.
What a run does
02
Decision
SCARP identifies the smallest set of changes that cuts that route, with the evidence that put each change there. It waits for your sign-off before anything touches your systems.
03
Prove
Once you've applied it, SCARP runs the identical check again. The path only moves to closed when that re-check confirms the route is gone.
Principles
Evidence over theater
Every product claim should point back to an observation, decision, or re-check result.
Changes over queues
A prioritized list only matters if it helps someone choose which fix to ship next.
Outcomes over activity
A change earns credit only when a re-check measures what actually disappeared.
Working with us
A design-partner engagement is a working relationship, not a report handed over the wall. Here is what that means in practice.
- Read-only onboarding
- Engagements start read-only: SCARP maps what's already exposed before anything more active runs, and only once you've agreed to it.
- Approval on every change
- Every proposed fix goes to you first. Nothing changes on your systems without your approval.
- Evidence and re-checks, inspectable
- The path, the evidence behind the fix, and the re-check result stay visible next to the score, not hidden behind it.
- One inbox, straight to the team
- Reviews, security questions, and onboarding requests all land with the people building SCARP, not a support layer.