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.
At a glance
What this is: StackHawk argues that CI/CD security testing works best when DAST runs on pull requests and other pipeline stages, with scan speed, data reset, and failure thresholds tuned for delivery.
Why it matters: For IAM, NHI, and broader security teams, the operational lesson is that control placement matters as much as control capability, especially when build pipelines and ephemeral environments are part of the trust chain.
Context
CI/CD security testing is the practice of running security checks inside the delivery pipeline rather than after release. The governance gap it tries to close is simple: if security validation waits until production, teams discover issues after code, data, and access paths have already become harder to unwind.
The article focuses on DAST in automated delivery, where the question is not whether to test but where to place the test so it does not slow the pipeline or distort results. That matters to identity security because delivery pipelines often depend on service accounts, tokens, build runners, and ephemeral environments that must be governed as non-human identities.
For teams that run modern delivery stacks, the subject is typical rather than exceptional. The controls are already present in many environments, but the challenge is treating them as part of the security model instead of as developer convenience tooling.
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. Enforce branch protection, secrets management, dependency scanning, and deployment approval in automated workflows so developers get fast feedback and risky changes are blocked before production. The goal is to reduce rework, not add friction after release windows are already committed.
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. Seeded data or database snapshots keep the target reproducible, which makes findings easier to trust, compare, and triage across pipeline runs.
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. The practical failure is not just delay, but the gradual weakening of enforcement and developer confidence.
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.
Technical breakdown
How DAST fits into CI/CD pipeline timing
Dynamic application security testing probes a running application while the pipeline is still assembling and validating a release candidate. In a CI/CD model, that means the scan has to align with pull request checks, staging branches, or scheduled pipeline stages, not a post-deployment audit. The central architectural issue is feedback latency: the scanner must finish soon enough for developers to act on findings while the code change is still fresh and before the release path advances. That is why the article recommends frequent scans and discourages production execution.
Practical implication: Place DAST where it can influence release decisions without becoming a separate after-the-fact process.
Why scan consistency depends on seeded test data
DAST tools often issue requests that create, update, or delete application data as part of their probing. If each run starts from a different database state, findings become harder to reproduce and developers cannot tell whether a failure is a genuine regression or a test artefact. The article’s answer is to reset the target to a known baseline with snapshots or seed data before each scan. This is less about scanner tuning than about preserving evidentiary consistency across pipeline runs.
Practical implication: Use repeatable test data so security findings remain actionable and comparable from run to run.
How to reduce scan time without losing coverage
Scan duration usually grows because of network distance, overly broad route coverage, or large application footprints. The article points to three levers: run the scanner close to the target, exclude static content, and split very large applications into smaller scan units that can run in parallel. In practical terms, the performance problem is architectural, not just parameter-based. Scan design must reflect where the application lives, which routes actually change, and how the pipeline can parallelise safely.
Practical implication: Design scans around dynamic routes, proximity, and parallel execution instead of accepting slow full-scope runs.
Threat narrative
Attacker objective: The attacker objective is to slip unsafe code or compromised pipeline artefacts into production before defenders can block release.
- Entry occurs when vulnerable code moves through a delivery pipeline without security testing at pull request or staging stages.
- Credential and pipeline trust are then abused through CI/CD runners, tokens, and other automation artifacts that can be part of the delivery path.
- Impact lands when defective code reaches production or when the pipeline becomes too slow or noisy to enforce release decisions.
Breaches seen in the wild
- ArtiPACKED 2024: Unit 42 found public GitHub Actions artifacts in major open source projects leaking live GITHUB_TOKENs, runtime tokens and cloud tokens.
- reviewdog Action compromise 2025: A stolen maintainer token poisoned reviewdog/action-setup, leaking CI secrets including the tj-actions bot token used in the next attack.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
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.
Pipeline identities need the same discipline as application identities. Build runners, deployment tokens, and ephemeral test environments are non-human identities in practice, even when teams do not label them that way. That means access scope, lifecycle, and environment reset matter as much as scanner configuration.
Known-good test state is the named concept that determines whether DAST findings are trustworthy. Without seeded data, snapshot resets, and stable execution paths, the organisation ends up measuring environment drift as much as application risk. Practitioners should treat state control as part of the security signal, not an implementation detail.
Failure thresholds are a governance choice, not a scanner setting. The article shows that teams need to decide what level of risk should stop a release and what should be triaged without halting delivery. That decision becomes more important as pipelines move from human-led to increasingly automated enforcement.
The modern CI/CD stack is a control surface for identity and access, not only for code quality. Frequent scanning, asynchronous jobs, and scheduled scans all depend on trusted automation. Practitioners should align pipeline controls with identity governance so that the delivery system does not become the weakest automation layer.
From our research library:
- 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.
- Read next: CI/CD Pipeline Identity Security Guide
What this signals
Known-good test state is the practical boundary that separates useful CI/CD security testing from noisy automation. When environments are reset with snapshots or seed data, teams get repeatable evidence instead of arguing over whether the scanner or the data drift caused the result.
Pipeline identity controls deserve as much attention as application controls because build agents, deployment jobs, and test environments are part of the trust chain. That is where secrets, tokens, and release authority concentrate, so NHI governance and delivery governance increasingly overlap.
The next maturity step is not more scanning, but more disciplined orchestration of what gets scanned, when it gets scanned, and what state the target is in when the scan starts. That is how CI/CD testing becomes a release control rather than a periodic security activity.
For practitioners
- 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. That keeps findings close to the code and reduces the chance that vulnerabilities reach production unnoticed.
- Reset test state before every scan Use database snapshots or seeded data so each run starts from a known baseline. Without controlled state, repeated scans produce noisy results that are harder to reproduce and triage.
- Break large scans into parallel units Split OpenAPI, GraphQL, and other large route sets into smaller pieces that can run concurrently in the pipeline. Exclude static content and keep the scan focused on dynamic application paths.
- Set a build-breaking failure threshold Define which findings should fail the pipeline and which should be marked false positive, accepted, or assigned for follow-up. This lets teams block risky releases without turning every finding into an immediate stoppage.
- Tune scanner scope to the application architecture Use technology flags and path filters to reduce unnecessary tests, especially for monoliths and mixed route sets. The aim is to preserve coverage while keeping the pipeline fast enough for daily delivery.
Key takeaways
- CI/CD security testing is most effective when it runs inside the release flow, not after production exposure.
- Repeatable state and controlled scan scope matter because DAST findings are only useful when teams can reproduce them.
- The governance challenge is deciding which findings should block release and which should trigger triage without disrupting delivery.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8, NIST CSF 2.0 and CSA Cloud Controls Matrix set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-16 — Application Software Security | The article is about embedding security testing into the software delivery pipeline. |
| Recommendation — Integrate security checks into the CI/CD workflow so release decisions include application risk signals. | ||
| NIST CSF 2.0 | PR.PS-03 — Software, Data and Scripts Are Protected From Unauthorized Changes | CI/CD testing and pipeline gating help protect release artefacts from unsafe changes. |
| Recommendation — Protect build and release artefacts with pipeline controls that prevent unsafe code from shipping. | ||
| MITRE ATT&CK | TA0003;TA0011 — Persistence; Command and Control | The article's delivery-pipeline context intersects with adversary use of automation and release infrastructure. |
| Recommendation — Map pipeline abuse to attacker persistence and command paths when evaluating build infrastructure risk. | ||
| CSA Cloud Controls Matrix | SEF — Security Event and Incident Management | Automated scans in CI/CD generate security events that must be actionable and low-noise. |
| Recommendation — Tune pipeline security events so scan findings feed triage without overwhelming release operations. | ||
Key terms
- Continuous Integration Pipeline: A continuous integration pipeline is the automated workflow that builds, tests, and validates code changes before they are merged or released. For security teams, it is a practical control point for running checks on every build. This makes vulnerabilities visible while code is still active, not after deployment has created operational risk.
- Dynamic Application Security Testing: Dynamic Application Security Testing evaluates a running application from the outside to identify weaknesses that only appear under real execution conditions. It is useful for validating authentication, session handling, and API behaviour, especially where configuration and integrations change how the system actually responds to attack.
- Failure threshold: A failure threshold is the rule that decides when a security finding should stop a build or deployment. It turns test output into policy, but only works when teams also define triage states and exceptions clearly.
- Known-good State: A known-good state is a configuration snapshot taken when the application was working as expected. It gives incident teams a trusted reference point for restoration, especially when multiple humans, scripts, and automation paths can alter production settings.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, IAM, and secrets management. It helps security and identity practitioners connect delivery automation to the identity controls that keep pipelines trustworthy.
Published by the NHIMG editorial team on August 2, 2026.
Updated on October 13, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org