app-security-scan

NightVision App Security Scan

Run a real DAST scan against an app you just built or changed. API Discovery runs first when the backend language is supported, because it improves coverage and lets findings trace back to a source file and line (Code Traceback). DAST is the expected outcome on every run, not just a generated spec.

Requirements: this skill drives the NightVision MCP server's app-security-scan harness, so it needs a server build that provides run-app-security-scan, preflight-app, wait-for-scan, summarize-scan-findings, and export-sarif with the project_path argument. On an older server these tools are missing (the call returns an unknown-tool error) or export-sarif ignores project_path and silently drops source-linking. If any of the listed tools is unavailable, update the NightVision MCP server before using this skill; running preflight-app first is the cheapest way to confirm the harness is present.

Best-supported languages and frameworks

API Discovery uses deterministic static analysis to generate an OpenAPI spec for supported codebases. Source-linked results are strongest for the empirically verified languages and frameworks below:

• Python: Django, Django REST Framework, Flask, Flask-RESTful, FastAPI
• JavaScript/TypeScript: Express, NestJS, Fastify
• Java: Spring Boot, JAX-RS/Jersey, Micronaut, Java EE/Jakarta EE
• C#: ASP.NET Core controllers and minimal APIs
• Go: Gin, httprouter, and experimental net/http support
• Ruby: Rails and Grape

Treat frameworks outside this list, including PHP frameworks, as verify-first for source discovery. Still run DAST against reachable web apps and APIs as a WEB target when discovery is unsupported or produces no spec, but report that findings may not include source file:line traceback. Source-based discovery is REST/OpenAPI only.

Workflow

1. Locate the app's source directory and pass it as project_path. Do not rely on the current working directory: a developer usually launches you from their home directory, not the repo, and API Discovery reads project_path to generate the spec that links findings to source. If you are not already in the repo, find it (the app's git root / where its source lives) and pass that absolute path. Running against the home directory is refused with project_path_not_app_source.
2. Know the app's URL. You are running on the developer's machine with the app's source in front of you, so you know how it serves. If it is not already running, start it with its own command (npm run dev, docker compose up, the framework dev server). Pass that URL as target_url. Do not ask the harness to guess it.
3. Call run-app-security-scan with project_path, target_url, the NightVision project, and the app-auth mode (see Auth). One call does preflight, API Discovery, target create/update, DAST start, and writes .nightvision/manifest.json. Always route the scan through this one harness call, even when the user already has a NightVision target or credential set up: pass their existing project and auth/auth_id, and the harness reuses and updates that target and refreshes API Discovery so its spec is not stale. Do not hand-assemble a scan from create-target / start-scan / list-targets; that path skips the fresh discovery and is how a scan silently exercises a stale spec.
4. Report the discovery result before you poll, so the user can see API Discovery ran and what it produced. The single harness call runs API Discovery, updates the target, and starts DAST in that order, but all of it is invisible from the outside: the user sees one tool call and then a long scan, which reads as "it skipped discovery and went straight to DAST". Do not let a 10+ minute scan be the first thing the user hears about. Read these fields off the result and state them in one or two sentences before the first poll:
   • api_discovery.status (success, no_spec, skipped, or failed) and api_discovery.attached_spec_file (the spec that was pushed to the target).
   • The endpoint count in that spec. Count the entries under paths: in the spec file (for example grep -c '^ /' <attached_spec_file>) and say how many endpoints DAST will exercise.
   • target.action (created, updated, or reused) and the resolved target's type, nested at target.target.type (the target block wraps the action and the resolved target object). Any non-WEB type means the spec is attached and findings can carry source file:line (the backend echoes a spec-attached target as API or OPENAPI, so do not match on API alone); type WEB means it is scanning without a spec. Prefer api_discovery.status for the coverage judgment; treat the target type as confirmation only.
   • The scan_id.