Skip to main content

levo-dast.yml

levo-dast.yml is a version-controlled file that captures everything non-secret about a DAST scan — target, crawl bounds, auth strategy, test categories, reporting — so you can commit it alongside the application it scans and re-run the exact same scan from the CLI, CI, or the dashboard.

Think of it as the difference between a long flag-heavy CLI invocation and shadownet scan.

Why YAML​

  • Reproducible scans. Same file, same scan, whoever runs it.
  • Code review for security config. Tune the scan in a PR, not a support ticket.
  • Less CLI noise. A couple of flags for secrets, the rest lives in the file.
  • One schema everywhere. The same YAML works unchanged in Docker, Kubernetes, and the dashboard.

Auto-discovery and precedence​

The CLI looks for the config file automatically:

  1. --config <path> flag if provided.
  2. ./levo-dast.yml in the current working directory.
  3. ./levo-dast.yaml fallback.
  4. Nothing — fall back to CLI flags and defaults only.

When a field is set in multiple places, the order is:

CLI flag > environment variable > YAML > built-in default

So a CI job can commit an opinionated YAML and still override max_pages or fail_on from the command line when needed.

Environment variable interpolation​

Every string value supports ${VAR} and ${VAR:-default}:

env: "${DEPLOY_ENV:-staging}"

auth:
  username: "${SCAN_USERNAME}"

Interpolation runs at load time, so the resolved values show up in the scan log for debugging.

Secrets policy​

Secrets never go in YAML

The loader rejects the file with an error if it sees any of the keys below. They must come from CLI flags or environment variables at runtime.

Rejected keys:

CategoryKeys
Levo identityorg_id, workspace_id, env_id, app_id, LEVOAI_AUTH_KEY, access/refresh tokens
Auth credentialspassword, token, raw cookie values, local_storage_b64
Third-partyANTHROPIC_API_KEY, OPENAI_API_KEY, CAPSOLVER_API_KEY, INTERACTSH_SERVER_AUTH_TOKEN

Use env vars (SCAN_PASSWORD, SCAN_TOKEN, ANTHROPIC_API_KEY, LEVOAI_AUTH_KEY, …) or CLI flags (--password, --token, --org-id, --env-id) instead.

A minimal file​

version: "1"
name: "acme-webapp"
env: "${DEPLOY_ENV:-staging}"

target:
  url: "https://app.example.com"

auth:
  strategy: "form"
  login_url: "https://app.example.com/login"
  username: "${SCAN_USERNAME}"

reporting:
  output: "sarif"
  output_file: "shadownet-report.sarif"
  fail_on: "high"

Run it:

shadownet scan --password "$SCAN_PASSWORD"

The scanner auto-discovers ./levo-dast.yml, merges env vars and CLI flags, and runs.

When to reach for YAML​

  • You're wiring DAST into CI.
  • You want to review scan-config changes in pull requests.
  • Multiple teammates run the same scan and you keep drifting.
  • You're about to paste a 200-character CLI command into Slack.

Still exploring? The dashboard and the CLI flags are always supported — YAML is additive, not a replacement.

Next​

Was this page helpful?