Dynamic scanning (DAST)

Where code scanning reads your source at rest, dynamic scanning exercises your application while it is running. AlertaVuln drives a series of scanners against a live web app or API, normalises everything they emit into one finding set, and tiers each finding REDYELLOWGREEN. Findings land on the project’s Dynamic Scan page when you upload them.

Passive by default, active on request

• Passive scans crawl the target and observe its responses. They send no attack payloads, so a passive scan is non-intrusive and safe to run anywhere, including production. This is the default.
• Active scans (--active) additionally run real attack-payload rules. They are opt-in, throttled by --intensity (low / medium / high), and gated for production targets.

Only scan what you are allowed to

A scan sends live requests - and, with --active, real attack payloads - to the target you name. Only scan systems you own or are explicitly authorized to test. Every av dast scan prints a legal authorization notice and requires you to attest authorization (via --i-am-authorized or the interactive prompt) before any engine runs. See av dast scan for the full gate.

Run from your own environment

av dast scan runs every engine from your machine or CI runner:

• Engines are downloaded on first use, pinned to an exact version, and verified against a hard-coded SHA-256 checksum before they are installed.
• Verified binaries are cached in your user config directory and reused on later scans.
• Each engine runs as a separate subprocess with a bounded timeout - nothing is linked into the CLI. An engine that can’t run in your environment is skipped with a notice, and the rest of the scan still runs.
• The scan’s traffic goes only to the target URL you name. Nothing about the target reaches AlertaVuln unless you opt in with --project, and then only the resulting findings - never your traffic or credentials - are uploaded.

The CLI reports each engine by a neutral capability label - web-scanner and template-scanner - rather than a product name.

RED / YELLOW / GREEN tiering

The engines emit raw signals; the CLI tiers them for local display, and on upload the server computes the authoritative tier from the same signals. A CVSS score wins when one is present; otherwise the scanner’s own severity signal decides:

Signal	Tier
CVSS score 7.0 and above	RED
CVSS score 4.0 - 6.9	YELLOW
CVSS score below 4.0	GREEN
Scanner severity high or critical, no CVSS	RED
Scanner severity medium, no CVSS	YELLOW
Scanner severity low or informational, no CVSS	GREEN

A low-severity finding reported at high confidence is raised to YELLOW. For CI gating, av dast scan --fail-on red (or yellow) makes the scan exit non-zero when the worst finding reaches that tier.

Scanning something behind a firewall

If a web application firewall or CDN sits in front of your target, some probes never reach your application at all - the firewall answers instead. Those responses tell you nothing about the application, so AlertaVuln does not treat them as findings.

A refused probe is reported as inconclusive, not as a pass and not as a vulnerability. The scan summary names the firewall it recognised and how many probes it refused:

Firewall: Cloudflare - 3 probe(s) refused and reported as INCONCLUSIVE, not as findings.
A firewall is a compensating control, not a fix; allowlist this scanner to test what is
behind it.

Recognition is deliberately cautious, because being wrong in either direction is expensive. A firewall fingerprint alone is not treated as a block - almost every site sits behind a CDN - and neither is a bare 403, because plenty of endpoints legitimately refuse a request. It takes both together, or an unmistakable block or challenge page. That way a genuine access-control finding is never quietly discarded.

Every check still runs. Nothing is skipped because a firewall blocked a related probe: firewalls block partially, so pruning a whole class of checks after one refusal risks missing a real vulnerability in exchange for a slightly faster scan.

A clean result from outside is not a clean application

If most probes were refused, the scan has measured your firewall, not your code. Allowlist the scanner and re-run to see what is actually exposed behind it - and fix the underlying issue regardless. A firewall rule can be changed, bypassed, or misconfigured; the vulnerability behind it does not go away.

Uploading to a project

Pass --project to upload the findings so they appear on the project’s Dynamic Scan page. The scanned target’s git ref is detected from the working tree’s git metadata and recorded as provenance. Uploaded findings carry their raw engine signals, and the server computes the authoritative tier from them. The first scan of a URL registers it as a target - see av dast targets.

Hosted scanning (Enterprise)

If you would rather AlertaVuln run the scan for you, hosted DAST scans your target from our infrastructure - an Enterprise feature. Because a hosted scan sends live traffic from our infrastructure to your target, we first require proof that you control the domain:

• DNS TXT record (primary) - add the verification record we issue to the domain’s DNS.
• HTTP well-known file (fallback) - serve the verification token at a well-known path over HTTP.

A verified organisation domain authorizes scanning of its subdomains. Raw IP addresses are not supported on the hosted path - run the self-hosted CLI for those. The local av dast scan stays free of any domain-verification step because it runs entirely in your own environment.

Because the hosted crawler follows links, single-page apps and APIs - which have few or no links to follow - need a starting map. Seed the scan with a URL list or an OpenAPI spec so it reaches every page and endpoint: see Help us find your pages.

Reference

av dast scanScan a running target, tier findings, and optionally upload to a project.

av dast findingsList the consolidated DAST findings the server holds for a project.

av dast targetsList the scan targets registered for a project.

See also

• av dast scan - run a dynamic scan
• Help us find your pages - seed a hosted scan of a SPA or API so it reaches every page
• Code scanning (SAST) - the static counterpart that reads your source at rest
• Red, yellow, green - how the three-tier verdict model works