SAST vs DAST: Coverage, Timing and How to Combine Them

Static and dynamic application security testing find different classes of flaw at different points in delivery, and teams that buy one expecting it to cover the other end up with blind spots and noisy backlogs. SAST reads source code, bytecode or binaries without running them; DAST exercises a running application from the outside. This guide compares coverage, timing, accuracy and cost, explains when each is the better first investment, and sets out how to combine them in a pipeline without overwhelming developers. It is for application security leads, DevSecOps engineers and engineering managers planning or tuning a testing programme.

Key takeaways

SAST finds flaws in code before it runs. It points to the file and line, works early in the IDE or pull request, and is strongest on injection and unsafe API patterns.
DAST finds flaws in behaviour after deployment to a test environment. It sees configuration, headers, session handling and server responses that are not visible in source code.
Neither covers access control well on its own. OWASP lists authentication, access control and cryptography misuse among the issues static tools find hard to detect, and scanners need valid test identities to reach them at all.
Timing drives the choice. SAST gives fast feedback on every change; DAST gives slower but higher-confidence findings on a deployed build.
Combine by stage, not by duplication. Run fast SAST rules on pull requests, full SAST nightly, and authenticated DAST against staging on every release candidate, with one triage workflow for both.

What each one is

SAST (static application security testing) analyses human-readable code or compiled artefacts against rules for insecure patterns, typically by tracing data from untrusted sources to dangerous sinks. OWASP notes that these tools scale well, run repeatedly in builds, and report the exact file and line number, but produce high numbers of false positives, struggle to prove that a finding is exploitable, and often need code that compiles with its libraries present.

DAST (dynamic application security testing) sends requests to a running web application or API, normally from the outside, and inspects the responses. OWASP describes these scanners as looking for issues such as cross-site scripting, SQL injection, command injection, path traversal and insecure server configuration. DAST needs no source code, so it also works on third-party and legacy applications.

NIST SP 800-218 (the Secure Software Development Framework) treats them as separate practices: PW.7 covers reviewing or analysing human-readable code, with a static analysis tool as an example, and PW.8 covers testing executable code, with dynamic vulnerability testing, fuzzing and penetration testing as examples. NIST SP 800-53 Rev. 5 mirrors this with SA-11(1) Static Code Analysis and SA-11(8) Dynamic Code Analysis.

Side-by-side comparison

Dimension	SAST	DAST
What it examines	Source code, bytecode or binaries	A running application over HTTP, HTTPS or API calls
Access needed	Repository and build configuration	A deployed URL, test accounts and an API definition where available
When it runs	IDE, pull request, build, nightly	After deployment to test or staging; sometimes scheduled against production with care
Feedback speed	Seconds to minutes for incremental scans	Minutes to hours for a full crawl and attack phase
Location of findings	File, line and data flow	URL, parameter, request and response
Strong at	Injection sinks, unsafe functions, hard-coded values, insecure API use, dead branches the scanner cannot reach	Server and TLS configuration, security headers, cookie flags, session handling, reflected input, behaviour of the whole deployed stack
Weak at	Configuration, runtime behaviour, business logic, issues spanning services	Code paths it cannot reach, root cause location, logic that needs multi-step workflows
False positive pattern	Higher: reports paths that are not exploitable in practice	Lower for confirmed findings, but misses anything not exercised
Language dependence	Needs support for each language and framework	Language independent
Main operational risk	Developer fatigue from noise	Test data corruption, account lockouts or load on shared environments

Coverage by vulnerability class

The table gives typical strength by class. It is a planning guide, not a guarantee: tool quality and rule sets vary, and the OWASP Benchmark project exists to measure real results on your own shortlist.

Class	SAST	DAST	Better partner
SQL and command injection	Strong (source to sink tracing)	Good where the input is reachable	Both
Cross-site scripting	Good, depends on framework knowledge	Good for reflected, weaker for stored	Both
Security misconfiguration and headers	Weak	Strong	Configuration scanning
Broken access control (object level)	Weak	Limited without multiple test users	Manual testing and authorisation tests
Cryptography misuse	Good for weak algorithms in code	Good for TLS settings	Both
Hard-coded secrets	Some rules	No	Dedicated secret scanning
Vulnerable dependencies	No (that is SCA)	Only when a version banner leaks	Software composition analysis
Business logic flaws	Weak	Weak	Threat modelling and penetration testing

For classes neither tool covers well, interactive testing (IAST) instruments the running application to combine code location with runtime confirmation. See the Interactive Application Security Testing (IAST) and RASP Guide.

When to choose SAST first, and when DAST first

