Notifications
Clear all
Topic starter
02/08/2026 12:27 pm
TL;DR: Dynamic analysis can validate running applications, uncover business logic flaws, and confirm whether findings are exploitable, but the article argues it is not required inside CI/CD to do DevSecOps well, according to Semgrep. The practical test is whether the toolchain preserves fast feedback, broad coverage, and low false positives across the SSDLC, not whether it matches a vendor pattern.
NHIMG editorial — based on content published by Semgrep: dynamic analysis, DAST, and where DevSecOps teams should actually place testing
Questions worth separating out
Q: How should security teams decide where to run dynamic application testing?
A: Place dynamic testing where it can observe the behaviours that matter most, such as internet-facing APIs, high-value workflows, pre-production validation, or production monitoring for unsafe responses.
Q: Why do APIs create more runtime testing blind spots than traditional web apps?
A: APIs often expose object-level access, hidden fields, and direct request paths that generic web scanning does not model well.
Q: What do security teams get wrong about SAST and DAST coverage?
A: They often treat the tools as substitutes rather than complementary controls.
Practitioner guidance
- Map dynamic testing to risk-bearing paths Prioritise runtime testing on internet-facing APIs, workflows with business logic risk, and applications that handle identity or secrets data.
- Separate authorisation testing from generic vulnerability scanning Create test cases that explicitly verify response boundaries, object-level access, and record-level filtering.
- Use human-led testing for high-value applications Reserve penetration testing for systems where exploit chaining, judgment, and business context matter.
What's in the full article
Semgrep's full article covers the operational detail this post intentionally leaves for the source:
- Tool-by-tool discussion of DAST, IAST, web proxies, and API-specific scanners for different application types.
- Practical placement options across IDE, CI/CD, pre-production, production, and continuous monitoring.
- Trade-offs between automated scanning and human-led penetration testing for legacy and modern architectures.
- Non-tooling SDLC support such as training, architecture review, threat modelling, and security champion programmes.
👉 Read Semgrep's analysis of dynamic analysis, DAST, and DevSecOps coverage choices →
DAST in CI/CD: what DevSecOps teams should actually optimise?
Explore further
02/08/2026 1:26 pm
Dynamic testing is a coverage problem, not a checkbox. The article’s core point is that security value comes from how much of the application’s real behaviour is exercised, not whether a DAST box sits in CI/CD. That matters because teams often confuse pipeline placement with control effectiveness. In practice, runtime coverage across APIs, pre-prod, production, and targeted human testing usually matters more than tool orthodoxy.
A question worth separating out:
Q: When does penetration testing add more value than automated scanning?
A: Penetration testing adds more value when the question is not just whether a flaw exists, but whether it can be chained into meaningful business risk. Skilled testers can combine tools, follow weak signals, and validate exploitability in ways scanners cannot. It is most useful for the most important applications.
👉 Read our full editorial: Dynamic analysis in DevSecOps: where DAST fits and where it does not
