SAST vs DAST: Building a Practical Application Security Testing Plan

Why the tooling question is the wrong starting point

The SAST vs DAST question arrives dressed up as a procurement decision, and it never is one. By the time anyone asks it, there is already a pipeline and a backlog of findings nobody has triaged. Adding a scanner to that produces tickets.

What changes outcomes is the operating model around the scanners: coverage you can describe and owners who answer for findings. Vulnerability exploitation reached 20% of breach initial access vectors in Verizon's 2025 Data Breach Investigations Report, up 34% year on year. That pressure lands on delivery teams.

So treat SAST vs DAST as a coverage design problem. The rest of this article works through that design, from detection gaps to release gates.

SAST vs DAST basics

Static application security testing (SAST) analyses source code or compiled binaries without running them. Dynamic application security testing (DAST) sends crafted requests at a running instance and reads the responses. One needs repository access and language support. The other needs a deployed, reachable environment and credentials to get past the login page.

That difference decides everything downstream. SAST runs at commit or pull request, so a finding lands while the author still has the change in their head. DAST runs after deployment, which means findings arrive later and belong to whoever owns the service rather than whoever wrote the line.

Most SAST vs DAST comparisons stop at "white box versus black box" and leave the useful part out. The useful part is remediation context. A static finding names a file and a line. A dynamic finding names a request and a response, and someone still has to trace it back to code.

Neither gives you assurance on its own. The gaps are not symmetrical, and the next section maps them.

Static application security testing

Static application security testing walks the code the way a compiler does. It builds a syntax tree and then traces control and data flow from untrusted input to sensitive operations. Palo Alto Networks describes the approach as data flow analysis and syntactic pattern matching applied without executing anything. Because it reads every path, even those your tests never hit, coverage of the codebase is broad.

The cost is precision. Independent NIST SATE V benchmarking cited by Endor Labs found traditional static analysis producing 68 to 78 percent false positives across Java and C. A 2025 Ghost Security scan of public repositories was worse: of 2,116 flagged issues, only 180 were real. Tuning brings that down. Nothing removes it.

Language support is the other constraint. Your scanner covers the languages it covers, and a polyglot estate will have quiet corners. And because the analysis never runs the application, it cannot see what configuration or infrastructure actually does at request time. That blind spot is the reason the SAST vs DAST pairing exists at all.

Dynamic application security testing

Dynamic application security testing probes the deployed application and its APIs from the outside, with no view of the source. It confirms behaviour rather than inferring it, which is why a dynamic finding rarely gets argued down in triage. Something responded in a way it should not have, and there is a request to prove it.

Two conditions make or break the results. The first is authentication: an unauthenticated scan of a product where everything interesting sits behind login will report almost nothing worth reading. The second is endpoint discovery. Crawlers miss single-page application routes and undocumented API paths, so feeding the scanner an OpenAPI specification or recorded traffic changes coverage more than any setting in the tool.

What you get back is thin on code context. The scanner reports a vulnerable endpoint, and the engineering team spends the next hour finding the handler. Running dynamic application security testing also means owning an environment that behaves like production, with representative data and integrations that tolerate being attacked.

Compare detection coverage

Injection sits in the overlap. Static application security testing finds the unsafe query construction and dynamic testing proves the payload executes, so you know the flaw exists and that it is reachable. Insecure data flows and hardcoded secrets belong to the static side alone, because they are visible in code and invisible from the outside.

Runtime and configuration issues run the other way. Missing security headers and exposed administrative endpoints only exist once something is deployed. Access control is the uncomfortable case. The OWASP Top 10 for 2025 reports that 100% of applications tested contained some form of broken access control, and it is the category both methods handle worst.

Business logic flaws are the honest gap. Broken object level authorisation appears in around 40% of API attacks according to Salt Security, and Salt's research notes these authorisation flaws are not easily detectable with automated static or dynamic testing. A scanner does not know that account 5012 should not see invoice 4488. A human tester does. Any honest SAST vs DAST plan states that limit rather than papering over it.

Map the testing layers

First-party code and third-party dependencies fail differently, so they need different instruments. Software composition analysis (SCA) checks what you imported. The Black Duck 2025 Open Source Security and Risk Analysis report found 86% of codebases contained vulnerable open source components, and the mean count per codebase has since risen 107% to 581.

Mike McGuire, Senior Manager and OSSRA Data Advisor at Black Duck, put the problem plainly: "blind spots are prevalent when it comes to open source dependency management." With an average application carrying 911 open source dependencies, no code scanner is going to cover that surface.

Read the table as a coverage map. Wherever a row is missing from your pipeline, something is going unexamined.

Build the pipeline

Placement follows the constraint each method has. Static application security testing needs code, so it runs where code appears. Dynamic application security testing needs a deployment, so it runs after one exists. The UK National Cyber Security Centre's guidance on continually testing your security recommends that dynamic analysis tools run in parallel to the deployment pipeline, with results delivered into the team's own channels.

