CLI & CI/CD

Vooki Pro ships a command-line runner so a scan can happen without a person driving the interface — in a nightly job, in a pipeline, or on a machine with no display.

How It Works

One idea, and it keeps the whole thing simple: the config file is the single source of truth. Everything — target, scope, discovery, authentication, policy, throttling, report format — is a key in a JSON file. There are no dozens of flags to remember, and the same config always produces the same scan.

Getting a Config File

Export it from the interface. This is by far the easier route, because the correct method, URL, headers, cookies and body are filled in for you:

• Open Scans → New Scan for a website, or the API Builder for a single API request.
• Configure it exactly as you would for a normal scan — target, auth, discovery, policy.
• Step through to the final Review step.
• Click Export Config and choose where to save the .json file.

That file is ready to run. Edit it only when you want to change something.

Config Template

Writing one by hand is also fine. Only target and requests are required; every other key is optional and shown here with its default:

{
  "target": "https://example.com",
  "project_name": "My Project",

  "report_format": "html",
  "report_type": "standard",
  "compliance_framework": "owasp",

  "export_scan_data": false,
  "export_scan_data_path": "",

  "speed": "normal",
  "scan_types": ["all"],
  "concurrency": 5,
  "delay_ms": 0,
  "requests_per_second": 7,
  "max_payloads_per_type": 0,
  "skip_timing": false,
  "ai_detect": false,
  "attack_include": [],
  "attack_exclude": [],

  "scope": "same_host",
  "scope_hosts": [],

  "discovery": "quick",
  "crawl_depth": 2,
  "max_urls": 0,
  "crawl_max_duration_sec": 0,
  "discover_background_urls": false,
  "discovery_include": [],
  "discovery_exclude": [],
  "test_state_changing": false,

  "auth": {
    "headers": { "Authorization": "Bearer <token>" },
    "cookie": "session=your-session-token"
  },

  "requests": [
    {
      "url": "https://example.com/login",
      "method": "POST",
      "headers": { "Content-Type": "application/json" },
      "body": { "username": "admin", "password": "test" }
    },
    {
      "url": "https://example.com/search?q=test",
      "method": "GET"
    }
  ]
}

Key Settings

Report output — report_format takes html (default), json, docx or pdf. Set report_type to compliance and add compliance_framework — one of owasp, pci_dss, nist, iso27001, hipaa, gdpr or sox — for a framework-mapped report.

Speed — speed is a shortcut for three presets:

• stealth — 2 parallel requests, 2 second delay. Avoids WAF alerts.
• normal — 5 parallel requests, 500 ms delay. A good default.
• aggressive — 10 parallel requests, no delay. May trip WAF blocks.

Setting concurrency, delay_ms or requests_per_second directly overrides the preset; the larger effective delay wins.

Which checks run — "scan_types": ["all"] runs every class. To narrow it, list groups by name:

"scan_types": ["sqli", "xss", "lfi", "ssrf"]

Scope and discovery — scope takes all, same_host, same_domain or custom (with scope_hosts). discovery takes quick (only the listed requests), crawl, or hybrid, tuned with crawl_depth, max_urls, crawl_max_duration_sec, discover_background_urls and the discovery_include / discovery_exclude wildcards.

Saving the scan data — a report is a document; the scan data is the scan itself, every finding plus the HTTP request and response behind it. Set:

"export_scan_data": true,
"export_scan_data_path": ""

An empty path saves to your Downloads folder. Give a folder and the file is named after your config; give an exact .vpscan path and it is used verbatim. There is no command-line flag for this — the config decides, so the same config always produces the same files. The scan data is written even when a scan finds nothing, and the full path is printed when the scan ends.

Running a Scan

--config is the only required parameter:

pariksha-cli --config scan_config.json

Optional parameters:

• --output FILE — where to write the report. Defaults to the config file's name with the report format's extension.
• --verbose — print all scan progress messages, not just findings.

Findings print to the terminal as they are found, colour-coded by severity, and the report is saved when the scan finishes.

In a Pipeline

The runner is a plain executable that reads a file and writes a file, so it drops into Jenkins, GitHub Actions, GitLab CI or Azure Pipelines without special support. A typical arrangement:

• Keep the exported config in the repository, next to the code it tests.
• Inject credentials from your CI secret store rather than committing them in the auth block.
• Use a tight custom policy so the scan finishes inside your build timeout — a Deep policy does not belong in a pull-request check.
• Set "report_format": "json" if a later step needs to parse the results, and archive the report as a build artefact.
• Run the heavier policies on a nightly job instead, against staging.

Bringing Results Back

Set export_scan_data to true and the pipeline produces a .vpscan archive alongside the report. Pull that file onto a workstation and open it with Scans → Import: it appears like any scan you ran locally, with all findings and evidence intact, ready for triage and retest.