01
Attack path
SCARP shows how an attacker could chain what is exposed on your internet-facing estate toward the systems 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 changes that cut those routes, with the evidence that put each change there. Your team decides what ships; SCARP never touches your systems.
03
Prove
Once your team has shipped the change, SCARP scans again. The path only moves to closed when that re-check finds its findings 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.
- Your team ships every change
- SCARP recommends and re-checks. Every fix is made by your own team, in your own systems.
- 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.