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 RED YELLOW GREEN. 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 and their scan templates 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 and templates 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. No outside interaction server is used, and the target is never asked to call one. For any target other than localhost, only the target URL and scan mode are sent to AlertaVuln for the ownership check; with --project the resulting findings are uploaded too - never your traffic or credentials.

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, a hosted scan runs the same scanners against your target from our infrastructure. It is available with the AV-hosted DAST module, is metered against a weekly quota, and you start it from the Scan it for me panel on the project’s Dynamic Scan page or with av dast server-scan. The local av dast scan costs nothing and is not metered, and needs no domain verification for localhost because it runs entirely in your own environment.

Because a hosted scan sends live traffic from our network to a URL you name, we first need proof that your organisation controls that domain. Verification is done once per domain, by an org admin or another member whose role can manage domains, under Settings -> Domains.

Prove you control the domain

1. Add the domain. Open Settings -> Domains (the Verified Domains panel), enter the domain or any URL on it, and click Add domain. AlertaVuln reduces what you typed to its registrable domain - app.example.com becomes example.com - and issues a unique verification token of 32 lower-case hex characters.

2. Publish the proof. The new row shows exactly what to publish, each with a copy button. Add the DNS record if you can; serve the file if you cannot edit DNS:

   • DNS TXT record (primary): host _alertavuln-verify.example.com, value av-verify=<token>.
   • HTTPS well-known file (fallback): https://example.com/.well-known/alertavuln-verify.txt, served over HTTPS with a success status and containing only the token (surrounding whitespace is ignored).

   The TXT record is the stronger proof: a shared host or a reflected file upload can forge a well-known file, so AlertaVuln only fetches the file when the DNS lookup did not already match. Leave the record or file in place for as long as you want the domain verified - it is re-checked, never consumed.

3. Click Verify. AlertaVuln resolves the TXT record first and falls back to the well-known file. The row turns Verified, and AlertaVuln records which method matched. A mismatch turns it Failed with the reason; fix the record and click Verify again. DNS changes take time to propagate, so each domain has a 30-second cool-down between checks; click Verify too soon and the button counts down until you can retry.

What a verified domain authorizes

• The domain and every host under it. Verifying example.com authorizes example.com, app.example.com, api.staging.example.com and so on. Add the registrable domain once; there is no per-host challenge.
• Both scanning paths. The same verified domain is what a hosted scan checks before any traffic leaves our network, and what av dast scan checks before it starts a local scan of any URL other than localhost.
• Hostnames only. A raw IP address cannot be verified - there is no DNS zone to prove - so neither path will scan one; point the scan at the hostname instead. The only exemption is localhost and other loopback addresses on the local CLI, which are your own machine.
• Public targets only. A hosted scan is refused if the host resolves to a private or internal address, even under a verified domain, and a target registered as internal is never hosted-eligible. Internal targets belong to the local CLI, run from inside your network.

Verification has no fixed expiry date, but it is re-checked: whenever a scan is authorized and the domain’s last check is older than 7 days, AlertaVuln checks again - the DNS record first, then the well-known file - before allowing the scan. If neither proof still matches, the domain flips to Failed, the scan is refused with that reason, and an admin must fix the record and click Verify again. Removing a domain from the panel revokes authorization for every host under it immediately.

Run a hosted scan

1. On the project’s Dynamic Scan page, open Scan it for me. It shows how many hosted scans your organisation has left this week.

2. Add a target by URL and pick its environment (Production or Staging). If its domain is not yet verified, AlertaVuln says so and offers to take anyone who can manage domains straight to Settings -> Domains. Targets you have already scanned with av dast scan --project are listed too.

3. Choose Passive (the default) or Active. Active scanning sends real attack payloads, so you tick the authorization checkbox for that target, and your organisation needs the hosted Attack Scanning module.

4. Optionally store a Bearer token for the target so the scan reaches pages behind authentication (the panel takes a Bearer token; av dast targets auth stores the other credential kinds), and a crawl seed so it reaches every page of a single-page app or API (see Help us find your pages).

