TL;DR: Dynamic analysis can validate running applications, uncover business logic flaws, and confirm whether findings are exploitable, but the article argues it is not required inside CI/CD to do DevSecOps well, according to Semgrep. The practical test is whether the toolchain preserves fast feedback, broad coverage, and low false positives across the SSDLC, not whether it matches a vendor pattern.
At a glance
What this is: This article argues that DAST is one option within dynamic testing, not a mandatory CI/CD requirement, and that DevSecOps should be judged by coverage, feedback speed, and false-positive rate.
Why it matters: It matters because security and IAM-adjacent teams should optimise where testing runs and what it covers, rather than assume that moving a scanner into CI/CD automatically improves control outcomes.
Context
Dynamic application security testing is only one way to interrogate a running system, and it is not synonymous with DevSecOps maturity. The governance gap is the assumption that a specific scan location, especially CI/CD, is the control objective rather than one possible operating model for preserving security outcomes across the software delivery lifecycle.
For IAM and NHI practitioners, that matters because modern delivery pipelines increasingly depend on service accounts, API keys, tokens, and ephemeral build identities. If a security programme overfits to tool placement instead of control coverage, it can miss how access, testing, and release workflows actually interact in CI/CD and production.
The article’s core point is typical of teams that have inherited tooling-first security thinking. The more useful question is not whether DAST sits in the pipeline, but whether the combined SSDLC control set catches exploitable issues without slowing delivery or drowning teams in noise.
Key questions
Q: What breaks when DAST is treated as mandatory in CI/CD?
A: Teams often optimize for scan placement instead of security outcomes. That can slow delivery, produce noisy findings, and still leave important runtime paths untested. The better test is whether the overall assurance model preserves fast feedback, meaningful coverage, and actionable results across the SSDLC.
Q: When does dynamic testing add more value than static analysis alone?
A: Dynamic testing adds the most value when teams need to prove exploitability, inspect business logic, or validate API and runtime behaviour that code review cannot confirm. Static analysis still matters, but runtime checks are better at showing whether an issue is reachable and operationally real.
Q: What are the signs that a dynamic testing programme is underperforming?
A: Common signs include slow pipelines, poor endpoint coverage, repeated false positives, and tools that miss API-specific paths or legacy behaviours. If developers ignore reports or testers cannot validate findings quickly, the programme is creating activity without improving assurance.
Q: How should teams balance DAST, SAST, and pen testing in one SSDLC?
A: Use each control for what it does best. SAST and review find issues early, DAST validates runtime behaviour, and pen testing concentrates expert effort on the most important applications. A balanced programme does not force one control to carry all assurance needs.
Technical breakdown
What DAST actually measures in a live system
Dynamic testing inspects an application while it is running, which means the tool observes runtime behaviour rather than source code. DAST usually works from outside the application, using a scanner, proxy, or direct API calls to probe responses, authentication paths, and input handling. That makes it useful for exploitable findings, business logic problems, and evidence that a reported issue is real. Its limitation is structural: without code visibility, it cannot explain design intent or guarantee complete coverage of all paths.
Practical implication: Use DAST where runtime evidence matters, but do not treat it as a substitute for source-aware controls such as SAST, review, and threat modelling.
Why API-heavy systems change the dynamic testing model
Modern applications expose more behaviour through APIs than through a single web front end, so dynamic testing increasingly needs API-specific tooling, fuzzing, and runtime monitoring. These tools can detect broken authorisation, unexpected response shapes, exposed records, and decommissioned endpoints that still answer requests. That is a different control problem from classic browser-based scanning because the attack surface is distributed across services, not concentrated in one page flow. For identity governance, the issue is often whether service-to-service access is scoped correctly when endpoints are invoked by machine identities.
Practical implication: Prioritise API coverage and service identity controls where the application’s real risk lives, not just where a traditional scanner is easiest to run.
Why CI/CD is a placement choice, not a security requirement
CI/CD is only one execution point in the broader SSDLC. Dynamic testing can run in the IDE, overnight, in pre-production, or continuously in production, depending on the risk being addressed and the operational tolerance for runtime impact. The article argues that DevSecOps quality depends on preserving fast feedback, whole-system efficiency, and continuous improvement, not on forcing a particular tool into the pipeline. In practice, the wrong placement can slow developers, increase noise, or reduce coverage, which weakens governance rather than strengthening it.
Practical implication: Choose the scan cadence and location that preserve developer flow while still producing evidence you can trust for release decisions.
Threat narrative
Attacker objective: The objective is to exploit runtime weaknesses in application or API behaviour to access data or functions that should remain out of reach.
- Entry occurs when vulnerable application logic, exposed APIs, or poorly controlled runtime paths are exercised by a scanner or attacker against a live system.
- Credential or authorisation weaknesses are then exposed through requests that return more data than expected or reach endpoints that should not be reachable.
- Escalation happens when broken authorisation, weak input handling, or incomplete surface coverage allows the issue to affect more records, more flows, or higher-value functions.
- Impact is the discovery or exploitation of exploitable application flaws that would have been missed by a poorly placed or narrowly scoped dynamic testing approach.
Breaches seen in the wild
- 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.
- Shai Hulud npm malware campaign: Shai Hulud campaign: npm malware exposed secrets on GitHub.
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
Pipeline placement is a governance decision, not a security virtue. The article is right to separate dynamic testing value from CI/CD dogma. DevSecOps succeeds when the programme preserves coverage, feedback speed, and trust in results, not when it satisfies a marketing narrative about where a scanner must run. Practitioners should treat tool placement as an operating choice, not a maturity badge.
API-era dynamic testing shifts the control question from pages to privileges. In API-heavy systems, runtime testing is increasingly about whether service identities can access the right object, field, or flow, not just whether a web form behaves as expected. That makes identity governance part of application testing, because broken authorisation in an API often means a machine identity has too much reach.
Coverage beats format when the release system is the control surface. Fast feedback matters only if the test actually reaches the risk. If an automated dynamic test misses large parts of the attack surface, the fact that it runs inside CI/CD is irrelevant. The stronger model is a mixed control set that combines static review, runtime validation, targeted pen testing, and monitoring where each adds distinct assurance.
Dynamic analysis is now one layer in a broader assurance stack. The article’s most useful signal is that modern development programmes need multiple verification paths, not a single canonical one. That approach aligns with how identity security is handled elsewhere: one control rarely covers provisioning, authentication, authorisation, and lifecycle risk at once. Practitioners should design for assurance depth, not tool orthodoxy.
From our research library:
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
- 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
Runtime assurance should follow risk concentration, not pipeline fashion. In modern delivery, the most valuable control is the one that actually reaches the system behaviour you need to test. That means developers, appsec, and IAM teams should align scan placement with where business logic, API authorisation, and machine identity exposure are most likely to fail.
Identity and access controls are increasingly part of application testing. When APIs return too many records or the wrong fields, the problem is often not the scanner but the authorisation model behind the request. Teams should therefore treat service-account scope, endpoint inventory, and response validation as linked parts of the same assurance problem.
For practitioners
- Define testing outcomes before tool placement Decide whether the primary objective is exploit validation, coverage of business logic, API authorisation checks, or developer feedback speed, then place dynamic testing accordingly.
- Split runtime testing by application type Use lighter-touch DAST or manual proxies for legacy web apps, and use API-specific fuzzing and monitoring where service calls carry the real risk.
- Measure scan value by false positives and coverage Track whether dynamic tests are slowing delivery, missing endpoints, or generating noise that teams ignore, because those are governance failures not tooling quirks.
- Pair dynamic testing with non-tool controls Keep threat modelling, architecture review, secure coding guidance, and security champion programmes in the SSDLC so runtime scanning does not carry the assurance burden alone.
Key takeaways
- DAST is useful for runtime validation, but the article argues it is not a mandatory ingredient of DevSecOps maturity.
- The strongest programme is the one that preserves coverage, fast feedback, and low false positives without forcing security tools to disrupt delivery.
- For modern API-heavy systems, testing strategy should be shaped by business logic, authorisation risk, and service identity exposure, not by scanner orthodoxy.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 and MITRE ATT&CK address the attack and risk surface, while OWASP ASVS, NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | The article repeatedly points to API authorisation and response overexposure as runtime testing targets. |
| Recommendation — Use API5 testing to validate that service calls cannot reach functions or records outside their intended scope. | ||
| OWASP ASVS | V8 — Authorization | The article’s runtime examples centre on whether exposed behaviour is properly authorised. |
| Recommendation — Apply V8 checks to confirm that application flows return only the data and actions each role is allowed to reach. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Dynamic tests are evaluating whether access decisions and entitlements are enforced correctly at runtime. |
| Recommendation — Review runtime access decisions against PR.AA-05 so exposed APIs and flows match intended authorisations. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | The article is about how to structure application security testing across the SDLC. |
| Recommendation — Map dynamic analysis into CIS-16 so application testing is balanced with other software assurance controls. | ||
| MITRE ATT&CK | TA0007;TA0009 — Discovery; Collection | The testing patterns discussed mirror how attackers probe runtime behaviour and gather exposed data. |
| Recommendation — Map uncovered API and runtime weaknesses to TA0007 and TA0009 to prioritise detection and containment. | ||
Key terms
- 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.
- Interactive Application Security Testing: IAST is a testing method that instruments an application from the inside while it runs in a controlled environment. It helps teams see how code behaves, which data flows are triggered, and where security weaknesses appear before deployment, but it does not govern identities after release.
- Business logic vulnerability: A business logic vulnerability is a flaw in how an application’s workflow or rules are enforced, allowing an attacker to misuse a process rather than break code directly. These issues often evade signature-based tools because the weakness lies in authorisation, sequence, or state handling.
- API authorisation: API authorisation is the decision logic that determines what an authenticated identity can do through an interface. It is stronger than simple login control because it governs actions, data access, and delegated requests at every service boundary.
Deepen your knowledge
NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. Explore the NHI Foundation Level course, the industry's only accredited NHI security programme, if your programme needs stronger control over service accounts, machine identities, and lifecycle governance.
Published by the NHIMG editorial team on August 2, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org