Skip to main content
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.
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.

​
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. Runtime validation results use these verdicts: 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. 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.

​
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

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.
1

Open the repository

Go to the repository in ZeroPath and select the Runtime Validation tab.
2

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.
3

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.
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.

​
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: 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 collapsed Runtime Validation section below the exploit walkthrough. 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 is collapsed by default so the issue view remains readable for users who only need 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.

​
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.