Dynamic analysis in DevSecOps: where DAST fits and where it does not

At a glance

What this is: This is an analysis of how dynamic application security testing, web proxies, penetration testing, and API-focused tooling fit into DevSecOps workflows.

Why it matters: It matters because IAM, NHI, and broader security teams need testing models that improve coverage and control without creating pipeline friction or blind spots.

👉 Read Semgrep's analysis of dynamic analysis, DAST, and DevSecOps coverage choices

Context

Dynamic application security testing is useful because it evaluates a running system, not just source code, but that also means it only sees the application through the behaviour it can observe at runtime. For DevSecOps teams, the real question is not whether to use dynamic analysis, but where it belongs in a workflow that already includes static testing, code review, secret scanning, and deployment controls.

This is relevant to identity security because dynamic testing often exposes broken authorisation, overbroad access, and API response leakage, all of which intersect with IAM and NHI governance. The article’s starting position is not unusual for mature engineering teams: the strongest security programme usually combines several testing modes rather than forcing every control into CI/CD.

Key questions

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

A: Place dynamic testing where it can observe the behaviours that matter most, such as internet-facing APIs, high-value workflows, pre-production validation, or production monitoring for unsafe responses. CI/CD can be one option, but not the only one. The better decision criterion is coverage of real runtime risk, not tool placement alone.

Q: Why do APIs create more runtime testing blind spots than traditional web apps?

A: APIs often expose object-level access, hidden fields, and direct request paths that generic web scanning does not model well. That means a tool can report clean results while still missing broken authorisation or data overexposure. Teams need API-aware tests that validate response boundaries and entitlement behaviour.

Q: What do security teams get wrong about SAST and DAST coverage?

A: They often treat the tools as substitutes rather than complementary controls. That leads to blind spots, either by missing design flaws that static analysis could catch or by missing live exploitation paths that only dynamic testing can expose. Coverage should be measured by phase and risk surface, not by vendor count.

Q: When does penetration testing add more value than automated scanning?

A: Penetration testing adds more value when the question is not just whether a flaw exists, but whether it can be chained into meaningful business risk. Skilled testers can combine tools, follow weak signals, and validate exploitability in ways scanners cannot. It is most useful for the most important applications.

Technical breakdown

Why dynamic analysis sees what static tools miss

Dynamic analysis tests software while it is running, which lets testers observe actual responses, business logic, and control failures that source-only scanning cannot confirm. DAST tools typically probe web apps and APIs from the outside, while IAST instruments the application from within. That makes dynamic testing valuable for validating exploitability, but it also means it depends on runtime reachability and test coverage. If a workflow or environment is not exercised, it will not be evaluated.

Practical implication: place dynamic testing where it can observe the behaviour that matters, rather than assuming CI/CD is the only useful execution point.

Where dynamic tooling fails in modern API estates

Modern API estates create a coverage problem for traditional DAST because many attacks happen through direct API calls, hidden fields, or access-control mistakes that generic scanners do not model well. API-specific fuzzing and monitoring tools help by generating malformed inputs, inventorying endpoints, and watching for abnormal response sizes or overexposed records. In identity terms, this often reveals broken authorisation and over-shared data paths, not just code defects. The mechanism is runtime observation plus request shaping, not simple vulnerability enumeration.

Practical implication: add API-aware runtime tests when access control and data exposure are the main risk, especially for services carrying identity or secrets-related data.

How penetration testing, IAST, and DAST complement each other

Penetration testing is not just a manual version of DAST. It uses skilled human judgement, multiple tools, and attack chaining to validate whether weaknesses become real business risk. IAST shifts some of that work into the application itself, which can improve visibility in pre-production or production. The trade-off is operational complexity, cost, and integration burden. For mature programmes, the right mix is shaped by architecture and risk, not by a single tool category.

Practical implication: use human-led testing for high-value applications and pair it with runtime tooling where automated coverage alone is too shallow.

Threat narrative

Attacker objective: The attacker objective is to turn runtime weaknesses such as broken authorisation or hidden data exposure into confirmed access, abuse, or exfiltration.

1. Entry occurs through runtime interaction with a web application or API, often by exercising requests that a static scanner cannot fully model.
2. Escalation happens when broken authorisation, overbroad responses, or hidden endpoints expose more data or functions than intended.
3. Impact follows when attackers or testers can confirm exfiltration, business logic abuse, or unsafe behaviour that changes the real risk picture.

