Continuous DAST Rescanning
How continuous DAST rescanning detects new vulnerabilities introduced by application changes, verifies remediation of previous findings, and maintains ongoing visibility into runtime security.
Primary question: Why should dynamic security testing be repeated as applications change?
Direct answer
Dynamic security testing should be repeated as applications change because new code, configuration, and deployment changes can introduce new vulnerabilities, and rescanning verifies that previous findings have been properly remediated
Dynamic security testing should be repeated as applications change because new code, configuration, and deployment changes can introduce new vulnerabilities. Rescanning detects new findings, verifies that previous findings have been remediated, and maintains ongoing visibility into runtime security as the application evolves. [derscanner-dast]
Rescan results can be compared to previous scans to identify new findings, remaining findings, and fixed findings. This comparison provides visibility into whether application changes have introduced new vulnerabilities, whether remediation has been effective, and whether the overall security posture has improved or degraded. [derscanner-dast]
Continuous rescanning does not guarantee complete security. DAST coverage still depends on what code paths, endpoints, and attack scenarios are exercised during each scan. Rescanning should be combined with SAST for comprehensive application security testing. [derscanner-sast][derscanner-dast]
Definitions
Rescan
Re-running dynamic analysis after application changes to detect new vulnerabilities, verify remediation of previous findings, and maintain ongoing runtime security visibility.
New findings
DAST findings that were not present in previous scans, indicating vulnerabilities introduced by application changes.
Remaining findings
DAST findings that are still present in a rescan, indicating vulnerabilities that have not been remediated.
Fixed findings
DAST findings that were present in a previous scan but are no longer detected in a rescan, indicating successful remediation.
The engineering problem
Applications change continuously through code updates, configuration changes, and deployment modifications. Without regular rescanning, organizations lose visibility into new vulnerabilities introduced by these changes. [derscanner-dast]
Without scan comparison, organizations cannot easily determine whether new findings are caused by recent changes, whether previous remediation was effective, or whether the overall security posture has improved. [derscanner-dast]
Manual tracking of DAST findings across multiple scans is error-prone and does not scale as applications and scan frequency increase. [derscanner-dast]
Security controls
Each control inspects a different artifact and produces evidence for an engineering decision.
Initial DAST scan
Baseline DAST- Artifact
- Running application.
- Risk
- No baseline for comparison with future scans.
- Output
- Baseline DAST findings for comparison with future scans.
Evidence: DerScanner dynamic testing documentation
Rescan after changes
Post-change DAST- Artifact
- Running application after code or configuration changes.
- Risk
- New vulnerabilities introduced by changes not detected.
- Output
- Rescan findings compared to baseline to identify new, remaining, and fixed findings.
Evidence: DerScanner dynamic testing documentation
Scan comparison
DAST scan comparison- Artifact
- Results from multiple DAST scans.
- Risk
- Missing new findings or failing to verify remediation without systematic comparison.
- Output
- Comparison report showing new findings, remaining findings, and fixed findings.
Evidence: DerScanner dynamic testing documentation
Verification workflow
- Run an initial baseline DAST scan against the running application.
- Document baseline findings for comparison with future scans.
- After application changes, run a rescan against the updated application.
- Compare rescan results to baseline to identify new findings, remaining findings, and fixed findings.
- Prioritize new findings for remediation and verify that fixed findings were properly addressed.
- Repeat rescanning after each significant application change to maintain ongoing visibility.
- Correlate DAST findings with SAST findings if available.
DerScanner · Enterprise
Relationship to DerScanner
DerScanner DAST supports rescanning and scan comparison to track new, remaining, and fixed findings over time.
DerScanner performs dynamic analysis with rescanning and scan comparison capabilities to track findings over time. [derscanner-dast]
Limits of verification
- DAST coverage depends on what code paths, endpoints, and attack scenarios are exercised during each scan. Changes in scan configuration or test scenarios may affect comparability between scans.
- Scan comparison requires consistent scan configuration and test scenarios to produce meaningful results.
- Correlation with SAST findings requires a supported mechanism; not all SAST and DAST tools provide correlation functionality.
Related knowledge
Combining SAST and DAST
Why organizations use both SAST and DAST together
Relationship: related-toDAST Scan Modes
Choosing between standard and aggressive DAST scan modes
Relationship: related-toSAST and DAST in CI/CD
How SAST and DAST fit into a CI/CD security workflow
Relationship: related-toCanonical terms used: Continuous DAST; DAST rescanning; Scan comparison; New/remaining/fixed findings.
Evidence and references
- DerScanner dynamic testing documentationDerScanner performs dynamic analysis of running applications with rescanning and scan comparison capabilities to track new, remaining, and fixed findings over time.
derscanner-dast - DerScanner static analysis documentationDerScanner performs static analysis and reports source-code security findings, including vulnerable imports and function calls to dependencies.
derscanner-sast
Continuous DAST rescanning