Topic starter
18/08/2026 2:53 pm
TL;DR: Dynamic application security testing proves whether a vulnerability is exploitable in a running application, and Cycode's guide argues that this runtime confirmation matters more as AI agents ship code faster than manual review can keep up. The practical shift is toward continuous, CI/CD-embedded testing that complements SAST and SCA, because agentic development increases release volume and widens the gap between theoretical risk and real exposure.
Editorial analysis by NHI Mgmt Group, based on content published by Cycode: “What Is DAST? Dynamic Application Security Testing in the Agentic Era”.
Key questions
Q: What breaks when runtime testing is not in place for deployed applications?
A: Without runtime testing, teams may know a flaw exists in code but never confirm that it is actually exploitable in the running application.
Q: Why does continuous DAST matter more when AI agents accelerate software delivery?
A: AI-assisted delivery increases change volume and shortens the time between code creation and production exposure.
Q: What are the signs that DAST coverage is failing in practice?
A: Common signs include scans that never reach authenticated areas, incomplete API discovery, duplicate findings that never get deduplicated, and results that cannot be reproduced in the environment developers use.
Practitioner guidance
- Embed DAST at release gates Run runtime scans on every build, merge, or deployment that meaningfully changes application behaviour, and fail the pipeline when exploitable findings appear.
- Configure authenticated scan coverage Provide test accounts, session handling, or scripted login sequences so protected areas, APIs, and post-authentication paths are actually scanned.
- Correlate runtime findings with SAST and SCA Use cross-layer triage to separate exploitable issues from theoretical ones and to prioritise the findings that persist across code, dependency, and runtime context.
Bottom line: DAST matters because it confirms exploitability in the deployed application, not just weakness in code.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
18/08/2026 3:36 pm
Runtime confirmation is becoming the deciding control, not a supporting one. In agentic delivery environments, the question is no longer whether a flaw exists in code, but whether it is exploitable in the application that actually reaches users. That makes black-box runtime testing a governance control for release assurance, not just an AppSec technique. Teams that rely on static findings alone will keep overestimating coverage and underestimating exposure. The practitioner conclusion is to treat exploitability proof as a required control outcome.
A few things that frame the scale:
- Internal repositories are 6x more likely to contain secrets than public ones (32.2% vs 5.6%), contradicting the assumption that private repos are safe, according to the State of Secrets Sprawl 2026.
A question worth separating out:
Q: How do SAST, SCA, and DAST work together in DevSecOps?
A: SAST and SCA should run early in pull requests and builds, while DAST validates the deployed application from the outside. That sequence lets teams catch code flaws, dependency issues, and runtime behavior in the right order. The best programs treat the three as complementary controls, not substitutes.
👉 Read our full editorial: DAST in the agentic era: runtime testing still closes gaps