Proven
The payload, request and response that triggered the finding are stored with it, so the developer sees exactly what the scanner saw.
DAST
Test the application.
Keep the evidence.
Run dynamic application security testing (DAST) against authorised targets. Use explicit scope and recorded evidence to investigate runtime behaviour.
Authorised test target
Target URL
Test request
Observed response
Investigation context
01 / Scope
Start with an authorised target.
- Target reference
- Test scope
Define the running application and test scope before executing probes.
02 / Exercise
Inspect the request and response.
- Request evidence
- Response evidence
Review the evidence behind a dynamic test finding in its request context.
03 / Recheck
Verify the behaviour after a change.
- Application revision
- Retest result
Use a follow-up test to review the issue against the updated application.
Auth
Authenticated scanning
Form login, bearer token or basic auth.
Proof
Replayable evidence
Payload, request and response on each finding.
Route
SAST correlation
Dynamic and static findings meet on the handler.
Import
Pentest results
Burp Suite, Nessus and Qualys.
The category
What is DAST?
DAST is black-box testing of a deployed application. It crawls and probes endpoints, injects payloads into parameters and inspects how the application responds. It catches what static analysis cannot see, such as a misconfigured server, a missing security header or an injection that only appears once the framework, the proxy and the database are wired together. Its classic weaknesses are coverage (pages behind a login are never reached) and trust (findings without evidence are argued away). A modern DAST programme has to answer both.
SecurityVault answers both and then connects the result. Authenticated targets take the scanner past the login page when the configured authentication succeeds. Active findings retain request and response evidence for review. Where source context is available, route correlation helps developers investigate the relevant handler, and a retest records whether the observed behaviour still reproduces.
Authorised target
Define the running application in scope.
HTTP exchange
Inspect the request and the application response.
Route finding
Keep the tested endpoint with its supporting evidence.
Dynamic testing adds observed behaviour to the application investigation.
How SecurityVault does it
How does SecurityVault run DAST?
Targets
Register each application as a target with its base URL, authentication and scan profile. Profiles choose which attack modules run; schedules run them on a cadence, and target health shows when an application stopped answering.
Active testing
Active attack modules probe for injection, cross-site scripting, open redirects, path traversal and response-level weaknesses such as CORS policy, cookie flags and server version disclosure.
Config checks
Passive configuration checks read framework settings for debug mode, permissive CORS, insecure cookie flags, disabled CSRF protection, hard-coded secrets and missing HTTPS redirects, each reported with file, line and snippet.
Proxy and replay
The interactive proxy imports HAR files and curl commands, so a request captured in a browser can be replayed and modified to confirm a behaviour by hand.
Imports
Burp Suite, Nessus and Qualys exports arrive through a pentest import wizard, so manual and automated testing land in one place.
After the scan
What happens to a DAST finding?
It lands in the same findings model as your code, dependency, image and cloud findings, with the evidence attached and a remediation deadline from your SLA policy.
01
02
Correlated to code
Route matches connect dynamic and static findings where corresponding source context is available. Review the handler and evidence to determine the root cause.
03
Retested, not assumed
A retest replays the stored proof after the fix and records whether the issue still reproduces, so "fixed" is a tested result rather than a status someone set.
Governance
How do DAST results feed deadlines and compliance?
Every DAST finding receives a remediation deadline from your severity-based SLA policy, and breaches show in remediation SLAs beside every other overdue finding. Dynamic-testing results are recorded as evidence when controls are evaluated, and the framework cross-walk maps them to the vulnerability-detection and secure-development controls in your audit, so a recent authenticated scan supports the controls that ask for application testing. Carry the scan record into continuous compliance and evaluate release policy through deployment gates.
Endpoint evidence
Retain the observed request and response context.
Remediation deadline
Track the time allowed to address the finding.
Compliance review
Include the supporting record in control evaluation.
Observed behaviour remains connected to the work required.
Platform offerings
What is coming next for DAST?
- Two-identity authorisation testing for broken object-level access (IDOR).
FAQ
Frequently asked questions about DAST
- What is the difference between DAST and SAST?
- SAST analyses source code; DAST sends requests to an authorised running application and examines its responses. SecurityVault can correlate results by route where source context is available. A route match helps investigation but does not by itself establish the exact source line responsible. See SAST.
- Can DAST scan pages behind a login?
- Yes. A target can carry form-login, bearer-token or basic authentication, so the scanner reaches the authenticated surface of the application rather than only the public pages.
- How do I know a DAST finding is real?
- Each active finding stores the payload, the request and the response evidence that triggered it. You can replay it yourself, and a retest after the fix sends the same payload again and records whether the issue still reproduces.
- Can I bring results from Burp Suite or a penetration test?
- Yes. Burp Suite, Nessus and Qualys exports import through a guided wizard into the same findings model, so manual testing and automated scanning share one queue and one set of remediation deadlines.
- Does DAST need access to my source code?
- No. Active testing needs only a reachable target URL. Connecting source code adds the passive configuration checks and lets a dynamic finding be correlated to the static finding and the route handler behind it.
DAST covers the running application; its neighbours cover the rest. API security tests the specification and the route guards, SAST finds the flow in the code a dynamic finding points to, and attack surface management finds the hosts you did not know to register as targets. Built for AppSec teams running application testing at scale. See vulnerability management and the exposure entry in the glossary.
From the blog
Plan and verify your dynamic tests
- SSRF prevention: review a webhook delivery workerReview SSRF prevention in webhook workers with destination controls, redirect handling, isolated tests and evidence for release decisions.
- API authorisation: test your tenant boundariesBuild API authorisation tests around identity, tenant, object and action, using controlled fixtures to verify both allowed operations and denied access.
- API inventory: find undocumented endpoints safelyBuild an API inventory from specifications, source routes and deployment evidence, then assign ownership and review undocumented or retired endpoints.
- Authenticated DAST: prove what your scan reachedCheck authenticated DAST coverage with session verification, role-specific routes and a reproducible test record before trusting a quiet scan report.
See it on your stack
Bring one application.
One authenticated target, one scan, and a finding with the request and response that prove it.