DAST exposes runtime application risks that static analysis misses

At a glance

What this is: DAST is presented as the control layer that reveals application weaknesses only visible at runtime, especially broken authentication, session handling flaws and API risks.

Why it matters: DevSecOps teams need runtime testing because static tools can miss the paths attackers actually use once code is live, and noisy findings can delay fixes if they are not prioritised.

Context

Dynamic application security testing, or DAST, evaluates a running application instead of the source code alone. That matters because authentication, session state, API behaviour and deployment-specific misconfigurations often only emerge when a system is live, which creates a governance gap for teams that assume static analysis gives a complete view.

For DevSecOps programmes, the identity angle is strongest around API authentication, session handling and broken access paths. Those are not just application defects; they are access-control failures that can expose accounts, tokens and business flows even when code reviews and dependency scans look clean.

Key questions

Q: What breaks when static analysis is used as the main AppSec control for AI code?

A: Static analysis breaks down when it is treated as the primary control for AI code because it cannot fully explain context, runtime behaviour, or why a generated change is risky in production. It remains useful, but only as part of a wider system that correlates build, dependency, and runtime evidence before decisions are made.

Q: Why do runtime authentication and API flaws create more risk than code defects alone?

A: Because attackers exploit the way a deployed system behaves, not the way it was intended to behave in source. Weak sessions, broken authentication and API authorization mistakes can expose sensitive functions even when code looks correct. The business risk is that live traffic reveals the weakness after release, when the blast radius is larger.

Q: How do security teams know if continuous DAST is actually working?

A: By checking whether scans can authenticate, traverse protected routes, reach business-logic paths, and run on changed code without frequent operator intervention. If the programme only works after repeated manual fixes, it is not continuous coverage. The right signal is stable reachability across releases, not the number of reported issues alone.

Q: Should teams run DAST before release or only after deployment?

A: Teams should do both, but with different depth. Lightweight checks belong in CI/CD so obvious runtime issues are caught early, while fuller scans belong in pre-production or scheduled monitoring where authenticated flows and API paths can be exercised more completely. That sequencing balances speed with meaningful coverage.

Technical breakdown

Why runtime-only flaws evade static analysis

Static application security testing looks for defects in code before execution, but many application risks are created by runtime state, configuration and chained behaviour. A login flow may be coded correctly and still fail in production because cookies are mis-scoped, a gateway is misconfigured, or an API responds differently under real traffic. DAST sends requests against the live system, observes responses and validates whether the vulnerable path is actually reachable. That is why it is effective for broken authentication, weak session management, insecure redirects and API flaws that only exist once components interact.

Practical implication: Run DAST against deployed environments where authentication and API behaviour can be observed in context, not only in code review.

Why alert fatigue undermines DAST value

Traditional DAST often generates a long list of findings without distinguishing exploitable issues from theoretical ones. That creates a governance problem for DevSecOps teams, because engineers spend time triaging repeated injection alerts, non-production noise and edge-case output instead of fixing the weaknesses that matter in production. The article’s core point is that runtime testing becomes useful when findings are contextualised against other signals such as SAST, SCA and IaC. That correlation turns DAST from a raw scanner into a prioritisation layer for real attack paths.

Practical implication: Correlate runtime findings with source, dependency and infrastructure context before assigning remediation priority.

How DAST fits into CI/CD without becoming a bottleneck

DAST only scales if it is treated as part of the delivery system rather than a separate security exercise. In CI/CD, lighter scans can run on pull requests or builds, while broader coverage belongs in pre-release or scheduled jobs. That sequencing lets teams test authentication flows, APIs and runtime controls close to release without slowing engineering throughput. The article also highlights that scale matters when organisations manage hundreds of repositories and frequent releases, because manual runtime testing cannot keep pace with modern delivery rates.

Practical implication: Embed runtime checks into pipeline stages that match release risk, and reserve deeper scans for pre-production gates.

Threat narrative

Attacker objective: The attacker wants to exploit a real runtime path, not a theoretical code defect, to gain unauthorized access or reach sensitive application data and functions.

1. Entry occurs when an attacker interacts with the live application surface and probes authentication, session and API behaviour that static tooling never validated in execution.
2. Credential access or abuse follows when broken authentication, weak session handling or insecure tokens allow access to functions or data that should have been denied.
3. Impact is reached when those runtime weaknesses expose sensitive business flows, customer data or administrative actions that the static pipeline failed to catch.

Breaches seen in the wild

• Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.
• Microsoft Midnight Blizzard breach: Midnight Blizzard (APT29) exploited legacy test account without MFA to breach Microsoft.

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

Runtime observability is now part of access governance: DAST matters because authentication, session state and API authorization are governance failures once code is live, not just defects at build time. Static tools can tell teams what might be wrong, but only runtime testing shows whether a user, token or request can actually cross the boundary. Practitioners should treat runtime validation as an access-control control, not an optional testing layer.

Alert fatigue is a control failure, not just a tooling inconvenience: When DAST floods teams with low-value findings, the programme loses its ability to distinguish exploitable risk from noise. That weakens remediation discipline and delays fixes for broken auth flows and insecure APIs. DevSecOps teams need prioritisation logic that links runtime findings to code, dependencies and infrastructure so security work maps to reachable attack paths.

Runtime API risk is now a mainstream application governance problem: The article’s cited 99% API issue rate underscores that API security is not an edge case. Broken object-level authorization, weak authentication and sensitive data exposure are recurring runtime failures that traditional static analysis can miss. The practical conclusion is that API governance must include live validation, not only design-time checks.

DAST becomes more valuable when it is treated as a verification layer for identity-bound application behaviour: Session cookies, bearer tokens and authenticated API calls are identity constructs inside the application stack. That makes DAST relevant to IAM-adjacent governance because it checks whether those constructs actually enforce the intended boundary under live conditions. Teams should use it to verify that application identity controls behave as designed after deployment.

Continuous delivery changes the security question from detection to timing: In fast-moving engineering environments, the issue is not whether a flaw exists in theory, but whether it is identified before it becomes a production path. DAST is most defensible when it runs often enough to track release velocity and when its outputs are interpreted alongside other controls. Practitioners should focus on timing, reachability and exploitability rather than raw finding counts.

From our research library:

• 71% of organizations use third-party APIs, according to Gartner’s 2024 data.
• Read next: NHI Lifecycle Management Guide

What this signals

Runtime validation is becoming a governance requirement for fast-release applications: When delivery cycles shorten, static review cannot be the last word on whether authentication and API controls work in practice. Teams need a control point that observes live behaviour, or they will keep discovering exploitable issues after release.

API security now depends on execution-time evidence, not just design-time assumptions: The 99% API issue rate cited in the article and the 71% third-party API usage figure from Gartner’s 2024 data show how deeply external interfaces shape attack surface. That means runtime authorization and session checks deserve the same governance attention as code quality and dependency risk.

Noise suppression is a programme design decision: DAST generates value only when findings are correlated with source, dependency and infrastructure context. Without that, teams risk spending more time triaging alerts than reducing exposure, which is exactly the failure mode DevSecOps was meant to avoid.

For practitioners

• Embed runtime testing in release pipelines Run lightweight DAST checks on pull requests or build stages, then reserve deeper scans for pre-release and scheduled runs so runtime validation keeps pace with delivery.
• Correlate runtime findings with source and build context Link DAST results to SAST, SCA and IaC evidence so teams can separate reachable vulnerabilities from noise and assign ownership to the right code or configuration change.
• Prioritise authentication and API paths first Focus triage on broken authentication, weak session handling, BOLA and insecure API responses because these issues expose real access paths rather than generic scanner output.
• Tune scan scope and baselines for non-production noise Exclude health, internal and dev-only paths where appropriate, and maintain baselines for repeated low-value results so alert volume does not obscure exploitable findings.

Key takeaways

• DAST closes the gap between code that appears secure and applications that are actually secure when running under real traffic.
• API authentication, session handling and runtime misconfiguration are the issues most likely to escape static analysis and become exploitable after release.
• DAST works best when it is embedded into CI/CD and correlated with SAST, SCA and IaC so teams fix reachable risk first.

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.
• Alert Fatigue: Alert fatigue is the condition where a security team receives so many low-value alerts that important events become harder to notice. In monitoring programs, it usually signals poor rule tuning, weak prioritisation, or a mismatch between detection logic and operational reality.
• Broken Object-Level Authorization: A failure to check whether an authenticated identity may access a specific object, record, or device. The request succeeds because the credential is valid, but the application does not enforce per-object entitlement. In NHI environments, this turns a legitimate token into cross-resource exposure.
• Runtime Security: Runtime security is the practice of detecting and constraining malicious behavior while software is executing. It focuses on live workload activity, not just code quality or pre-deployment checks, so teams can contain abuse after a system is already running.

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. It is designed for practitioners who need to connect identity controls to broader security programmes without losing governance precision.