> ## Documentation Index
> Fetch the complete documentation index at: https://zeropath.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Dynamic Testing (DAST)

> Use dynamic testing to discover vulnerabilities in running applications, confirm exploitability at runtime, and verify fixes after merge

Dynamic Testing is ZeroPath's Dynamic Application Security Testing (DAST) capability for running applications. It can be deployed in three ways: discover vulnerabilities in live applications, confirm which static findings are exploitable at runtime, and verify that fixes resolve the issue after merge.

<Info>
  The dashboard uses **Runtime Validation** for the issue-specific DAST
  workflow: routes, tabs, run pages, and issue evidence sections still use that
  name. Runtime Validation is one mode of ZeroPath Dynamic Testing.
</Info>

## What It Does

Dynamic Testing exercises a configured running target with finding context, application profile inputs, encrypted runtime credentials, and, when needed, a compiled local application artifact. The goal is to produce evidence from the live application rather than relying only on static analysis.

| Mode | Use case |
| - | - |
| **Live discovery** | Run dynamic tests against production or staging APIs to find runtime-only vulnerabilities such as prompt injection and IDOR. |
| **Runtime validation** | Start from a completed SAST finding and confirm, disconfirm, or explain exploitability against the deployed application. |
| **Post-merge verification** | Reuse the dynamic profile after a patch lands to verify the vulnerable behavior no longer reproduces. |

Runtime validation results use these verdicts:

| Result | Meaning |
| - | - |
| **Queued** | The issue is part of the run but has not reached a final verdict yet. |
| **Confirmed** | ZeroPath observed runtime evidence that the issue is exploitable. |
| **Disconfirmed** | ZeroPath could not exploit the issue in the configured runtime environment. |
| **Unable** | Validation could not reach a trustworthy verdict, such as when required runtime state was unavailable or the application was unreachable. |

Disconfirmed findings can be moved into the false-positive workflow with runtime evidence explaining why the issue did not reproduce.

## Vulnerability Classes

Dynamic tests can target runtime behaviors that are difficult to prove from source alone:

* **Prompt injection** - tests whether AI-powered features execute injected instructions by manipulating inputs across user-facing and backend prompts. Findings show the injection path and model response.
* **IDOR** - exercises object identifiers across authenticated roles to prove when users can access resources they do not own.
* **Vulnerability chaining** - combines multiple runtime behaviors to show how smaller weaknesses become a practical attack path.
* **Out-of-band (OOB) vulnerabilities** - detects blind SSRF, blind XXE, blind SQL injection, DNS exfiltration, and other vulnerabilities where the exploited behavior is not visible in the HTTP response. The validation agent generates unique callback URLs on `oob.0path.ai` and monitors for outbound requests from the target application, proving that the injected payload triggered a real server-side request.

### Out-of-Band Testing and Network Requirements

OOB testing uses `oob.0path.ai` as the default callback server on ZeroPath Cloud. The validation agent injects unique URLs under this domain into the target application and monitors for DNS lookups, HTTP requests, and other protocol interactions that prove the vulnerability is exploitable.

If your target application runs behind a firewall or egress filter, you may need to whitelist `*.oob.0path.ai` (DNS and HTTPS) so the target can reach the callback server. Without this, OOB tests will return no interactions even if the vulnerability is real.