Choose SAST first when you own the code, ship often, and want developers to fix issues in the pull request. It also suits organisations with many repositories and few deployed test environments.
Choose DAST first when you run third-party, legacy or low-code applications without source access, or when your largest exposure is internet-facing configuration rather than code.
Small organisations: start with the static analysis built into your code hosting or CI platform on pull requests, plus an open source DAST baseline scan against staging before release. See the Open Source AppSec Tools Landscape Guide.
Large organisations: run both, feed findings into one posture view, and define per-application testing tiers by risk. See the Application Security Posture Management (ASPM) Guide.
Regulated or high-risk systems: add penetration testing (SA-11(5)) on top. Automated tools are a floor, not a substitute.

Where identity fits

An unauthenticated DAST scan sees the login page and little else. Authenticated scanning needs dedicated test accounts per role, so the scanner can reach protected functions and so access control tests can compare what each role sees. Treat these as non-human identities: create them only in test environments, give them the minimum roles needed, store their credentials in a secrets manager rather than in scanner configuration files, and rotate them. The same applies to the tokens SAST tools use to read repositories and post pull request comments. See the CI/CD Pipeline Identity Security Guide.

How to combine them in a pipeline

Agree a secure coding standard and rule set. SSDF PW.7.2 expects analysis against the organisation's secure coding standard. Start SAST with a small, high-confidence rule set (injection, deserialisation, unsafe crypto) rather than every rule.
Run SAST in report-only mode. Scan the main branch, triage the baseline and suppress confirmed false positives with recorded reasons. The SAST Triage Guide covers this.
Add incremental SAST on pull requests. Comment on new findings only, so developers are not shown the historical backlog.
Stand up DAST against staging. Import the OpenAPI definition for APIs, configure authenticated test users, exclude destructive endpoints, and start with a passive or baseline scan.
Turn on gates gradually. Block merges only for new high-severity SAST findings with a data flow; block releases only for confirmed high-severity DAST findings. Keep a documented override with expiry.
Merge triage. Send both outputs to one tracker, deduplicate by CWE and endpoint, and record root causes as SSDF PW.7.2 and PW.8.2 ask.
Roll back safely. If a gate blocks delivery unexpectedly, switch that rule to report-only rather than removing the scanner, and review the rule within a sprint.

The SAST, SCA and code scanning tool rollout playbook gives a fuller rollout plan.

Threat model, failure modes and decision criteria by option

SAST

Threat model. SAST defends against the developer mistake that an attacker later finds: untrusted input reaching a dangerous sink such as a SQL query, shell command, file path or deserialiser, or code that uses a weak algorithm or an unsafe API. It assumes the attacker has no special access, only the ability to send input the code fails to handle. It does nothing against a misconfigured server or a vulnerable library pulled in at build time, and it cannot see a malicious change if the rule set has no pattern for it, which is why SSDF PW.7.2 also lists expert review for backdoors and other malicious content.

How it works in practice. The tool builds a model of the program (abstract syntax tree, call graph and data flow), marks sources such as request parameters and sinks such as query execution, and reports paths between them that lack a recognised sanitiser. Its accuracy depends on how well it understands each framework: if it does not know that a templating library escapes output, it reports a false positive; if it does not know that a helper function builds a query, it misses a true one.

Failure modes. Noise that trains developers to ignore findings; custom sanitisers the tool does not recognise; languages or frameworks with partial support; generated code and reflection that break the data flow; code that does not compile in the scan environment, so the tool silently analyses less than you think; and suppressions with no reason or expiry that hide real issues months later.

Controls. A documented secure coding standard and a rule set mapped to it (PW.7.2); recorded triage decisions with a named reviewer; custom rules or sanitiser models for in-house libraries; a scan health check that fails loudly when files are skipped; and periodic review of suppressions.

Decision criteria. Language and framework coverage for your actual stack; incremental scan time short enough for pull requests; how clearly each finding shows the data flow; ease of writing custom rules; and measured precision on your own code, for example using the OWASP Benchmark approach on a shortlist.

DAST

Threat model. DAST takes the attacker's position: an outsider, or a user with a valid account, sending crafted requests to the deployed application. It finds what that attacker could find, including flaws that only exist once code, framework, server and configuration are assembled, such as missing security headers, verbose errors, weak TLS settings and cookies without the Secure or HttpOnly flags. It sees nothing it cannot reach, so its threat model is only as wide as its crawl and its test accounts.

How it works in practice. The scanner discovers endpoints by crawling links, importing an API definition or replaying recorded traffic, then sends attack payloads to each parameter and judges the responses. Modern single-page applications and APIs often expose little to a crawler, so an imported OpenAPI definition and recorded login sequences decide how much is tested.

