SAST and DAST in CI/CD
Where SAST and DAST belong in a CI/CD pipeline — static analysis on the build, dynamic analysis on a running target, and how correlating both stages changes what you ship.
Primary question: How should SAST and DAST fit into a CI/CD security workflow?
Direct answer
SAST runs early during development and build when source code is available. DAST runs after deployment to a test environment when a running application exists. Correlation connects findings from both stages to provide more complete security visibility throughout the CI/CD pipeline
SAST runs early during development and build when source code is available. DAST runs after deployment to a test or staging environment when a running application exists. This timing difference means SAST and DAST provide complementary visibility at different stages of the CI/CD pipeline. [derscanner-sast]
SAST can run on every commit or pull request, providing early feedback to developers about code-level weaknesses. DAST typically runs after deployment to a test environment, providing visibility into runtime weaknesses before production deployment.
Correlation between SAST and DAST findings can be performed after both analyses complete, providing combined evidence for prioritization and remediation decisions before production deployment.
Definitions
CI/CD security workflow
The integration of security testing into a continuous integration and continuous deployment pipeline, where security checks run automatically at appropriate stages of the build and deployment process.
Early security testing
Security analysis that runs during development or build, before deployment, when source code is available. SAST is the primary early security testing technique.
Late security testing
Security analysis that runs after deployment to a test or staging environment, when a running application exists. DAST is the primary late security testing technique.
The engineering problem
Security testing that runs only at the end of the CI/CD pipeline misses the opportunity to provide early feedback to developers, leading to more expensive and time-consuming remediation.
Security testing that runs only during development misses runtime weaknesses that only manifest after deployment, when the application is running with real configuration and data.
Without correlation, SAST and DAST findings from the CI/CD pipeline are triaged separately, leading to duplicated effort and inconsistent prioritization.
Security controls
Each control inspects a different artifact and produces evidence for an engineering decision.
SAST in CI
SAST in build- Artifact
- Source code during build or commit.
- Risk
- Code-level weaknesses not identified before deployment.
- Output
- SAST findings with code location and severity.
Evidence: DerScanner static analysis documentation
DAST in CD
DAST in staging- Artifact
- Running application in test or staging environment.
- Risk
- Runtime weaknesses not identified before production deployment.
- Output
- DAST findings with endpoint and runtime evidence.
Evidence:
Correlation in pipeline
Pipeline correlation- Artifact
- SAST and DAST findings from the same build/deployment cycle.
- Risk
- Treating SAST and DAST findings independently without combined context.
- Output
- Prioritized findings based on combined code-level and runtime evidence.
Evidence:
Verification workflow
- Source code is committed and triggers the CI/CD pipeline.
- SAST analyzes source code during the build stage.
- Application is deployed to a test or staging environment.
- DAST analyzes the running application in the test environment.
- Findings from SAST and DAST are correlated to identify relationships between them.
- Correlated findings are prioritized based on combined evidence.
- Security gates evaluate findings according to organizational policy.
- Remediation is applied and verified through rescan.
- Application is deployed to production after security gates pass.
DerScanner · Enterprise
Relationship to DerScanner
DerScanner provides SAST, DAST, and results-correlation capabilities that can be integrated into a CI/CD security workflow across the build and deployment pipeline.
DerScanner performs static analysis and dynamic analysis, and can correlate findings between the two to provide combined code-to-runtime evidence. [derscanner-sast][derscanner-dast]
Limits of verification
- DAST requires a running target in a test or staging environment, which must be maintained and kept representative of production.
- Correlation requires a supported mechanism; not all SAST and DAST tools provide correlation functionality.
- Security gates must be carefully configured to balance security requirements with development velocity.
Step-by-step guides
Related knowledge
Combining SAST and DAST
Why organizations use both SAST and DAST together
Relationship: related-toStatic and Dynamic Security Testing Workflow
A practical combined SAST and DAST workflow
Relationship: related-toSecurity Testing Before and After Deployment
Why test application security both before and after deployment
Relationship: related-toClaude Code Security
Where agent-native review stops and the pipeline scan has to take over
Relationship: related-toCanonical terms used: SAST in CI/CD; DAST in CI/CD; Pipeline security testing; Early and late security testing.
Evidence and references
- DerScanner static analysis documentationDerScanner performs static analysis and reports source-code security findings.
derscanner-sast - DerScanner dynamic analysis documentationDerScanner DAST is a web-application scanner that detects vulnerabilities and backdoors by providing malformed or random inputs, using the black-box method without requiring source code. When source code is available, dynamic-analysis results can be correlated with static-analysis results for better accuracy and easier prioritization.
derscanner-dast
SAST and DAST in CI/CD