nightvision-dast

Configures and runs NightVision white-box-assisted DAST: analyzes source code before attacking, traces every finding to its origin line, and drives coverage from OpenAPI / Postman / GraphQL specs rather than crawling. Supports Header, Cookie, TOTP, and recorded Interactive Login auth; exports findings as SARIF for GitHub Code Scanning, plus JSON, CSV, or PDF. Per-finding suppression via Alert Rules; CLI integration via the `nightvision` command. Use when source-traceable findings and spec-driven request coverage matter, not just authenticated black-box scanning (see zap-authenticated-scans for that).

Install with skills.sh (any agent)

npx skills add testland/qa --skill nightvision-dast

View source

nightvision-dast

Overview

Per docs.nightvision.net (opens in new window):

"NightVision is a white-box-assisted Dynamic Application Security Testing (DAST) tool" that "helps you identify security vulnerabilities in web applications and REST APIs."

It "analyzes code before simulating attacks and traces findings back to their origin" per nv-docs (opens in new window) - the source-traceability that sets it apart from black-box tools (ZAP / Burp).

When to use

The team needs source-traceable DAST (findings link to specific code locations, not just URLs).
API-heavy repo with OpenAPI / Swagger / GraphQL specs available as the scan target.
Team wants spec-driven coverage (NightVision derives request surface from API specs vs crawling).
Layered with zap-baseline for combined coverage.

How to use

Install the nightvision CLI and authenticate (nightvision login).
Pick the target: prefer an OpenAPI / Postman / GraphQL spec over a crawl URL so the scanner knows the full request surface (see Target types).
Create and run a scan against staging with the right auth mode, wait for it to finish, and pull findings (see Worked example).
Triage findings, suppress false positives via Alert Rules with a re-review date (see False-positive triage), then wire the scan into CI as a SARIF gate - full workflow and scope tuning in references/ci-and-scan-operations.md.

Install

Per nv-docs (opens in new window), "Installing the CLI":

# Linux/macOS
curl -fsSL https://install.nightvision.net | sh

# Verify
nightvision --version

# Authenticate
nightvision login

Target types

Per nv-docs (opens in new window) the platform supports:

Target type	How
OpenAPI / Swagger spec	Upload via CLI / dashboard
Postman collection	Upload via CLI / dashboard
GraphQL endpoint	Configure via API Discovery framework
Public web app URL	Standard URL target
Authenticated web app	+ auth recorder configuration (see Authentication)
Public REST API	Standard URL target
Authenticated REST API	+ Header / Cookie / TOTP auth

Authentication

Per nv-docs (opens in new window) the platform supports:

Auth type	Use
Interactive Logins	Record a browser-side login flow; replay during scan
Header authentication	Static token in HTTP header
Cookie authentication	Static cookie value
TOTP authentication	Time-based OTP for 2FA-protected apps

For interactive logins, the auth recorder captures the login flow in the dashboard UI; the recording is saved and referenced by name in subsequent scans.

Worked example

Scan an OpenAPI-described API on staging with a bearer token, wait for the run to finish, then export findings as JSON for triage and SARIF for GitHub Code Scanning:

# Create a spec-driven scan with header auth
SCAN_ID=$(nightvision scan create \
  --name "my-api-staging" \
  --target-url https://staging.example.com \
  --spec ./openapi.yaml \
  --auth header \
  --auth-header "Authorization: Bearer $TOKEN" \
  --output json | jq -r '.id')

# Block until the scan finishes
nightvision scan get "$SCAN_ID" --wait

# Export findings: json for cross-tool triage, sarif for Code Scanning
nightvision scan results "$SCAN_ID" --output json > findings.json
nightvision scan results "$SCAN_ID" --output sarif > nightvision.sarif

Verify: the run must reach a completed state before you export. If --wait returns a failed or timed-out run, the auth mode or scope is wrong - fix --auth-header (or the scope) and re-run the scan before triaging.

False-positive triage (MANDATORY)

Per nv-docs (opens in new window) "Alert Rules" govern per-finding suppression:

Mechanism	Use
Alert Rule (dashboard / API)	Suppress per (finding-type, URL-pattern) tuple
Scope exclusion	Skip whole URL trees
Severity threshold	Filter low-severity findings
Mark-as-FP per scan	Persistent across re-runs

Justification template (mandatory in Alert Rules):

Alert Rule: Suppress "SQL Injection" on /search?q=
Reason: parameter pre-validated via Joi schema; verified safe in code review
Reviewer: alice@example.com (2026-05-15)
Expires: 2026-12-15
Re-review-date: 2026-12-15

Cadence: every quarter, audit Alert Rules in the dashboard; expired rules removed; persistent ones reviewed.

Operating in CI

Run the scan against staging on push, export --output sarif, and upload it via github/codeql-action/upload-sarif so findings land inline on the PR. Pin a CLI version in CI, and tighten scope control first so scans stay focused and within budget. The full GitHub Actions workflow, the scope-control patterns, and the output-format matrix live in references/ci-and-scan-operations.md.

Anti-patterns

Anti-pattern	Why it fails	Fix
Crawl-based scan when OpenAPI spec exists	Misses unspidered endpoints	Always use `--spec` if available (see Worked example)
Scan production	Active probes risk data corruption	Staging only
Skip scope exclusion	Tests waste budget on out-of-scope URLs	Configure scope (see Operating in CI)
Suppress without `Re-review-date`	Permanent FP debt	Required template (see False-positive triage)
Hardcode auth tokens in CI logs	Token leak	Use CI secret + redact (`::add-mask::` in GHA)

