Dynamic application security testing
Proof, not a list of maybes.
SekuScan drives a real browser against your application and reports a weakness only when it holds the evidence that one exists. Every finding arrives with the requests that produced it and the responses that settled it. Nothing is graded on a hunch.
injection/sqli · replay minimised to 3 requests
Why you can trust the output
Three claims, each one checkable without taking our word.
A security scanner asks for credentials, network position and a view of every request your application serves. That deserves more than a datasheet.
Findings carry their evidence
A weakness is reported when the engine can demonstrate it, with the request pair that proved it and the controls it ran alongside. What it could not prove, it does not report — and says so.
no severity guessed from a bannerYou can read the half that sees your traffic
The sensor runs inside your network and observes everything. Its source is available to you — including the two files that decide whether it stays in scope and whether it redacts your secrets.
agent/scope.py · agent/redaction.pyYou prove the target is yours
Every host is verified before it can be scanned, by a DNS record or a file you place at its root, and the authorisation is recorded. A scanner that will point anywhere is a liability you inherit.
_sekuscan-verify.<host> · /.well-known/The report
What lands on your desk.
Every row carries the count of requests that settled it. The quiet rows matter as much: a scanner that reports everything it touched is one you stop reading by the second page.
/catalogue/search?q=
3 requests prove it
/api/v2/orders/{id}
2 identities compared
profile.display_name
marker echoed back
/webhooks/test
callback received
Where it goes
Into what you already use.
Results diff against a baseline, so a pipeline fails on what is new rather than on what you already accepted.
How it runs
Two halves, and a hard boundary between them.
The sensor
Opens a real Chromium against your application, performs one instruction at a time, and describes what happened. It holds no checks and no planner: it cannot decide what to test — only refuse what is out of scope and report what it saw.
The engine
Owns the crawl, the checks, the scoring and the verdicts. It reads what the sensor reports, decides the next instruction, and produces the report with the evidence attached to every finding.
The sensor connects outbound and asks what to do next. Your firewall changes by one outbound allowance — or by nothing at all. Nothing is ever opened inbound, and the engine never reaches into your network.
Results
Graded by other people, and published in full.
Every corpus we run is published with the date, the engine commit it was measured against and what it cost in requests — including the ones where we score worst. A recall number without its false-positive number beside it is not a measurement.
| Corpus | What it grades | Result |
|---|---|---|
| WAVSEP (ZAP team’s fork) | Every true-positive case, across 1 265 cases | 1 210 / 1 210 |
| WAVSEP false-positive traps | Look-alikes it must refuse to report | 38 / 44 |
| Crawl Maze (Google) | Reaching content buried in JavaScript, headers, CSS | 85 / 85 |
How it differs
Including the row where we lose.
Every vendor comparison table is green all the way down its own column. That is how you know none of them are worth reading. Here is ours.
| Common practice | SekuScan | |
|---|---|---|
| Why a finding is a finding | Signature or version match, severity inferred | Demonstrated, with the requests that proved it attached |
| What sees your traffic | A closed binary or agent | Source-available sensor, scope and redaction readable |
| Benchmark numbers | Rarely published, never the weak ones | Every corpus published, worst results included |
| Scanning something you don’t own | Often just a checkbox you tick | Per-host proof by DNS or file, and it is recorded |
| Network exposure | Outbound agent — the sane approach, widely used | Same. We did not invent this and do not claim to |
| Hosted multi-tenant SaaS | Standard, sign up with a credit card | Not offered. The engine is deployed for you, which is slower to start and not what everyone wants |
Questions we actually get
The awkward ones first.
Will it knock over my production site?
There is a per-host request ceiling you set, a run-level breaker that halts a scan behaving badly, and a hard cap we enforce regardless. Checks are a handful of requests with a strict verdict, not a payload cannon: a parameter gets roughly four to nine probes, ever.
Can it test what’s behind a login?
Yes, and it re-authenticates when a session drops mid-scan. It also compares two identities against the same endpoint, which is how authorisation flaws surface at all.
What do you do with what you find?
Findings are a list of working attacks against your application, so they stay behind your account and are never a public link. Obvious secrets are redacted by the sensor before anything leaves your network — in code you can read.
What does it miss?
Plenty, and it is written down. The weakest published corpus result is 102 of 154 on OWASP VulnerableApp, mostly behind scripted navigation the crawler does not yet reach. That page is one click away and not hidden behind a form.
Is this an AI product?
No. The verdicts come from oracles — a differential that holds, a timing gap against a baseline, a marker echoed back — not from a model being asked whether something looks vulnerable.
Why should I trust a small vendor?
You should not, on the strength of a website. Read the sensor source, check the benchmark numbers against corpora we did not write, and start with one application.
Getting started
Three steps to the first scan.
No sales call before a technical conversation, and nothing runs against a host until you have proved it is yours.
Prove the host is yours
Publish a DNS record or drop a file at the site root. We check it, record who authorised what and when, and only then will the engine accept the target.
_sekuscan-verify.example.com TXT
Run the sensor where the app is reachable
One process, on a host inside your network. It dials out over HTTPS and waits for instructions. Nothing is opened inbound, and you can read its source before you run it.
sekuscan-agent run --brain api.sekuscan.com
Read what it could prove
A report in HTML, JSON or SARIF, with the evidence attached to every finding and the checks that stayed quiet listed beside them. Wire it into CI and it fails on what is new.
report.html · report.json · report.sarif
Pricing
Priced per application, not per seat.
Scanning is licensed against the hosts you have verified. Everyone on your team can read the results.
Standard
Per verified application
- Scheduled and on-demand scans
- Reports in HTML, JSON and SARIF
- CI integration, results diffed against a baseline
- Unlimited readers
Enterprise
Let’s talk
- Multiple sensors across segmented networks
- Internal applications that never touch the public internet
- Security review of the sensor source with your own engineers
- Named contact and agreed response times
Research
The measurements behind the opinions.
SekuriPy publishes what it finds, in full and with the conditions it was measured under. Twenty-nine notes so far, and eleven CVEs credited.
Get started
Tell us what you want scanned.
We will ask which application, who owns it, and how you would like to prove that. If SekuScan is the wrong tool for what you are protecting, we would rather say so at the start than sell you a subscription.