Skip to content

DAST connectors

DAST connectors ingest dynamic scan findings against deployed services.

SCM-first dependency

Connectors in this category depend on at least one SCM connector being installed first. Their findings reference silver.repositories.repository_id populated by SCM (resolved through silver.deployments). Walk the SCM category before installing a DAST connector.

Capability scope

DAST sources emit findings scoped to a target URL, application, or API endpoint rather than to a source file. The documented key is (target, alert_id, uri_path): target identifies the scanned deployment (host, base URL), alert_id is the scanner internal rule identifier, and uri_path disambiguates multiple hits of the same rule across paths of the same target. Severity vocabularies are shorter than SAST (typically four levels, for example Informational, Low, Medium, High), and the specification requires lookup tables for each tool mapping each source value to the documented four level severity.

Two deployment styles recur:

  • Server-based tools run as a long-lived daemon (for example, the ZAP daemon or the ZAP API) driven by the connector against target URLs drawn from the application inventory. The connector orchestrates scans per deployment and reads alerts back after scan completion.
  • CI/CD step tools run the scanner CLI inside a pipeline (for example, zap-baseline.py in a GitHub Actions step) against the freshly deployed application and emit JSON or SARIF output to an artifact store or object storage prefix collected by the connector.

The incremental strategy is based on scan reports: one ingestion per scan completion, with full reload within the scope of a scan. Unlike SAST, there is no server-side updated_at incremental column on individual findings. The scan ID (server-based) or artifact file (CI/CD step) is the high-water mark, and findings from prior scans remain queryable for audit.

Authentication differs by style. Server-based tools use an API key (for example, the ZAP API key supplied via X-ZAP-API-Key header, configured at daemon startup). CI/CD step output files have no native authentication. Access is governed by the IAM policy of the object storage bucket.

DAST findings reference a URL rather than a repository file, so application linkage requires resolving target against the deployment inventory (silver.deployments). Unmatched URLs are emitted for inventory gap analysis.

Documented mapping contribution

DAST sources populate the Silver finding table scoped by (application_id, target, alert_id). See Canonical mapping.

Skills

Four skills cover the connector lifecycle for DAST sources, with facts for the category at Skills. The procedural body of each skill is documented at Connector skills.

Connectors in this category