Self-hosted deployments do not use `oob.0path.ai`. They run a private callback collector inside the cluster on a dedicated DNS zone chosen by your platform team (for example `oob.security.internal`), and the applications under test must be able to resolve and reach that zone. See [Self-hosted deployments](#self-hosted-deployments) below.

A callback channel failure (DNS, TLS, or polling error) is always reported as an error, never as "no interactions". The agent runs a positive control against the collector before and after each test, so a **Disconfirmed** verdict for an OOB finding means the callback channel was healthy and the payload still produced no interaction.

## Prerequisites

Dynamic Testing requires:

* A deployed application reachable by the validation worker, or a compiled local application artifact uploaded in the Runtime Validation setup panel.
* A Runtime Validation application profile for the detected application.
* All required profile inputs saved, such as target URL and generated authentication fields.
* For issue-specific validation, a completed full scan with eligible SAST findings.

Generated input fields are represented as structured dashboard fields rather than a single JSON blob. Values are encrypted before they are stored, and readiness checks prevent validation from starting until required inputs are present.

Local artifact validation currently supports Linux x86\_64/amd64 compiled artifacts packaged as `.zip`, `.tar`, `.tar.gz`, or `.tgz`. The artifact runs inside ZeroPath's Debian-based Runtime Validation gVisor container; other operating systems and CPU architectures are not supported.

## Running Runtime Validation

<Tabs>
  <Tab title="Auto-provision All Applications">
    Use this option to validate every detected application in a repository at once, without configuring individual application profiles first. ZeroPath builds and runs each application directly from source in an isolated container.

    <Steps>
      <Step title="Open the repository">
        Go to the repository in ZeroPath and select the **Runtime validation** tab.
      </Step>

      <Step title="Auto-provision & Validate all applications">
        Click the **Auto-provision & Validate all applications** button in the toolbar at the top of the tab. This button appears when ZeroPath has detected applications in the repository and a completed full scan is available.
      </Step>

      <Step title="Monitor results">
        ZeroPath provisions a source-build profile for each detected application and queues a full validation run. Applications that are already running are skipped automatically. A confirmation message shows how many applications were provisioned and how many were skipped.
      </Step>
    </Steps>

    This is the fastest way to get runtime validation results without any upfront profile setup. You can also enable the **Auto-Provision Runtime Validation** toggle in scanner settings to trigger this automatically after every full scan.
  </Tab>

  <Tab title="Auto-provision Single Application">
    Use this option to build and run a specific application from source in an isolated container and immediately queue a full validation run — without configuring the profile first or waiting for it to reach a ready state.

    <Steps>
      <Step title="Open the repository">
        Go to the repository in ZeroPath and select the **Runtime validation** tab.
      </Step>

      <Step title="Select an application profile">
        Choose the application profile you want to validate from the profile list.
      </Step>

      <Step title="Auto-provision & Validate">
        Click the **Auto-provision & Validate** button in the profile panel. ZeroPath automatically switches the profile to a source-build configuration, builds the application from source in an isolated container, and queues a full validation run against the currently selected scan.
      </Step>

      <Step title="Monitor results">
        The run appears in the run list. You can track its progress from the run detail page.
      </Step>
    </Steps>

    This option is useful when you want to validate one specific application without configuring profile inputs manually. To validate all detected applications in a repository at once, use the **Auto-provision All Applications** option instead.
  </Tab>

  <Tab title="Full Application">
    Use a full-application run when you want to validate every eligible issue for an application profile.

    <Steps>
      <Step title="Open the repository">
        Go to the repository in ZeroPath and select the **Runtime validation** tab.
      </Step>

      <Step title="Select an application profile">
        Choose the application and scan you want to validate.
      </Step>

      <Step title="Confirm readiness">
        Fill any missing profile inputs until the profile is ready. For local applications, upload the compiled Linux x86\_64/amd64 artifact in the **Local artifact** section.
      </Step>

      <Step title="Start the run">
        Choose **Full application** and start validation. The run appears in the run list below the configuration panel.
      </Step>
    </Steps>
  </Tab>

  <Tab title="Selected Issue">
    Use a selected-issue run when you only need proof for one finding.

    <Steps>
      <Step title="Open an issue">
        Open the issue modal or full issue view from the repository **Issues** tab.
      </Step>

      <Step title="Check Runtime Validation">
        If the issue belongs to a configured application profile, the Runtime Validation control appears in the **Runtime validation** section of the issue's **Evidence** tab.
      </Step>

      <Step title="Start validation">
        Start validation for that issue. ZeroPath creates a selected-issue run and links back to the run detail page.
      </Step>
    </Steps>

    You can also start a selected-issue run from the repository **Runtime validation** tab by choosing **Selected issue** and picking an eligible finding.
  </Tab>
</Tabs>

## Reviewing Results

The repository **Runtime validation** tab shows recent validation runs. Selecting a run opens a dedicated run page with two top-level sections, selectable from the tab bar:

### Issues

The Issues section shows validation results grouped by verdict:

* **Queued** - issues still waiting for runtime validation.
* **Confirmed** - issues proven exploitable at runtime.
* **Disconfirmed** - issues that did not reproduce in the configured runtime environment.
* **Unable** - issues where validation could not produce a reliable verdict.

Clicking an issue from any result tab opens the standard ZeroPath issue view, so the static finding, exploit walkthrough, remediation guidance, and runtime evidence can be reviewed together.

### Exploit Chains

The Exploit Chains section shows multi-step attack paths discovered during the validation run — combinations of individual findings that, when chained together, form a practical exploit sequence. Use this view to understand how separately confirmed vulnerabilities can be combined by an attacker and to prioritize remediation of findings that contribute to high-impact chains.

The table lists each chain with the following columns:

| Column | Description |
| - | - |
| **Chain** | The chain title and a brief impact summary |
| **Severity** | The combined-impact severity across all steps in the chain |
| **Steps** | The number of individual vulnerabilities in the chain |
| **Setup** | Whether the chain can be executed with a **Default setup** or requires environment modifications (**Requires modification**) |

Clicking a row expands it to show the full chain detail:

* **Impact** — a narrative description of the real-world consequence if the chain is exploited.
* **Reasoning** — the analysis behind why these vulnerabilities form a viable chain.
* **Attack steps** — an ordered walkthrough of how an attacker would execute the full chain end to end.
* **Attack path** — each individual step in the chain, linked to its originating issue, with its vulnerability class, severity, setup requirement, the role it plays in enabling the next step, and any configuration requirements.
* **Proof of concept** — when available, a generated Python script that reproduces the exploit chain. You can copy the PoC to your clipboard using the copy button.

The active section is reflected in the page URL (`?section=exploit-chains`), so you can bookmark or share a direct link to either the Issues or Exploit Chains view for a specific run.

## Issue-Level Evidence

When a finding has Runtime Validation output, the issue modal and full issue view include a **Runtime validation** section on the **Evidence** tab. It summarizes:

* The latest verdict and run status.
* What ZeroPath attempted during runtime testing.
* Evidence observed during the attempt.
* Why the finding was confirmed, disconfirmed, or marked unable.
* A link to the dedicated run page for broader run context.

The section lives on the Evidence tab, so the Overview tab stays focused on the original finding details.

### Structured Validation Data in the API

The issue detail and runtime validation API responses include two structured fields that give you machine-readable insight into what the validation agent did:

* **`validationSteps`** — an ordered list of objects, one per action the agent performed. Each object contains:
  * `target` — the endpoint, workflow, object, or code path exercised (nullable).
  * `action` — the concrete action taken.
  * `expectedResult` — the expected safe behavior or exploit signal for this step (nullable).
  * `observedResult` — what the agent actually observed at runtime.
  * `conclusion` — why this observation matters for the verdict.
* **`attackReproductionSteps`** — for confirmed findings only, an ordered list of natural-language steps that reproduce the confirmed attack. Suitable for inclusion in a bug report or remediation ticket.

Both fields are returned as arrays and are always present (empty when not applicable). The previously available `agentGroupKey` field has been removed from the API response.

## Self-hosted deployments

Dynamic Testing is available on ZeroPath self-hosted starting with release `onprem-2026.09.07-beta` (any later release includes it). It is **off by default** and is enabled by your platform team through the Helm value `runtimeValidation.enabled: true`. Until it is enabled, the Runtime Validation panels still let you review application profiles, save inputs, and upload local artifacts, but launching a run returns *Runtime validation execution is disabled on this deployment*; the repository page shows the same message in a banner.

When enabled, everything runs inside your cluster:

* **Sandboxes** run as short-lived pods under a sandbox `RuntimeClass` (gVisor by default) on nodes your team designates. Each run gets its own pod, and SOURCE\_BUILD runs build and start the application inside that pod.
* **Callbacks** go to a private collector reachable at a DNS zone your team delegates (for example `oob.security.internal`) instead of `oob.0path.ai`. Applications under test must use resolvers that forward that zone to the collector and must be able to reach it on ports 53, 80, and 443.
* **Network access** from the sandbox is limited by NetworkPolicy to the private networks your team lists: the applications under test, the model proxy, internal package mirrors, and the collector. Public internet egress is not available from a sandbox, so REMOTE targets must be reachable on a private address and SOURCE\_BUILD dependencies must come from internal mirrors configured by your team.
* **Local artifacts** are staged on the shared scan volume and stored in your S3-compatible object store; they expire after 30 days.

Operational requirements, air-gapped package mirrors, and the acceptance checklist are documented in the self-hosted deployment guide (section *DAST / Runtime Validation in private and air-gapped networks*) delivered with each release.

## Operational Notes

* Full-application runs are blocked while another active run exists for the same scan and application profile.
* Selected-issue runs are blocked only when a full-application run is active or when another active selected-issue run already targets the same finding.
* Dynamic Testing depends on the configured deployed target, so a failure to reach the application should be treated as an environment or profile problem before treating the finding as disconfirmed.
* For repositories with many scans, use the run list and result tabs instead of scanning issue-by-issue from the main issues table.

## Related Pages

* [SAST Overview](/docs/scanning/sast-overview)
* [Scanner Settings](/docs/platform/scanner-settings)
* [Auto-Fix & Patches](/docs/scanning/auto-fix)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.