Implement DAST scanning in staging environments
Implementation Effort: High – Standing up DAST against staging environments, tuning scans to reduce noise, and maintaining them as applications change is an ongoing engineering commitment. User Impact: Low – DAST runs against staging or pre-production environments configured by administrators; end users are not affected. Lifecycle Stage: Code
Overview
Implement dynamic application security testing (DAST) in staging or pre-production environments so runtime vulnerabilities are detected before release.
DAST is an active, intrusive test technique: it sends crafted and potentially malicious requests against a running application. For that reason it belongs in staging or ephemeral pre-production environments, not in production.
There is deliberately no companion "DAST in production" task, because production runtime risk is covered by a different class of control — runtime threat protection and posture management — rather than by re-running active scans against live customer traffic.
For production, rely on Microsoft Defender for APIs for runtime API protection, runtime container threat protection, and DevOps attack path analysis to surface exploitable exposure without injecting test payloads into live systems. Treat pre-production DAST and production runtime protection as a complementary pair that together cover the full lifecycle.
Static application security testing (SAST) examines source code and configuration files for known vulnerability patterns, but it cannot detect flaws that only manifest when an application is running. Dynamic application security testing (DAST) helps identify runtime weaknesses such as authentication bypass conditions, server misconfiguration, insecure session handling, and injection vulnerabilities that depend on live data flows. These are precisely the classes of weakness that threat actors probe with automated tooling against internet-facing endpoints. An organization that relies solely on SAST and dependency scanning has a blind spot for the runtime behavior of the application. Detecting and remediating these runtime weaknesses before release supports Assume breach by shrinking the exploitable surface exposed to production traffic.
Integrate DAST into GitHub Actions or Azure DevOps validation workflows and run those tests against staging or ephemeral environments rather than production. Most organizations should deploy a dedicated DAST tool in their CI/CD pipeline.
On GitHub, prefer SARIF output so results can be uploaded and reviewed in the code scanning experience. In Azure DevOps, publish DAST results as pipeline artifacts and create Work Items so findings are tracked. Do not assume native SARIF ingestion into Azure DevOps security alerts.
Microsoft Defender for APIs provides runtime protection and threat detection for APIs published through Azure API Management. It monitors production API traffic for abuse, unauthorized access, and anomalies, but it is not a DAST scanning engine for pre-production environments. Treat runtime API protection and pre-production DAST as complementary, not interchangeable.
For pre-production DAST, use dedicated scanning tools integrated into GitHub Actions or Azure Pipelines. Microsoft Defender for Cloud also offers a preview integration with StackHawk that surfaces DAST and API security findings (via SARIF) alongside other DevOps security results; validate its current support state, licensing, and roadmap before adopting it for production-critical workflows.