Topic starter
02/08/2026 12:27 pm
TL;DR: Dynamic testing can validate exploitable behaviour and business logic, Semgrep argues in its blog post, but DevSecOps should not be judged by whether DAST sits in CI/CD. Security programmes work better when they keep fast feedback, broad coverage, and low false positives across the SSDLC.
Editorial analysis by NHI Mgmt Group, based on content published by Semgrep: “You do not need to do DAST in a pipeline to do DevSecOps”.
Key questions
Q: When does dynamic testing add more value than static analysis alone?
A: Dynamic testing adds the most value when teams need to prove exploitability, inspect business logic, or validate API and runtime behaviour that code review cannot confirm.
Q: What are the signs that a dynamic testing programme is underperforming?
A: Common signs include slow pipelines, poor endpoint coverage, repeated false positives, and tools that miss API-specific paths or legacy behaviours.
Q: What breaks when DAST is treated as mandatory in CI/CD?
A: Teams often optimize for scan placement instead of security outcomes.
Practitioner guidance
- Define testing outcomes before tool placement Decide whether the primary objective is exploit validation, coverage of business logic, API authorisation checks, or developer feedback speed, then place dynamic testing accordingly.
- Split runtime testing by application type Use lighter-touch DAST or manual proxies for legacy web apps, and use API-specific fuzzing and monitoring where service calls carry the real risk.
- Measure scan value by false positives and coverage Track whether dynamic tests are slowing delivery, missing endpoints, or generating noise that teams ignore, because those are governance failures not tooling quirks.
Bottom line: DAST is useful for runtime validation, but the article argues it is not a mandatory ingredient of DevSecOps maturity.
Glossary terms: Dynamic Application Security Testing, Interactive Application Security Testing, Business logic vulnerability, API authorisation
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 2 days ago by NHI Mgmt Group
02/08/2026 1:26 pm
Pipeline placement is a governance decision, not a security virtue. The article is right to separate dynamic testing value from CI/CD dogma. DevSecOps succeeds when the programme preserves coverage, feedback speed, and trust in results, not when it satisfies a marketing narrative about where a scanner must run. Practitioners should treat tool placement as an operating choice, not a maturity badge.
A few things that frame the scale:
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
- 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations, according to the State of Secrets Sprawl 2026.
A question worth separating out:
Q: How should teams balance DAST, SAST, and pen testing in one SSDLC?
A: Use each control for what it does best. SAST and review find issues early, DAST validates runtime behaviour, and pen testing concentrates expert effort on the most important applications. A balanced programme does not force one control to carry all assurance needs.
👉 Read our full editorial: Dynamic analysis in DevSecOps: where DAST fits and where it does not