5. Click Start scan. The job moves through Queued and Running to Succeeded with its RED / YELLOW / GREEN counts, or Failed with the reason. Findings land on the Dynamic Scan page like any upload, and the run appears in av dast jobs.

From a terminal, av dast server-scan does the same with the target ID (the id field of av dast targets --json); see Starting a hosted scan from the CLI below.

Every finding a hosted scan produces passes through the same credential redaction as a CLI upload, and the server redacts again before anything is stored - a reflected session cookie or bearer token never reaches your findings.

Hosted scans can also run on a schedule - daily, weekly or monthly. Set or change it with the pencil on the target’s row on the Dynamic Scan page. Scheduled scans are always passive, and each run counts toward the weekly hosted-scan allowance. Targets marked Internal (reachable only inside your network) cannot be scheduled - run av dast scan there on your own schedule instead. The target’s row shows when its schedule last ran, so a schedule that has stopped running (for example because the allowance is used up) is easy to spot.

Active hosted scans need an explicit attestation

A hosted active scan sends real attack payloads from our infrastructure, so starting one asks you, every time, to attest that you are authorized to attack the target. The attestation is recorded on the scan job - who attested and when - and the resulting run carries that record as its authorization. A request for an active hosted scan without the attestation is refused before anything is queued, and the hosted scanner refuses to run an active job that reaches it without one. Passive hosted scans need no attestation: they send no attack traffic.

Intensity

When you choose an active hosted scan you also choose an intensity: low (the default), medium or high. Intensity sets how hard the scanner pushes the target - requests per second, concurrency and the time budget - exactly as --intensity does for a CLI scan. Start at low and move up only for a target that can absorb the extra load. Passive scans have no intensity setting. The intensity a run used is shown on its job in the web app.

Starting a hosted scan from the CLI

av dast server-scan asks AlertaVuln to run a hosted scan of a target already registered on a project. It shows how much of your weekly allowance the scan will use and asks you to confirm; --yes skips the question but still shows the notice, and --wait blocks until the RED / YELLOW / GREEN counts come back.

For an active hosted scan, add --active together with --authorized, which is the attestation described above. --intensity low, medium or high sets the intensity; leave it out for low.

av dast server-scan --project <projectId> --target <targetId> --active --authorized --intensity medium --wait

The CLI refuses these on your machine, before anything is queued and without using any of your allowance:

• --active without --authorized: active hosted scans need an explicit authorization attestation: add --authorized to confirm you are authorized to actively test this target
• --intensity without --active: --intensity only applies to active scans (add --active)
• An intensity other than low, medium or high: intensity must be low, medium or high
• Any hosted scan while hosted scanning is paused: hosted scanning is temporarily paused - try again in a few minutes, or run 'av dast scan' locally

--authorized has no effect on a passive scan.

When hosted scanning is paused

We can pause hosted scanning across the service, for example during an incident or maintenance on the scanning fleet. While it is paused the Start scan button is disabled and says why, a request to start a scan is refused with HTTP 503 and a Retry-After header, and a job that was still queued when the pause began fails with the message “Hosted scanning was paused before this job started; please run it again later.” Nothing is lost: start the scan again once hosted scanning resumes. Your weekly allowance is never consumed by a refused or paused scan, and the local av dast scan is unaffected.

A queued job can also fail without a pause. If the platform could not start it within its window, it is marked failed with the reason “The scan did not start in time and was marked failed. Please try again.” Start it again; a job that never ran does not count against your weekly allowance either.

Scanners and crawl seeds

Hosted scans run the same pinned scanners and scan templates as av dast scan. The browser crawl (--ajax-spider) is a self-hosted option.

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 server-scanRun a hosted scan of a verified public target from AlertaVuln's infrastructure.

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

av dast targetsList the scan targets registered for a project.

av dast targets authGive a scan the credentials it needs to reach pages behind a login.

av dast jobsShow a project's scan-run history, local uploads and hosted runs alike.

See also

• av dast scan - run a dynamic scan
• av dast server-scan - run a hosted scan of a verified public target
• 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