How should security teams decide where to run dynamic application testing?

Why This Matters for Security Teams

Dynamic application testing is often treated as a pipeline checkbox, but the real issue is whether the testing location actually exposes the application behaviour that attackers can reach. For security teams, that means choosing coverage based on runtime risk: public APIs, authentication flows, session handling, privileged actions, and output handling in systems that can trigger financial, operational, or trust impact.

This is especially important in modern delivery models where applications may be deployed across multiple environments, and where code scanning alone cannot reveal how the system behaves once requests, identities, tokens, and data all interact. The NIST Cybersecurity Framework 2.0 emphasizes managing risk across the full environment, which is the right lens here: the question is not where testing is convenient, but where it can observe meaningful security outcomes.

Teams often miss the highest-risk path because they optimise for build speed, not for exposure. In practice, many security teams encounter the failure only after a production workflow has already been abused, rather than through intentional runtime validation.

How It Works in Practice

Dynamic testing works best when it is placed where the application is most likely to fail in ways that matter to users or attackers. That may be in CI/CD for fast feedback, in a staging environment that mirrors production, or in production for narrowly scoped monitoring of unsafe responses. The right answer depends on what the team is trying to observe, not on a fixed deployment rule.

Security teams usually get better results when they align testing location to the control objective:

• Use CI/CD when the goal is to catch obvious runtime failures early, such as broken authentication checks or unsafe redirects.
• Use pre-production when the goal is to exercise realistic integrations, identity flows, and API dependencies without business impact.
• Use production monitoring when the goal is to detect risky behaviour that only appears with live traffic, real data, or genuine user journeys.

For application security programs that also track attack patterns, MITRE guidance is useful for thinking about how adversaries exploit exposed behaviour, while OWASP testing guidance helps translate that into validation of common web and API weaknesses. A practical control design is to place dynamic testing near the highest-risk runtime boundary, then limit blast radius with scoped accounts, safe test data, and clear rollback procedures.

That approach is stronger than “test everything everywhere,” but it still needs operational discipline. If tests cannot authenticate, cannot reach the relevant workflow, or are blocked from the very response paths the business depends on, the signal becomes misleading. These controls tend to break down in tightly coupled production systems with unstable test data, brittle third-party integrations, or legacy environments where safe test execution is not isolated from real customer activity.

Common Variations and Edge Cases

Tighter runtime coverage often increases operational overhead, requiring organisations to balance better behavioural visibility against test isolation, cost, and change-management friction. That tradeoff becomes sharper in regulated or high-availability environments, where teams may not be able to run aggressive checks in production and must rely more heavily on pre-production replicas or narrowly tailored live monitoring.

There is no universal standard for this yet. Best practice is evolving toward risk-based placement, especially for systems that combine web applications, APIs, and identity-driven access decisions. For example, if a workflow depends on privileged access, secrets handling, or step-up authentication, dynamic testing should be placed where those controls can actually be exercised rather than where the code is merely compiled. For teams building to a broader security program, the NIST Cybersecurity Framework 2.0 remains a useful anchor for mapping testing to risk management outcomes.

The edge cases are usually architectural. Microservices may require testing at the API gateway and again inside the service mesh. Mobile or single-page applications may need separate coverage for backend APIs and client-side logic. Agentic systems add another layer because the runtime risk includes tool use and autonomous action, not just HTTP responses. In those environments, the right decision is to place dynamic testing wherever the behaviour can be observed with enough fidelity to prove whether the control actually works.

Related resources from NHI Mgmt Group

• How should security teams decide between dynamic secrets and rotation?
• How do security teams decide whether to migrate or isolate a legacy application?
• How should security teams use Burp extensions in application testing workflows?
• How do security teams make API testing part of application governance?