Notifications
Clear all
Topic starter
02/08/2026 9:40 am
TL;DR: Running dynamic application security testing in CI/CD lets teams catch security bugs before production, but it also creates trade-offs around scan timing, data consistency, pipeline latency, and failure thresholds, according to StackHawk. The governance issue is not whether to test, but how to make security checks fast enough, repeatable enough, and disruptive enough to matter.
NHIMG editorial — based on content published by StackHawk: Running StackHawk in CI/CD
Questions worth separating out
Q: How should security teams implement DAST in CI/CD pipelines?
A: Start by making DAST part of the release workflow, not a separate review process.
Q: Why do ephemeral test environments improve security testing quality?
A: Ephemeral environments improve quality because they start from a known state every time, which makes scanner output more comparable and easier to trust.
Q: What do security teams get wrong about blocking builds on DAST findings?
A: Teams often think blocking should be all-or-nothing.
Practitioner guidance
- Place DAST before release, not after deployment Run scans on pull requests, staging branches, or pre-production artefacts so security findings block delivery before production exposure.
- Reset test data for every scan run Use database snapshots or seed data to return the application to a known-good state before each scan.
- Run scanners as close to the app as possible Co-locate scan jobs with the target application, ideally on the same network, cluster, or host.
What's in the full article
StackHawk's full post covers the operational detail this post intentionally leaves for the source:
- Step-by-step patterns for running HawkScan on pull requests, staging branches, and scheduled jobs
- Configuration guidance for failure thresholds, includePaths, excludePaths, and technology flags
- Deployment patterns for Kubernetes jobs, parallel scan segmentation, and ephemeral test environments
- Examples of how to balance scan speed with coverage in large monoliths and multi-service pipelines
👉 Read StackHawk's guide to running DAST in CI/CD pipelines →
CI/CD security testing in delivery pipelines: what teams should change?
Explore further
02/08/2026 12:34 pm
CI/CD security testing fails when teams treat scan automation as a tooling choice instead of a control design choice. The article shows that DAST only becomes operational when it is aligned to pipeline stages, data resets, and release gates. That is a governance problem, not a scanner problem. For teams running identity-heavy delivery chains, the same applies to build credentials and deployment tokens: control reliability depends on how the pipeline is structured, not just which tool is installed.
A question worth separating out:
Q: How do teams know if agentic CI/CD controls are actually working?
A: Look for evidence that the agent cannot reach secrets, cannot mutate protected branches, and cannot execute shell commands outside its declared boundary. If telemetry shows attempted outbound calls, credential access, or policy violations being blocked or alerted on, the control is operating. If you only see clean workflow files, you do not yet know whether runtime guardrails are effective.
👉 Read our full editorial: CI/CD security testing changes how teams catch bugs before production
