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.
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: What breaks when DAST is treated as mandatory in CI/CD?
A: Teams often optimize for scan placement instead of security outcomes.
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.
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.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
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