Deteryx maps your application from the outside, builds attack hypotheses out of the structure it actually found, and runs them under an impact ceiling you set. What reaches your report is what it confirmed on your own system — with the evidence attached.
1 Confirmed on your own system, under an impact ceiling you set — with the evidence attached.
A Deteryx run is a sequence with a gate in front of it and a witness behind it.
Gate
Nothing is requested until the domain is verified as yours and an admission decision has been made on the account. No proof, no run — there is no flag that skips this.
Crawl
The crawler reads your bundles, not only your links. Chunk graphs are walked, request paths are recomputed from the code that builds them, and routes nothing links to show up anyway.
Catalogue
Endpoints, parameters and request bodies are joined across modules and callback props into one structure. A later check needs somewhere exact to aim, so the catalogue keeps the shape of every request — and never the values.
Plan
Hypotheses are formed from the structure in front of it: this object reference, this tenant boundary, this upload. No CVE needs to exist first, and no signature list decides what gets looked at.
Consent
You approve the impact you are willing to absorb, not a list of methods. Inside that ceiling the run adapts freely; to cross it, it comes back and asks you again.
Witness
Only a compiled procedure is allowed to execute. It runs its steps, records what came back, and the severity on your report is rated on what the run actually witnessed — not on the worst thing the technique could have reached.
Not a folder of scripts. Every technique is a record that states where it applies, what it changes, what it observes, what confirms it and what refutes it. The planner reads those records; the executor compiles them. Adding one is a data change, and a runtime edit can only subtract or reorder — never grant a new capability.
134 techniques in total 63 attack classes
Most tools hand you a list of things that might be true. A hypothesis that never reached a verdict is not a finding, and we do not print it as one.
The structure allows it. Nothing was observed. The run could not obtain a second identity, so no verdict was reached.
Not printed as a finding
GET /api/v2/orders/:idas identity A200own record, len 903GET /api/v2/orders/:idid from a listing the scan saw200marker belonging to identity BThe attack itself stays in the system of record, unfiltered, for your engineers to replay. The confirmed slip is what a person reads.
Recon
Rebuilds routes, internal APIs, roles and service boundaries from client bundles, lazy-loaded chunks and live responses. A full picture of the application, with no source access.
Fingerprint
Frameworks, modules and their exact versions are fingerprinted from the outside and checked against known advisories, so stale dependencies surface before anyone else finds them.
Workflow
Sign-up, checkout, invitations, approvals. Deteryx reconstructs your real business flows and tests each step in sequence — where logic flaws live, and where scanners never look.
Arsenal
Public CVEs are only the start. A built-in arsenal of 134 techniques across 63 attack classes hits every mapped endpoint to find the weakly protected ones, including flaws no advisory names. Each comes with evidence and a fix, and is reported only once reproduced on your system — built for zero false positives.
Sandbox
On request
We provision a temporary environment, deploy your services into it, and run the comprehensive and destructive tests there. Production keeps serving your customers the whole time.
White-box
On request
Black-box is the default and needs no source. Share your codebase and Deteryx traces each finding to the file and line, and tests the paths no outside request can reach.
Report
Every confirmed finding comes with its root cause, the evidence, and detailed step-by-step remediation guidance — written to be implemented, then re-tested in the next run.
Mapping, fingerprinting, workflow testing, the full arsenal and fix-ready reports.
A dedicated sandbox environment for destructive testing, and white-box testing against your codebase.
Closed for now. No price list — tell us what you need in a request card.
Registration is currently closed. Fill in a request card and tell us what you want tested — we read every one and send invites in batches. Sandbox and white-box testing are arranged through the same card.