Failure modes. Losing the session halfway through a scan and testing the login page for an hour; missing endpoints that the crawler never found; multi-step workflows such as checkout or approval that payloads break before reaching the vulnerable step; anti-automation controls or a web application firewall that block the scanner and produce a clean but meaningless report; and active scans against shared or production systems that create records or lock accounts.

Controls. Session validation checks during the scan; endpoint coverage measured against the API definition; allow-listing the scanner's source address in test environments rather than disabling protection in production; separate test accounts per role; excluded destructive operations; and agreed scan windows.

Decision criteria. Support for your authentication flows (forms, single sign-on, tokens); API definition import; scan time against your release cadence; clear reproduction evidence (request and response) for each finding; and safe defaults for non-destructive testing.

Worked scenarios

SAST scenario: a product team with 40 repositories. A team ships several times a day and has no long-lived test environment. It enables static analysis on pull requests with only injection, deserialisation and weak cryptography rules. The first main-branch scan returns several hundred findings; the application security lead triages a sample per rule, disables two rules that produce mostly false positives because the tool does not recognise the team's query builder, and writes a custom sanitiser model for it. Pull request scans now show only new findings. A month later a developer adds a reporting endpoint that concatenates a sort parameter into a query; the pull request comment shows the source, the sink and the line, and the fix lands before merge. The root cause (no allow-list helper for sort columns) is recorded, as SSDF PW.7.2 asks, and a shared helper is added so the pattern stops recurring.

DAST scenario: a purchased customer portal. An organisation runs a vendor-supplied portal it cannot see the source for. It deploys a copy to staging, imports the portal's API definition, and creates three test accounts: customer, support agent and administrator, each stored in a secrets manager and used only against staging. A baseline passive scan finds missing security headers and a session cookie without the Secure flag. An active authenticated scan, with password reset and payment endpoints excluded, finds that the support agent role can read another customer's record by changing an identifier, confirmed by comparing responses across the three accounts. Because there is no source, the finding goes to the supplier with the request and response as evidence, and a compensating rule is applied at the gateway until a fixed release is tested again with the same scan profile, in line with SSDF PW.8.2, which includes tests for previously reported vulnerabilities in the test suite.

Detection and measurement

Coverage: share of repositories with SAST on pull requests, and share of internet-facing applications with authenticated DAST each release.
Precision: share of findings confirmed true after triage, tracked per tool and rule, so noisy rules can be tuned or retired.
Time to fix: median days from detection to fix for high-severity findings, separately for SAST and DAST.
Escape rate: vulnerabilities found by penetration tests, bug bounty or incidents that the automated tools should have caught.
Authenticated reach: proportion of known endpoints the DAST scan actually exercised, compared with the API definition.

The AppSec Programme Metrics Guide covers how to report these.

Common failure patterns

Full rule set on day one. Thousands of SAST findings land at once, developers stop reading them, and real issues are ignored.
Unauthenticated DAST. The scan reports clean because it never got past the login page.
Scanning shared environments blindly. Active scans submit forms and create records, corrupting test data or locking accounts used by other teams.
Assuming SAST covers dependencies. Third-party library vulnerabilities need software composition analysis, a separate tool.
Counting findings, not fixes. Reporting volume encourages noise; report confirmed findings fixed and time to fix.
Over-privileged scanner identities. Production admin credentials in a scanner configuration file turn a testing tool into a high-value target. See Securing the SAST, SCA and code scanning tool itself.

Framework mapping

Framework	Reference	SAST	DAST
NIST SP 800-218 (SSDF)	PW.7, PW.8	PW.7 review and analyse human-readable code	PW.8 test executable code
NIST SP 800-53 Rev. 5	SA-11(1), SA-11(8), SA-15(7)	SA-11(1) Static Code Analysis	SA-11(8) Dynamic Code Analysis
NIST SP 800-53 Rev. 5	RA-5	Supporting	Vulnerability monitoring and scanning of deployed systems
NIST CSF 2.0	PR.PS-06, ID.RA-01	Secure development integrated in the life cycle	Vulnerabilities identified, validated and recorded
OWASP ASVS 5.0	Verification requirements	Test basis for code-level controls	Test basis for runtime controls

Practitioner checklist

Map each application to a testing tier that states whether SAST, DAST or both are required.
Start SAST with a high-confidence rule set and a triaged baseline.
Scan pull requests incrementally and show only new findings to developers.
Run authenticated DAST with role-specific test accounts against staging for every release candidate.
Exclude destructive endpoints and agree scan windows with environment owners.
Store scanner credentials in a secrets manager with least privilege and rotation.
Route SAST and DAST findings into one tracker, deduplicated by CWE and endpoint.
Add SCA and secret scanning; neither SAST nor DAST replaces them.
Track precision, time to fix and escape rate per tool, and retire noisy rules.