NHI Mgmt Group analysis

Dynamic testing is a coverage problem, not a checkbox. The article’s core point is that security value comes from how much of the application’s real behaviour is exercised, not whether a DAST box sits in CI/CD. That matters because teams often confuse pipeline placement with control effectiveness. In practice, runtime coverage across APIs, pre-prod, production, and targeted human testing usually matters more than tool orthodoxy.

Broken authorisation is the identity signal hiding inside API testing. The most useful dynamic findings in modern systems are often not generic bugs but access-control failures, response overexposure, and data returned outside intended boundaries. That is an IAM and NHI governance issue as much as an AppSec issue, because runtime controls define what identities can actually do. Teams should treat dynamic findings as entitlement and authorisation evidence, not just as vulnerability output.

API-specific runtime controls are becoming the named concept that replaces generic web scanning. As applications move toward service-to-service communication, the old black-box web scanner model misses too much of the real attack surface. API fuzzing, inventory, and response monitoring create a sharper view of overexposed records and untested endpoints. The practitioner takeaway is simple: coverage must follow architecture, or the control will lag the system.

DevSecOps maturity is measured by feedback quality, not tool volume. The article is right to focus on fast feedback, system efficiency, and continuous learning. Those are governance properties, not product features. If a control slows delivery, creates noisy false positives, or misses the actual attack path, it is underperforming regardless of where it runs. Teams should judge control placement by signal quality and operational fit.

What this signals

Runtime testing will matter more as API estates become the default control surface. The practical signal for security programmes is that the most important validation is shifting away from generic web scans and toward checks that prove authorisation, inventory, and response boundaries. That creates a stronger case for pairing runtime testing with identity controls, because overexposed data often originates in weak entitlement design rather than in isolated code defects.

Secret exposure and runtime testing now belong in the same governance conversation. The reason is straightforward: leaked credentials and broken authorisation compound each other. When secrets are exposed and APIs are permissive, attackers do not need sophisticated exploitation to create impact. Security teams should treat runtime validation, secret scanning, and least privilege as one combined control system, not as separate projects.

For practitioners

• Map dynamic testing to risk-bearing paths Prioritise runtime testing on internet-facing APIs, workflows with business logic risk, and applications that handle identity or secrets data. Keep CI/CD as one execution point, but not the only one, so coverage follows the actual attack surface.
• Separate authorisation testing from generic vulnerability scanning Create test cases that explicitly verify response boundaries, object-level access, and record-level filtering. This is where dynamic tools add identity value, because broken authorisation often looks clean to traditional scanners.
• Use human-led testing for high-value applications Reserve penetration testing for systems where exploit chaining, judgment, and business context matter. Pair that work with runtime tooling so the human findings validate the most important exposure paths instead of chasing volume.
• Tune tool placement to developer workflow Run some tests in the IDE, some in pre-production, and some continuously in production when the control is safe to do so. The goal is to reduce feedback latency without blocking delivery or flooding teams with false positives.

Key takeaways

• Dynamic analysis is valuable because it validates real runtime behaviour, but it is not mandatory inside CI/CD for a DevSecOps programme to be effective.
• The most important gaps are often API authorisation, response overexposure, and incomplete runtime coverage, which are identity and governance problems as much as testing problems.
• Mature teams optimise for feedback quality, architecture fit, and risk-bearing coverage instead of forcing every control into one pipeline stage.

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.
• Runtime Authorisation: Runtime authorisation is the practice of deciding access while a task is in progress, rather than only at provisioning time. It matters for NHIs because credentials and entitlements can change risk mid-session, especially when automation or AI agents interact with sensitive systems.
• 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.

What's in the full article

Semgrep's full article covers the operational detail this post intentionally leaves for the source:

• Tool-by-tool discussion of DAST, IAST, web proxies, and API-specific scanners for different application types.
• Practical placement options across IDE, CI/CD, pre-production, production, and continuous monitoring.
• Trade-offs between automated scanning and human-led penetration testing for legacy and modern architectures.
• Non-tooling SDLC support such as training, architecture review, threat modelling, and security champion programmes.

👉 Semgrep's full post covers the testing trade-offs, deployment placements, and SDLC support options in more detail.

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, the industry's only accredited NHI security programme. Explore nhimg.org resources to connect identity governance to the broader security disciplines your programme depends on.