> For the complete documentation index, see [llms.txt](https://docs.aquilax.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.aquilax.ai/user-manual/scanners/dynamic-scan-dast.md).

# Dynamic Scan - DAST

### 1. Overview of DAST in the Vulnix0 Context

AquilaX leverages [Vulnix0](https://vulnix0.com/) as the underlying scanning and attack simulation engine for Dynamic Application Security Testing (DAST). Within the Vulnix0 platform:

* DAST is categorized as one of several automated security modules, alongside Attack Surface Management (ASM), Automated Penetration Testing, and Threat Intelligence. 
* DAST scans live, running web applications and exposes runtime vulnerabilities and misconfigurations without requiring access to source code. 

From a technical standpoint, this means AquilaX’s DAST capability conducts black‑box testing — scanning external interfaces, injecting payloads, and observing runtime behaviors to detect exploitable flaws (e.g., XSS, SQLi, missing security headers). 

***

### 2. Engine Behavior and Scanning Workflow

The DAST scan logic implemented via Vulnix0 includes the following core phases:

#### 2.1 Discovery and Reconnaissance

* Scanning initiates with dynamic reconnaissance: enumerates subdomains and virtual hosts, enumerates endpoints, and maps live application structure. 
* The engine identifies accessible directories and files (e.g., /dashboard, /sitemap.xml), and collects metadata (security headers, server responses). 

This preliminary crawl builds an application model used in subsequent attack simulation.

***

#### 2.2 Runtime Attack Simulation

* DAST actively issues requests that simulate real‑world attack vectors against the running application.
* These probes test for protocol abuses, injection points, and business logic anomalies.

Examples of simulated conditions might include:

* Manipulating cookies and session tokens to test secure flag requirements.
* Suppressing or modifying security headers (e.g., CSP, X‑Frame‑Options) to see if responses indicate exposure. 

This behavior aligns with the general definition of DAST as external (black‑box) testing against a running target — with no visibility into application internals. 

***

### 3. Categories of Vulnerabilities Identified

The DAST capability surfaces vulnerabilities across multiple technical vector types:

#### 3.1 Misconfiguration Issues

The scanner checks security controls at the HTTP/TLS layer:

* Verification of header presence/values (e.g., missing HSTS, CSP).
* Detection of insecure cookies lacking HttpOnly/Secure. 

These checks combine positive validation (security headers correctly implemented) and negative validation (missing/weak controls).

***

#### 3.2 Sensitive Information Exposure

By crawling and probing accessible resources, the engine reports:

* Exposed files or directories that could leak infrastructure insights or policy data (e.g., public security.txt, sitemap data). 

This includes runtime enumeration of content that may not be known by development teams, effectively functioning as reconnaissance intelligence.

***

#### 3.3 Control Validation

Beyond vulnerability detection, the DAST engine executes tests to verify the effectiveness of existing security controls:

* Validates bot protection by analyzing response codes under automated traffic.
* Confirms proper operation of TLS and HSTS policies. 

This shows capabilities beyond pure flaw discovery — validating whether deployed mitigation mechanisms actually work under stress.

***

### 4. Data Output and Reports

Scans generate structured output that typically includes:

* Finding metadata — classification, severity, proof evidence.
* Raw scan data — captured request/response traces relevant to the finding (e.g., missing header JSON). 
* Remediation guidance — concise recommendations for developers or operations teams.

For example, a missing CSP header finding may include raw evidence demonstrating absence (empty value) and suggested policy enforcement. 

These outputs are consumed by AquilaX for:

* Internal dashboards.
* Integration into CI/CD pipelines (as technical feedback to DevOps).
* Automated ticketing/alerting flows.

***

### 5. Integration in the AppSec Toolchain

AquilaX’s use of DAST via Vulnix0 is positioned as a runtime validation tool in the broader security toolchain:

* Standalone Runtime Testing — DAST runs against deployed or staging environments where the application is live.
* Complement to Static Analysis (SAST) — DAST catches runtime and configuration issues that static code analysis cannot. 
* Part of CI/CD Gate Checks — scans can be automated as a final quality gate before deployment.

Integration is technical and can be automated via API key authentication (as documented in API docs), supporting scripting or orchestration with DevSecOps pipelines. 

***

### 6. Operational Considerations

From a security engineering perspective:

#### 6.1 Coverage and Environment

* DAST can run against production or staging environments, though staging is recommended to avoid unintended side effects from aggressive probes. 
* The scan must be configured with hostnames and credentials (for authenticated scanning) where necessary.

***

#### 6.2 Risk and Control

* Since the engine simulates malicious traffic, control over scan intensity and potential side effects (rate limiting, safe scanning modes) is necessary.
* Outputs require triage by security engineers to prioritize and plan remediation.

***

### 7. Summary — Key Technical Capabilities

AquilaX’s DAST via Vulnix0 provides:

* Automated black‑box runtime testing for web applications. 
* Attack surface enumeration at HTTP/TLS and resource levels. 
* Security control validation mechanisms. 
* Structured scan outputs suitable for DevSecOps automation. 

<br>

In essence, this integrated DAST service is designed to detect real, exploitable vulnerabilities and configuration flaws at runtime, supplementing source‑code analysis and other AppSec tooling.&#x20;