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).
75
94%
Does it follow best practices?
Run evals on this skill
Adds up to 20 points to the overall score
View guide
Low
Low-risk findings worth noting
Per docs.nightvision.net:
"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 - the source-traceability that sets it apart from black-box tools (ZAP / Burp).
zap-baseline for combined coverage.nightvision CLI and authenticate (nightvision login).Per nv-docs, "Installing the CLI":
# Linux/macOS
curl -fsSL https://install.nightvision.net | sh
# Verify
nightvision --version
# Authenticate
nightvision loginPer nv-docs 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 |
Per nv-docs 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.
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.sarifVerify: 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.
Per nv-docs "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-15Cadence: every quarter, audit Alert Rules in the dashboard; expired rules removed; persistent ones reviewed.
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-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) |
zap-baseline + burp-headless
combination instead.zap-baseline,
burp-headless - sister DAST toolsdast-scan-cadence-author -
build-an-X for layered DAST