Web application & API vulnerability scanner
Find vulnerabilities you can reproduce.
SekuScan crawls web applications and APIs in Chromium, actively tests the inputs it reaches, and reports a vulnerability only when the check can confirm it. Every confirmed finding carries the requests and controls that proved it.
Built by SekuriPy — Miroslav Stampar, author and maintainer of sqlmap and Maltrail.
injection/sqli · replay minimised to 3 requests
Verification
Three things you can check yourself.
Evidence with each finding
A vulnerability is reported only after that check’s confirmation condition is met: a response differential, a timing gap against a measured baseline, an out-of-band callback or a reflected marker. The report carries the request pair and the controls that ran alongside it.
no severity guessed from a bannerSource-available agent
The agent runs in your network and sees your traffic. Its source is available to read and audit, including the two files that decide whether it stays in scope and what it redacts before anything leaves.
agent/scope.py · agent/redaction.pyTarget verification
Every host is verified before it can be scanned, by a DNS record or a file you place at its root. The authorisation is recorded against the account that gave it, with the date.
_sekuscan-verify.<host> · /.well-known/Coverage
78 checks in 12 families.
Counted from the engine’s check registry. Most checks use four to nine requests per candidate input.
31 of the 78 are injection alone. Chromium is used for crawling, JavaScript execution and stateful navigation; the active checks then run against the surfaces that crawl discovered. What each module decides, and the evidence it requires before reporting, is in the documentation.
The report
Scan report.
Unauthenticated scan of sekumart.sekuripy.hr, a deliberately vulnerable shop we run in the open. 118 input surfaces, 912 active probes, 16 confirmed vulnerable locations across 10 vulnerability families. Every row carries the number of requests that settled it.
Generated by the engine, not a mock. The target is public, so the run can be reproduced against it. Severity is per location and the remediation is on the row; results that did not meet a confirmation condition are listed in their own sections below.
Result breakdown
Every check result from that same scan, one square each. 912 active probes produced 16 confirmed vulnerable locations; the rest either did not meet a confirmation condition or returned nothing to report.
Output
Exports and integrations.
Results diff against a baseline, so a pipeline fails on what is new rather than on what you already accepted.
Architecture
Agent in your network. Engine on ours. Outbound only.
The agent
- Runs Chromium against the target application
- Enforces verified target scope locally
- Redacts configured sensitive data before transmission
- Executes instructions from the engine
The engine
- Plans crawling and active checks
- Evaluates returned results
- Confirms findings and generates the report
- Does not initiate connections into your network
Benchmarks
Public benchmark results.
Results from WAVSEP, Google Security Crawl Maze and OWASP VulnerableApp. Each run records the corpus revision, the engine revision, the date and the request count, and the raw result data is published with it.
The 44 WAVSEP negative cases break down as 38 correctly silent, 4 not tested because they are outside supported scope, 1 whose answer key we dispute, and 1 genuine false positive. OWASP VulnerableApp is our weakest published result: most of the 52 missed cases sit behind scripted navigation the crawler does not yet reach.
Design choices
Trade-offs.
Each choice below has a cost, listed in the same row.
| Choice | Why | What it costs you |
|---|---|---|
| A finding needs an oracle | A differential that holds, a timing gap against a baseline, a marker echoed back | Real weaknesses we cannot demonstrate arrive as observations, not findings — so our headline count is lower than a scanner that reports everything |
| The agent is source-available | The component inside your network can be read before you run it | The engine is not. You are trusting a boundary, not the whole system |
| Every host is verified | DNS record or a file at the root, recorded with who authorised it | You cannot point it somewhere and see what happens; setup takes a step longer |
| Benchmarks published whole | Corpus, commit, request cost and exclusions, including where we score worst | Our weakest number is public and competitors can quote it |
| No hosted multi-tenant SaaS | The engine is deployed for you, so your findings are not in a shared system | Slower to start. No credit card and a running scan in ten minutes |
FAQ
Details worth checking.
Production safety
Each target has a request ceiling you set, each scan has a circuit breaker that halts a run behaving badly, and SekuScan enforces an additional hard cap regardless. Most active checks use four to nine requests per candidate input.
Authenticated scanning
Yes. The agent maintains and renews authenticated sessions during a scan. Authorisation checks compare the same endpoint using two different identities, with an unauthenticated control.
Where findings are stored
Findings are confirmed security issues with the evidence the check produced, so they stay behind your account and are never a public link. The agent redacts credentials, session tokens, authorization headers and configured patterns before anything leaves your network, in source you can read.
Known limits
The weakest published corpus result is 102 of 154 on OWASP VulnerableApp. Most of the misses sit behind scripted navigation the crawler does not yet reach. The full per-corpus results are on the benchmarks page.
Deterministic verdicts
No. Vulnerability verdicts are deterministic. Checks use explicit confirmation conditions: response differentials, timing against a measured baseline, out-of-band callbacks or reflected markers.
Evaluating a small vendor
Read the agent source, check the benchmark figures against corpora we did not write, and start with one application on the free evaluation.
Getting started
Run your first scan.
Nothing runs against a host until it has been verified.
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 agent where the app is reachable
One process, on a host inside your network. It connects outbound over HTTPS and waits for instructions, so no inbound access is required. Its source is available to read before you run it.
sekuscan-agent run --engine api.sekuscan.com
Review the report
HTML, JSON or SARIF, with the evidence attached to every confirmed finding and the checks that returned nothing listed by name. In CI it fails on what is new against a baseline.
report.html · report.json · report.sarif
Licensing
Licensed per application.
One price per application, per year, with unlimited readers on your
team. An application is one product and the hostnames that serve
it — www, api and auth
subdomains fronting the same product are one licence. A separate
product is a separate application.
One full scan with the complete report. No card, and no call before it.
Everything listed below is included.
For a team with a handful of services behind one roof.
Above fifteen applications, or air-gapped deployment, is quoted individually.
Billed annually. The monthly figures are the annual price divided by twelve, shown for comparison. There is no monthly plan.
Support is email, answered by the product team, usually within one to two business days. There is no contractual SLA.
Evaluation
Start an evaluation.
Tell us which application you want scanned and who owns it. The first scan is free and covers one application, with the complete report.
A finding is evidence,
or it is not a finding.
SekuScan · built by SekuriPy