Topic starter
02/08/2026 12:16 pm
TL;DR: DAST is shifting from a late-stage compliance scanner to a continuous security agent as AI-assisted development, agentic code review, and automated testing reshape the SDLC, according to Checkmarx. That change matters because dynamic testing now has to catch prompt injection, data manipulation, and sensitive-data exposure across feature branches through production.
Editorial analysis by NHI Mgmt Group, based on content published by Checkmarx: “The Future of DAST”.
Key questions
Q: How should AppSec teams adapt DAST for AI-generated applications?
A: AppSec teams should extend DAST beyond classic vulnerability checks to cover prompt injection, data leakage, and unsafe runtime behaviour in AI-powered applications.
Q: What breaks when DAST stays a late-stage release gate?
A: A late-stage-only model misses the reality of feature branches, automated code generation, and rapidly changing runtime behaviour.
Q: Where does AI application testing fail in practice?
A: It fails when teams treat a single launch review as sufficient for a system that changes with prompts, retrieval context, tools, and model updates.
Practitioner guidance
- Expand DAST coverage into AI-specific abuse cases Add prompt injection, data manipulation, and sensitive-data exposure scenarios to runtime test suites for AI-powered applications.
- Move testing earlier and keep it continuous Run dynamic tests across feature branches, staging, and production so runtime assurance follows the SDLC rather than ending at release.
- Define automation boundaries for testing agents Specify which tests the agent may run, when it must escalate findings, and what evidence must be retained for review.
Bottom line: DAST is evolving from a release-time scanner into a runtime assurance control as AI-assisted development changes how applications are built and tested.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
02/08/2026 1:18 pm
DAST is being pushed from verification to continuous runtime governance. In AI-first delivery, the control is no longer just about finding known bugs before release. It has to observe how the application behaves once models, prompts, and user interactions are live, which makes runtime evidence the real object of governance. For AppSec teams, the practical conclusion is that testing scope now has to follow execution, not just code.
A question worth separating out:
Q: How should organisations govern autonomous security testing?
A: They should treat the testing agent like any other privileged non-human identity. That means least privilege, narrow scope, full logging, and human approval for sensitive actions. The goal is to make the automation auditable and bounded so it can test production safely without becoming an uncontrolled actor.
👉 Read our full editorial: DAST in an AI-first SDLC: what changes for AppSec teams