The native scan is Vigolium’s deterministic, Go-based scanning pipeline, fast, modular, and AI-free. This page is a hands-on tour of running native scans from the CLI, with a focus on stateless scanning.
Use stateless scanning for CI/CD pipelines, scripting, AI-agent integration, and quick ad-hoc checks. For the conceptual deep-dive see Scanning Modes Overview; for the full strategy reference see Strategies.
scan-url and scan-request never touch a database. scan --stateless creates a temporary SQLite database, runs every requested phase, exports results, and deletes the database on exit.
Pass -o/--output (with --format) when using --stateless, otherwise results are discarded along with the temporary database. Vigolium prints a warning if you forget. --stateless and --db are mutually exclusive.
# Only injection-class modules (fuzzy match on ID/name)vigolium scan-url -m sqli -m xss "https://example.com/search?q=test"# Filter by tagvigolium scan-url --module-tag injection https://example.com/api/data# Skip passive analysis and insertion-point fuzzing for the fastest resultvigolium scan-url --no-passive --no-insertion-points https://example.com/api/data
Run a discovery/spider phase before the scan (these promote scan-url to the full pipeline and require a database, pass --db):
# From a file containing a raw HTTP requestvigolium scan-request -i request.txt# From stdinprintf 'GET /api/users?id=1 HTTP/1.1\r\nHost: example.com\r\n\r\n' \ | vigolium scan-request# From a curl command (auto-detected)echo "curl -X POST -d 'user=admin' https://example.com/login" \ | vigolium scan-request
Override the host when the request file has only a path:
Add --split-by-host to instead scan each target in its own isolated temporary database and write a separate per-host output file (the filename is suffixed with the host so results don’t overwrite):
When you point Vigolium at a large target list, use -P/--parallel N to scan several hosts at once. Each target runs in its own isolated child process — so there is no cross-contamination between workers — and each child keeps its own --concurrency, meaning real in-flight requests are roughly N × --concurrency.-P requires one of two output strategies so results never collide:
--stateless --split-by-host — each target runs against its own temporary database and writes a separate per-host output file (base-<host>.<ext>). Nothing is persisted. Best for stateless, fire-and-forget batches.
--db-isolate — each worker scans into a private temporary SQLite database, then merges its results into the shared --db (or the default DB) at the end. This lets many parallel scans share one database without write contention, and you export one unified report from the merged DB afterward.
# Stateless fan-out: per-host JSONL + HTML files, 3 targets at a timevigolium scan -T list-of-targets.txt -P 3 \ --stateless --split-by-host \ --format jsonl,html --output prefix-output \ --fuzz-wordlist ~/Tools/contents/fast.txt# Shared-DB fan-out: 4 targets at a time merged into one local.db, one unified outputvigolium scan -T list-of-targets.txt -P 4 \ --db-isolate --db local.db \ --format jsonl,html --output report \ --fuzz-wordlist ~/Tools/contents/fast.txt
--db-isolate is SQLite-only and cannot be combined with --stateless (they are two different ways to avoid write contention). Pressing Ctrl-C during a -P batch is treated as an operator stop: un-started and cut-short targets are reported as “not scanned” rather than failures.
A stateless parallel fan-out (-S -T --split-by-host -P) writes a tiny line-cursor manifest, <output>.progress.json, tracking the targets that completed cleanly. If the batch is interrupted (Ctrl-C, a crash, a CI timeout), re-run it with --resume to skip the finished targets and scan only the remainder — Vigolium also prints a copy-pasteable resume command on Ctrl-C/failure:
# Original runvigolium scan -T targets.txt -P 4 --stateless --split-by-host --format jsonl -o results# Resume only the targets that didn't finishvigolium scan -T targets.txt -P 4 --stateless --split-by-host --format jsonl -o results --resume
Run vigolium scan --resume bare — with no other flags — and it auto-discovers the *.progress.json in the current directory and relaunches the saved run from it (pass -o <prefix> to disambiguate when several manifests exist).
--resume currently applies only to the parallel fan-out (-S -T --split-by-host -P > 1). Resuming a plain sequential scan re-runs it in full.
Standalone DB dump (VACUUM INTO); requires -S + -o. Aliases sqlite3, db
console,jsonl,html
All of the above
Comma-separate to combine
For stateless runs, -o is the base path, Vigolium appends the correct extension per format and materializes every requested format from the temporary database before tearing it down.
Oh dear, you actually read to the end. Here’s the secret the config file
kept nudging you toward: by default every Vigolium request announces itself
with a Vigolium/<version> User-Agent, so a friendly blue team can spot your
authorized scan in their logs in seconds. Go full ninja only when you mean
to be sneaky:
# Persist it in your configvigolium config set scanning_strategy.http.user_agent random# Or a one-off via env var (overrides the config value for that run)export VIGOLIUM_DEFAULT_UA=random