Limitations

Commercial product - pricing model varies; check nightvision.net for current.
White-box-assistance requires source-code awareness - most useful for codebases NightVision can analyze (consult docs for language coverage).
For pure black-box DAST without commercial cost, use zap-baseline + burp-headless combination instead.
Per nv-docs (opens in new window) CLI / API / dashboard surface evolves; pin a CLI version in CI.
TOTP auth is supported but configuration is fragile when MFA policy changes.

References

nv-docs (opens in new window) - official documentation
nightvision.net - product page
zap-baseline, burp-headless - sister DAST tools
dast-scan-cadence-author - build-an-X for layered DAST
CI wiring, scope control, and output formats (with their own citations): references/ci-and-scan-operations.md

NightVision CI gating and scan operations

View source

NightVision CI gating and scan operations

Deep reference for the nightvision-dast SKILL.md. Consult when wiring a NightVision scan into CI as a SARIF gate, or when tuning scope control and output formats to keep scans focused and within budget.

CI integration - GitHub Actions

Run the scan against staging on push, export SARIF, and upload it to GitHub Code Scanning so findings surface inline on the pull request:

jobs:
  nightvision:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v5
      - run: |
          curl -fsSL https://install.nightvision.net | sh
          nightvision login --token ${{ secrets.NV_TOKEN }}
          SCAN_ID=$(nightvision scan create \
            --name "ci-${{ github.run_id }}" \
            --target-url https://staging.example.com \
            --spec ./openapi.yaml \
            --auth header \
            --auth-header "Authorization: Bearer ${{ secrets.STAGING_TOKEN }}" \
            --output json | jq -r '.id')
          nightvision scan get $SCAN_ID --wait
          nightvision scan results $SCAN_ID --output sarif > nightvision.sarif
      - uses: github/codeql-action/upload-sarif@v3
        if: always()
        with: { sarif_file: nightvision.sarif }

Exact CLI verb names per nv-docs (opens in new window) current release. Pin a CLI version in CI so a scanner update never silently changes results, and pass the auth token from a CI secret (never inline) so it stays out of logs.

Scope control

Per nv-docs (opens in new window) "Scope Control" defines:

Include patterns (URL globs in scope).
Exclude patterns (URL globs out of scope; e.g., /admin/* for admin-protected zones, /static/* for non-app assets).
Per-method exclude (e.g., skip DELETE on /users/*).
Per-finding-type include/exclude.

Tightening scope is essential - un-scoped scans hit unintended endpoints and waste scan budget. Configure it before the first CI run, not after a scan has already probed out-of-scope URLs.

Output formats

nightvision scan results <id> --output FORMAT:

json - for cross-tool finding aggregation.
sarif - for GitHub Code Scanning (the CI gate above).
csv - for spreadsheet review.
pdf - for compliance reports.

Related skills

burp-headless

Configures and runs headless Burp Suite Professional / Enterprise vulnerability scans (a "Burp scan"): Pro drives scans via its local REST API, Enterprise runs CI-driven scans at scale via its server API; supports BApp Store extensions (BCheck, custom scanners) and authenticated targets via session-handling rules; exports issues as HTML / XML / CSV / JSON or SARIF. Use when the team has a Burp Suite license and wants to run a vulnerability scan with Burp - paid-tier dynamic application security testing (DAST) layered on top of OWASP ZAP.

dast-scan-cadence-author

Designs an end-to-end DAST cadence for teams adopting dynamic scanning: ZAP passive baseline (PR-blocking) then ZAP full active scan (nightly on staging) then optional Burp Pro deep scan (per-release). Handles the baseline-finding ratchet for legacy apps so pre-existing findings do not immediately block PRs, plus per-tool per-run deduplication and CI workflow YAML. Use when the team is setting up DAST from scratch or restructuring scan cadence, not when tools are already running and you need to merge their output (cross-tool aggregation of existing independent runs is a separate concern).

nuclei-dast

Installs and runs ProjectDiscovery Nuclei template-based HTTP scanning: selects templates via `-t {path}` and `-tags`/`-severity` filters, controls request rate with `-rl`, emits JSONL output via `-j` for cross-tool finding aggregation, authors custom YAML matchers for app-specific checks, and gates CI on severity thresholds. Use when the team runs Nuclei alongside ZAP for template-driven DAST coverage, needs fuzzing-style probes beyond ZAP passive scan, or wants to operationalize community CVE templates in a pipeline.

zap-authenticated-scans

Configures authenticated DAST sessions in ZAP - ZAP Context + Authentication Method (form, JSON, script, browser-based, HTTP/NTLM), Session Management strategy (cookie, header, script), Verification Strategy (regex indicators, poll-URL), CSRF token handling, OAuth/bearer header injection, logged-in/logged-out indicator calibration, and context XML export for use with `-n` in baseline and full scans. Use when the team needs DAST coverage of authenticated routes - the most common DAST gap and the hardest DAST setup to get right.

zap-baseline

Configures and runs OWASP ZAP baseline scanning: `zap-baseline.py` Docker-packaged spider + passive scan suitable for CI gating; supports `-t target_url` + `-r html_report` + `-c config_file` rule customization (INFO/IGNORE/FAIL warnings) and Ajax spider via `-j` for JS-heavy SPAs. Passive-only; for active injection probes use `zap-full-scan.py` via zap-authenticated-scans. Accepts `-n context_file` for pre-configured auth contexts (see zap-authenticated-scans for setting up auth from scratch). Use when the user runs OWASP ZAP for pre-prod web app DAST.