DAST against staging on every release
Demonstrate that dynamic application security testing is consistently performed against the staging environment for every release, that findings are reviewed, and that release gates prevent promotion of applications with unacceptable vulnerabilities.
Description
What this control does
Dynamic Application Security Testing (DAST) is automatically executed against the staging environment as a mandatory step in every software release pipeline. The DAST scanner performs runtime analysis by sending crafted requests to the deployed application to identify vulnerabilities such as injection flaws, authentication weaknesses, and misconfigurations. This control ensures that security defects are detected in a production-like environment before code reaches production, reducing the window of exposure for exploitable vulnerabilities.
Control objective
What auditing this proves
Demonstrate that dynamic application security testing is consistently performed against the staging environment for every release, that findings are reviewed, and that release gates prevent promotion of applications with unacceptable vulnerabilities.
Associated risks
Risks this control addresses
- Deployment of applications with exploitable injection vulnerabilities (SQL, command, LDAP) that were not detected through static analysis alone
- Release of code containing authentication or session management flaws exploitable by unauthenticated attackers
- Production deployment of applications with insecure configurations (verbose error messages, exposed admin interfaces, weak TLS) observable only at runtime
- Bypass of security testing through ad-hoc or emergency release processes that skip the DAST gate
- Failure to detect vulnerabilities introduced by third-party libraries or frameworks that manifest only in runtime interactions
- Inconsistent or incomplete DAST scanning due to inadequate test coverage, authentication configuration, or scan policy tuning
- Unmitigated findings reaching production because DAST results are generated but not enforced as release criteria
Testing procedure
How an auditor verifies this control
- Obtain a list of all production releases deployed in the past 90 days, including release identifiers, dates, and associated applications or services.
- Review the CI/CD pipeline configuration files for a representative sample of applications to identify the stage where DAST is invoked and verify it targets the staging environment.
- Examine the DAST tool configuration to confirm scan policies, authentication settings, crawl depth, attack modules enabled, and severity thresholds defined for release blocking.
- Select three recent releases from different applications and retrieve the corresponding pipeline execution logs to confirm DAST scans were triggered and completed.
- Collect DAST scan reports for the selected releases and verify that findings are categorized by severity and mapped to specific vulnerabilities (OWASP Top 10, CWE references).
- Interview DevSecOps personnel to understand the process for reviewing DAST findings, triaging false positives, and documenting risk acceptance or remediation decisions.
- Review release gate configuration or policy documentation to confirm that releases with high or critical DAST findings are automatically blocked or require explicit security approval.
- Test the enforcement mechanism by reviewing at least one example where a release was delayed or rejected due to unresolved DAST findings, including evidence of the block and subsequent remediation.
Where this control is tested