Platform

Platform overview How it works Authorization testing Evidence & reports Private scanning Integrations

Solutions

Security agencies Product teams Regulated industries Partner programme

Learn

Blog Knowledge hub Compare

Resources

Pricing Documentation FAQ Security & data What we haven’t proved

Company

About Contact Careers Sign in to the platform Start a $199 pilot

Home / Evidence

Proof, not opinion

If we didn't break it, we don't report it.

Sorting through security findings is only a job because tools report things that might be true. Take away the maybe and most of the work disappears with it.

The case file

What arrives with every confirmed finding

A finding is not a title and a colour. It is an account of something that actually happened to your application, written out so the person who has to fix it does not have to reproduce it first to believe it.

The request
Exactly what we sent, and which role was signed in when we sent it.
The response
What came back, and what should have come back instead.
A screenshot
The result on screen in a real browser, for anything you can see.
The line of code
File and line, and the reason that code lets it through.
The re-run
After the fix, the same request sent again and what happened this time.
Critical IDOR · GET /api/users/:id/pii confirmed
# authenticated as role: support (privilege level 2)
GET /api/users/8814/pii HTTP/1.1
Cookie: session=<support>

 200 OK  (expected 403)
{ "email":"a****@northwind.co", "pan":"4111 **** **** 9012" }

source  api/src/routes/users.ts:214
 ownership check runs on req.body.orgId, not the session
screenshot  poc-8814-pii.png  (1 of 2)

✓ retest 09:41  same request, 403 · loop closed

Ships 19 October

Confirmed-only mode

One switch. The list then holds what we actually broke, and nothing else.

Four hundred maybes is not a result

A report that ends with hundreds of possible issues has not finished the job, it has handed the job to you. Somebody on your team now spends a week deciding which ones are real, and that week is the actual cost of the tool. Most of them turn out to be nothing, which is exactly why nobody reads the next report.

A list of what we broke is a result

A short list where every item arrives with the request that worked, the response it returned, a screenshot and the line responsible. Nothing to verify first, nothing to argue about in the stand-up, and short enough that your engineers will read all of it.

The things we suspected but could not break do not vanish. They are filed as suspicions, in their own list, for whoever wants to go looking. They are just kept out of the list you act on, because a finding without proof is a question, not a task.

4Pieces of proof per finding
19 OctConfirmed-only mode
16 NovCloses only when it fails

Reports

Something you can send to someone outside the team

Your name on it

Company name and logo taken from your settings, on every HTML and PDF report. Firms delivering this to their own clients send it under their own identity.

Secrets blanked out

Anything shaped like a key, a token or a password is masked everywhere in the report before it is rendered, including in the evidence we captured ourselves.

One for each audience

A summary for the person who signs it off, and the full case files for the person who has to fix it. The same run, written twice.

One app or all of them

A single run, or every application you own rolled into one view for the month.

What changed since last time

New, fixed and came-back, side by side in the console. Getting that delivered on a schedule as a changes-only report is on the list, not built.

The standard references

Findings carry the usual CWE and OWASP identifiers, so they line up with whatever framework your customers ask you about. Ready-made evidence packs for those questionnaires land 2 February.

Three questions, three answers

How bad, how sure, what now

Severity says how bad it would be. Confidence says how sure we are. Status says what you decided to do about it. Rolling those three into one number is how a list ends up with a hundred "high" items that nobody opens. So we keep them apart and let you sort on any of them. Six levels of severity, the ones your team already reads:

  • Critical
  • High
  • Medium
  • Low
  • Informational
  • Best practice

See what a real finding looks like.

The case file above is the shape every confirmed finding arrives in. We will open real ones against our own test applications and let you read the request, the response and the line that allowed it.

Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.