Topic starter
18/08/2026 2:53 pm
TL;DR: DAST confirms whether a vulnerability is exploitable in a live application, according to Cycode. Runtime validation matters more as AI-assisted delivery raises release volume and shortens the window for proving 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: 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.
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.
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.
Glossary terms: Dynamic Application Security Testing, Verified Exploitability, CI/CD Gate, API-First Attack Surface
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 1 day ago by NHI Mgmt Group
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