Evidence
Measured in public, before the first sale
Before selling a single scan, we ran the instrument over other people’s public code and published what it found — including the parts that make a cheap scanner look bad.
The sample run
We ran our calibrated scanner over two public codebases: 230 files, 28,900 lines, 16 findings. 1 was a real defect (now the fix-first item), 1 a watch item, and 14 were cleared — each with its reason printed. Nothing buried.
The one real defect: in the Spark web framework, the cookie-deletion path builds the cookie without the Secure flag that its own sibling method sets — a genuine, one-line defect in a framework other people build on. A cheap scan hands you 16 alarms and a panic. This service hands you 1 thing to fix, 1 thing to watch, and proof the other 14 were actually looked at.
The watch item — random-number ID generation inside a bundled example app — was reported as exactly that: harmless in a demo, dangerous if copied into production.
The instrument, measured
On the OWASP Benchmark, the same instrument scores J 0.4100 with precision 0.7169, and on a sealed JavaScript bug corpus it detected 78.7% of real bugs at a 0.8% false-positive rate. Those numbers are also why every finding is read in context — not just machine-flagged; the instrument is good, it is not perfect, and nothing reaches your report unread. The report says so on its face.
Honest limits, stated up front
- A scan is not a penetration test and not a certification. It does not make an app “secure” or “bug-free,” and no report from this service will ever claim that.
- Every report states its own scope and limits — what was checked, what was not, and what the instrument can and cannot see.
- Fees buy the work, never the verdict. PASS, FAIL, and UNKNOWN are all possible outcomes of a paid check.
The attack lab
Every certification campaign is judged across a fixed matrix of twenty labs. One of them exists to attack the work: hostile inputs, boundary abuse, cross-tenant probes, injection payloads, and planted defects the candidate’s own checks are supposed to catch. In the five verdicts published in the registry so far, the attack lab ran five times and read PASS five times — including in the one verdict that came back FAIL overall, where two other labs failed the candidate and this one still held.
Stated plainly, because the grade matters: the lab’s verdicts are signed inside the registry entries. The narrative attack report — one document per campaign, listing each attack and its evidence — exists as a format, and the first signed edition of it has not been issued yet. What is published here is the measured record: what was thrown, what held, and what was caught.
The proving ground — beta testing as evidence
Beta feedback usually arrives as opinions. The proving ground runs a declared cohort through declared journeys and keeps the evidence: every journey execution recorded, failures kept in the record permanently, and no result counts until every failure has a disposition — fixed and re-tested with the re-test evidence linked, or accepted as a risk under a named sign-off.
The proving ground is one of the suite’s five parts — the Court, the Attack Lab, the Proving Ground, the Seal, and the Watch. It is the form a beta test takes when the result has to be evidence rather than opinion: the cohort and the journeys are declared before the run, and the attestation is written only when every failure in it has been dispositioned.
The registry
Verdicts live in the registry
Every judged campaign ends in one verdict — PASS, FAIL, or UNKNOWN — with a signed receipt. Our own campaigns are published in the live registry, and the status of every seal is published there — a seal is valid for 12 months. A customer’s result is delivered to the customer only: it appears in the registry only when the public seal has been bought as part of the engagement, and a seal is issued only on a PASS. The registry, not this page, is the proof surface: check a verdict there, not here.
Start
Start with the intake
Tell us what you need checked. The quote comes back in writing, and a payment link is sent with your confirmed quote — you pay only after you have seen the final price in writing and accepted it.