1. Commit and pre-commit: secret scanning and fast incremental SAST on changed files, plus SCA on manifest changes. Results appear in the editor or the commit status.

2. Pull request: full-diff SAST and dependency policy checks, posted as review comments against the lines they concern. This is the cheapest place to fix anything.

3. Build: container image and infrastructure-as-code scanning against the artefact you are about to promote.

4. Post-deploy to a test environment: authenticated DAST against the running service and its APIs, triggered by the deployment event rather than a cron schedule.

5. Pre-release and risk milestones: manual penetration testing scoped to what changed architecturally, plus anything the scanners flagged as uncertain.

The NCSC also warns that deployment pipeline controls should not be bypassed or re-ordered. A gate a team can skip with a flag is documentation. Getting the SAST vs DAST placement right matters less than making the placement enforceable.

Set scan cadence

Split every scanner into a fast mode and a deep mode. Incremental static analysis on changed files finishes in seconds and belongs on every commit. The full-repository scan, which takes minutes to hours depending on codebase size, runs nightly or before a release, and its findings go to a backlog rather than a red build.

Dynamic scanning needs the same split. A targeted authenticated pass against changed endpoints fits a per-deployment trigger. A full crawl with active injection payloads does not, so schedule it weekly against a stable environment. Ephemeral preview environments are useful here, provided the scanner can authenticate against them and the environment lives long enough for the scan to finish.

Feed the scanner your API contract rather than hoping it finds everything. Then be deliberate about production. Active dynamic application security testing sends payloads designed to change state, and running it against live systems risks data corruption and outages. Passive monitoring and attack surface scanning belong in production. Active testing does not.

One note on urgency. The 2025 DBIR found organisations took a median of 32 days to fully remediate edge device vulnerabilities, and 22% of exploitation targeted edge devices and VPNs, roughly eight times the prior year. Cadence decisions on internet-facing services carry more weight than the same decisions internally. Your SAST vs DAST schedule should reflect that asymmetry.

Manage findings

Scanners produce volume. An operating process turns volume into a short list of things that credible people agree are real, assigned to someone who can fix them. Without that process, the SAST vs DAST investment becomes a queue nobody reads, and developers learn to ignore a red pipeline.

Assign triage ownership

Three roles need naming before the first scan runs, and the split matters more than the job titles you use:

• Security owns validation and deduplication. They confirm the finding is real and assign risk using exploitability and asset criticality rather than the scanner's default severity.

• Engineering owns the fix and the feedback. When a finding is wrong, the engineer says why, and that reasoning becomes a suppression rule or a tuned query rather than a comment in a ticket.

• Product owns the trade-off. Accepting risk for a release window is a commercial decision, so it needs a named approver and an expiry date.

Recurring false positives are a tuning defect. If the same pattern gets dismissed three times, change the rule. Teams that skip this step reach the point where developers suppress everything, which is the failure mode worth designing against.

Set release gates

Blocking on every finding is how gates get disabled. Gate on a combination of severity and confirmed exploitability, then let everything else flow into the backlog with an owner and a date.

Separate new issues from inherited ones. A team taking over a legacy service cannot clear ten years of findings before shipping a bug fix, so the gate should block regressions introduced by this change while the historic backlog runs on a scheduled reduction plan. Compensating controls count, provided they are real and documented.

Exploitability is where prioritisation earns its keep. FIRST notes that the fraction of known vulnerabilities exploited in any 30-day window sits in the low single-digit percent, and that remediating everything scoring CVSS 7 or above wastes 96% of the effort. Every override needs a written reason and an approver.

Define remediation SLAs

Attach deadlines to severity, then adjust for circumstance. CISA's BOD 22-01 directive set two weeks for confirmed exploited vulnerabilities disclosed from 2021 onwards, which is a defensible anchor for anything internet-facing.

• Active exploitation or KEV listing: treat as an incident, not a ticket, and escalate to the service owner and the engineering lead on the same day.

• Internet-exposed assets: halve whatever window you would apply to the equivalent internal finding.

• High fix complexity: keep the deadline, but require a documented interim mitigation if the fix will overrun it.

• Accepted risk: time-bound and re-reviewed on expiry.

Track age rather than count. A backlog of 400 low-severity findings with none older than the SLA is healthier than 40 findings where six have been open for a year. Escalation should be automatic at the breach point and land on someone with budget authority.

Review the testing plan

What each layer covers and who owns triage belong in writing. If any of those is unwritten, it is being decided ad hoc by whoever is on call.

Evolved Ideas has built and supported software for organisations including Bridgestone and the NHS, and our engineers work inside client delivery pipelines on testing and release practice. Talk to our team about reviewing security testing across your lifecycle and settling SAST vs DAST coverage properly.