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.
Editorial analysis by NHI Mgmt Group, based on content published by StackHawk: “Running StackHawk in CI/CD”.
Key questions
Q: How should security teams implement CI/CD security without slowing delivery down?
A: Build security into the pipeline itself instead of adding late-stage manual gates.
Q: Why do seeded test environments matter for CI/CD security testing?
A: Security scans often mutate data as they probe an application, so inconsistent test state turns repeat runs into different experiments.
Q: What breaks when DAST scans are too slow in delivery pipelines?
A: Slow scans create friction at the point where developers expect rapid feedback, so teams start bypassing, rescheduling, or narrowing them until the control loses value.
Practitioner guidance
- Run DAST on pull requests and staging branches Place security scanning where developers still own the change, then add scheduled scans for code paths that change less often.
- Reset test state before every scan Use database snapshots or seeded data so each run starts from a known baseline.
- Break large scans into parallel units Split OpenAPI, GraphQL, and other large route sets into smaller pieces that can run concurrently in the pipeline.
Bottom line: CI/CD security testing is most effective when it runs inside the release flow, not after production exposure.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
02/08/2026 12:34 pm
CI/CD security testing is now a delivery-governance problem, not just a scanning problem. The article makes clear that the real decision is where to place control points so they shape release behaviour. When tests run too late, they become reporting; when they run in the pipeline, they become governance.
A few things that frame the scale:
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
- 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations, according to the State of Secrets Sprawl 2026.
A question worth separating out:
Q: When should teams break a security scan into smaller pipeline jobs?
A: Do it when the application is large, route-heavy, or composed of distinct API surfaces that do not need to be tested as one monolithic scan. Parallel jobs preserve coverage while reducing runtime, which makes the control more realistic for continuous delivery.
👉 Read our full editorial: CI/CD security testing changes how teams catch bugs before production