Skip to main content

Overview

Vigolium offers several ways to scan a target and get results in a single command without managing a persistent database. This is ideal for CI/CD pipelines, scripting, and quick ad-hoc checks.

Quick Scan with scan-url

The fastest way to scan a single URL. No database, no phases — just direct module execution:
JSON output for scripting:
With authentication and a POST body:
Run only specific modules:
Skip passive analysis for faster results:

Scanning Raw HTTP Requests with scan-request

Feed a raw HTTP request from a file or stdin:
Override the target host when the request file lacks a full URL:

Piping Input from stdin

Both scan-url and scan-request auto-detect the input format from stdin: Plain URL:
Curl command:
Raw HTTP request:

Full Pipeline with --stateless

For a complete multi-phase scan without a persistent database, use the --stateless flag on vigolium scan. This creates a temporary database, runs all phases, exports results, and cleans up:
This produces results.jsonl with all findings. Combine multiple output formats:
This produces both results.jsonl and results.html.

Output Formats

Console (default)

Human-readable colored output to the terminal:

JSONL

Machine-readable, one JSON object per line. Use -j or --format jsonl:

HTML

Interactive report with ag-grid table. Requires -o to specify the output path:

SARIF

A SARIF 2.1.0 log of the run’s findings, for GitHub code scanning, DefectDojo, and SARIF viewers. Requires -o:
Pairs naturally with a stateless CI run — nothing is persisted, and the artifact is the upload. See Output and Reporting for the finding→schema mapping.

SQLite

Dump the per-run database to a single standalone .sqlite file (via VACUUM INTO). Only available in stateless mode and requires -o. Aliases: sqlite3, db:
You can reopen the file later without a persistent project DB (see Reading Results Back).

Filesystem (fs)

Write a flat, browsable tree instead of a single file — handy for piping a scan straight to a coding agent that prefers ls/grep/jq over a database:
This produces run-traffic/ and run-findings/ with per-host raw .req/.resp.* files, cross-linked finding .md files, and a jq-friendly index.json in each. --split-by-host is a no-op (fs already splits by host), and --omit-response drops the response files. See Output and Reporting for the full layout.

Multiple Formats

Comma-separate formats to produce several outputs at once:

Reading Results Back

A stateless run leaves no project database behind, but you can still browse a .jsonl or .sqlite export after the fact. Point finding/traffic at the file with -S/--stateless + --db — project scoping is turned off and nothing is written to your project DB:

CI/CD Integration

Use --ci-output-format for clean, parseable output with no banners or color codes:
This forces JSONL output and suppresses all decorative output.

Scanning from Various Input Sources

From an OpenAPI Spec

From a Burp Suite Export

From a HAR File

From a Postman Collection

Tuning the Scan

Control concurrency and rate limits:
Use a scanning strategy preset:
Include the full HTTP response in findings for debugging:

Examples

Quick check on a single endpoint:
Full scan with JSON output in one shot:
Scan a curl command from clipboard:
Scan an API spec and export HTML report: