Notifications
Clear all
Topic starter
02/08/2026 12:16 pm
TL;DR: As AI-assisted development becomes normal, the article argues that dynamic application security testing still has a central role because it can test running applications for vulnerabilities, prompt injection, and sensitive-data exposure as code generation accelerates. The bigger shift is that DAST is moving from a late-stage scanner to a continuous security agent that has to fit into AI-driven delivery workflows.
NHIMG editorial — based on content published by Checkmarx: A Brief History and where DAST is headed in an AI world
Questions worth separating out
Q: How should security teams implement DAST in CI/CD pipelines?
A: Start by making DAST part of the release workflow, not a separate review process.
Q: What breaks when AI skills are judged only by static code review?
A: Static review misses behaviours that only appear at runtime, including hidden exfiltration, environment variable access, and unauthorized network calls.
Q: What do security teams get wrong about prompt injection defence?
A: They often assume better blocklists will solve the problem, but obfuscation simply changes the shape of the payload.
Practitioner guidance
- Embed DAST earlier in the delivery pipeline Run DAST against feature branches and staging environments, then keep it active in production-facing validation where risk justifies it.
- Add AI-specific abuse cases to test coverage Extend test suites to include prompt injection, data poisoning patterns, and unintended disclosure of sensitive or confidential information.
What's in the full article
Checkmarx's full article covers the operational detail this post intentionally leaves for the source:
- How the DAST workflow is expected to operate across feature branches, staging, and production.
- The article's treatment of prompt injection, data poisoning, and data leakage as AI-era testing cases.
- The way Checkmarx frames DAST as a security agent that can identify issues and support fixes.
- The broader AppSec programme implications that are only sketched here.
👉 Read Checkmarx's analysis of DAST in an AI-first AppSec programme →
DAST in an AI-first SDLC: are AppSec controls keeping up?
Explore further
02/08/2026 1:18 pm
DAST is becoming a runtime governance control, not just a security test. As AI-assisted delivery accelerates, the value of DAST shifts from finding defects at the end of a release cycle to observing security behaviour while code is alive. That matters because runtime is where access, data handling, and user-facing exposure are actually expressed. For AppSec leaders, the practical conclusion is that DAST should be governed as part of the delivery control plane, not treated as a discrete scanner run.
A question worth separating out:
Q: How do organisations decide whether DAST should be automated with remediation?
A: Automated remediation makes sense when the issues are low-risk, well-scoped, and governed by clear approval boundaries. The key decision is whether the testing agent has enough context to fix safely without changing business logic or access control. If not, DAST should still generate findings, but humans must own the change.
👉 Read our full editorial: DAST in an AI-first SDLC: what changes for AppSec teams
