DAST vs SAST: when to choose each and when to run both
Choose SAST when you control the source code and want flaws reported early, while developers still have the change in front of them. Choose DAST when you need evidence of how the running application behaves, including its headers, sessions, server configuration and responses to hostile input. For most programs that ship a web or API application, run both. The two answer different questions, and neither replaces a tester-led penetration test. NIST SP 800-115 notes that organizations often combine techniques to reach an in-depth assessment at an acceptable level of risk, and the OWASP Web Security Testing Guide (WSTG) v4.2 makes the same point: no single technique is enough.
The SAST advantage matters most when your team writes most of the code, the build is automated, and you can scan each change in continuous integration. OWASP notes that these tools scale well, can run in nightly builds, and point to the file and line affected, which shortens the path to a fix. The DAST advantage matters most when you depend on frameworks, gateways or server settings that source scanning cannot fully see, or when you need to show a reviewer what an attacker could send to a deployed endpoint. Confirm whether your code can be compiled or built in your pipeline, because OWASP lists that as a common reason SAST tools produce weak results.
Both approaches produce noise. Ask each vendor or open-source project for its false positive handling and for how suppressed findings are recorded. NIST SA-11(1) treats a high density of ignored findings as a sign that the analysis process or tool needs attention, so track that ratio from the first run. For DAST, confirm the scan authentication method, the target environment and who may run active scans against it, since scanners send real attack payloads. Before release, agree on which findings block a build and which go to a backlog. Then schedule a penetration test that uses the scanner output as a starting point rather than as the result.
DAST vs SAST side by side: goals, scope, inputs and outputs
This table compares how DAST and SAST differ on goal, scope, required inputs, pipeline stage, typical output, owners and NIST SA-11 mapping. Read it to see which one fits the artifacts and access your team can provide, and why the two answer different questions about the same application.
| Factor | SAST | DAST |
|---|---|---|
| Primary goal | Find security flaws in source or compiled code before or as the software is built | Find exploitable weaknesses in a running application by sending requests and reading responses |
| What is tested | Code paths, data flows and known flaw patterns such as buffer overflows and SQL injection | Externally reachable behavior, such as cross-site scripting, SQL injection, command injection, path traversal and server configuration |
| Inputs needed | Source code or compiled artifacts and build configuration the tool can parse | A running test environment, its URL, and test credentials for authenticated areas |
| Typical pipeline stage | Commit, nightly build or continuous integration, where code can be scanned automatically | Staging or test environments after deployment, since the application must be running |
| Typical output | Findings that point to the affected file and line, often with high false positive volume to triage | Findings tied to a URL, parameter or request, with evidence of the response observed |
| Who acts on findings | Developers fix the code; AppSec staff tune rules and track ignored findings | Developers and testers reproduce findings in the running system; operations may fix server configuration |
| Known blind spots | Authentication, access control and cryptography issues are hard to find automatically; configuration gaps are often missed | Flaws that need deep code knowledge or are not reachable through the interface being scanned |
| NIST SA-11 enhancements | SA-11(1) static code analysis; SA-11(8) relates to dynamic analysis, while SA-11(9) covers interactive testing | SA-11(8) dynamic code analysis, including runtime tools and fuzz testing as a form of dynamic analysis |
| Confirm with your assessor | Which enhancements your system baseline selects and what evidence of scan coverage they expect | Whether authenticated scanning and test data handling meet your environment's rules |
What SAST finds, misses and what DAST finds, misses
SAST reads the code and points to the exact file and line, while DAST probes the running application from outside. Each approach has blind spots the other can cover, so the cards below separate what each method reaches from what it cannot see on its own.
SAST flaw pattern detection
SAST tools examine source or compiled code and find flaw patterns such as buffer overflows and SQL injection. They scale well and can run in nightly builds or continuous integration, and they point to the affected file and line. Check whether your team's language and build setup are supported before assuming coverage, because many tools struggle with code that cannot be compiled.
SAST blind spots in access control
OWASP notes that authentication, access control and cryptography issues are hard to find automatically, so a clean SAST report says little about who can reach which function. These flaws depend on how roles, sessions and data rules fit together. Pair SAST with reviewers or runtime tests that log in as different users and attempt cross-account actions.
SAST gaps in configuration
Configuration issues are often missed by SAST because the risky setting lives in deployment files, web server settings or the environment rather than in the code. A reviewer checking the code alone will not see a permissive header, a debug flag or a weak TLS setting. Ask which configuration files are in scope for your SAST run and who reviews them at deploy time.
DAST runtime and server findings
DAST scanners test the application from the outside for cross-site scripting, SQL injection, command injection, path traversal and insecure server configuration. Because they exercise the deployed build, they catch problems that only appear at runtime, including server settings that SAST misses. Confirm that the scanner runs against a staging instance with test accounts and data, not production.
DAST coverage gaps
A DAST scan can only test code paths it reaches, so features behind unusual workflows, rare states or authenticated flows that the crawler never completes stay untested. Business logic flaws also need someone who understands what the application should do. Map the workflows your scanner does not complete and decide who covers them, whether a manual tester or a scripted authenticated journey.
False positives in both methods
OWASP lists high false positive rates as a SAST weakness, and tuning a scanner for a noisy codebase takes ongoing effort. DAST also reports findings that do not hold up when a tester reproduces them. A high density of ignored findings signals a problem with the analysis process or tool, not a clean result. Ask each vendor or team how findings are triaged, confirmed and suppressed, and who owns that record.
Where SAST and DAST run in the pipeline
SAST works on code, so it runs as soon as code exists. Teams typically attach it to each commit or pull request, or run a fuller scan in nightly builds and continuous integration. OWASP notes that these tools scale well and can run in those scheduled or automated builds, and that they point to the file and line affected, which lets a developer act on a result without a separate investigation. NIST SA-11(1) makes the same point from the control side: static code analysis is most effective early in development, when each code change can be scanned automatically.
- Trigger: Run on each commit or pull request for fast feedback, and run a deeper scan on a nightly schedule.
- Input: Source or compiled code only, so no running environment is needed.
- Output: File and line references that developers can fix in the same sprint.
- Tuning signal: SA-11(1) states that a high density of ignored findings points to a problem with the analysis process or the tool, so track suppressions as a metric.
- Known gaps: OWASP lists authentication, access control and cryptography issues as hard to find automatically, and notes high false positive rates.
Before relying on a SAST gate, confirm which languages and build systems the tool supports and whether it can analyze code that does not compile in your pipeline.
DAST needs a running application, so it moves downstream. A common pattern is to deploy the build to a staging or pre-production environment and point the scanner at its exposed interfaces. OWASP describes DAST scanners as testing applications normally from the outside, looking for issues such as cross-site scripting, SQL injection, command injection, path traversal and insecure server configuration. Because the scan depends on live responses, its results describe the deployed configuration as well as the code.
- Trigger: Run after deployment to a non-production environment that matches production as closely as practical.
- Input: A reachable URL, valid test accounts and, where needed, an API definition or crawl scope.
- Output: Findings tied to requests and responses, which help reproduce the issue but do not point to a source line.
- Configuration coverage: Server and header settings that SAST cannot see are often found here.
- Test data: Use synthetic data in staging, and confirm the scanner cannot write to live systems or send messages to real users.
Confirm with your platform team that staging uses the same reverse proxy, authentication flow and TLS settings as production, because a DAST result from a different configuration will not describe production.
NIST SA-11(8) describes dynamic code analysis as runtime verification. Tools monitor programs as they run to detect memory corruption, user privilege problems and other security issues. The control counts fuzz testing as a type of dynamic analysis, so feeding malformed or random input to a running build also belongs in this category. This is distinct from DAST as a scanner of web responses, although both observe running software. Dynamic analysis is usually run against instrumented test builds or in dedicated test harnesses rather than against a shared staging system.
- Runtime monitoring: Agents or sanitizers watch memory and privilege behavior while functional or integration tests execute.
- Fuzz testing: Random or malformed input is applied at scale, often in a scheduled job rather than on every commit.
- Build variant: Instrumented builds may run slower and need separate artifacts from release builds.
- Scope: Parsers, protocol handlers and file processing code are common fuzzing targets.
- Overlap: Dynamic analysis and DAST can both report runtime issues, so map each finding to a single owner.
Ask the team whether they have the build flags, test harnesses and CPU budget for runtime monitoring before adding it to a schedule.
Pipeline placement does not end at release. Both tools need to run again when the application, its dependencies or its configuration change, and scheduled scanning covers the gaps between releases. NIST SP 800-115 suggests regularly scheduled scanning interspersed with periodic penetration testing, which places scanners as a recurring activity rather than a one-time gate. CIS Controls Safeguard 18.4 asks for security measures to be validated after each test so that detections cover the techniques testers used, which connects test output to monitoring.
- Schedule: Run DAST on a fixed cadence against production-like environments, and rerun it after significant changes.
- Regression: Keep a suite of previously confirmed findings to check that fixes remain in place.
- Governance: Record who approves scan windows and who may change scanner settings.
- Evidence: Keep dated scan reports, suppression decisions and retest results for assessors.
- Safety: Scanners can disrupt fragile production services, so avoid production scans without written approval.
For your own program, ask how scan results flow into the ticketing system and who closes findings, because an unowned report does not reduce risk.
How NIST SA-11 enhancements map to SAST and DAST
NIST SP 800-53 Rev. 5 control SA-11, Developer Testing and Evaluation, is where SAST and DAST sit in a federal or federally aligned control set. SA-11 is a developer-side requirement, so it asks for testing performed by or for the system developer, and it carries nine enhancements. Two of them map directly to this comparison: SA-11(1), which covers static code analysis, and SA-11(8), which covers dynamic code analysis. A third, SA-11(9), covers interactive application security testing, which sits between the two. Before you cite any enhancement in a control narrative, open the OSCAL catalog for Release 5.2.0 and copy the exact wording. This page only names the enhancements and their titles, and the catalog is the source to check.
The enhancement guidance adds a practical point for SAST. SA-11(1) describes static analysis as most effective early in development, when each code change can be scanned automatically. For your evidence file, that means you should be able to show a pipeline stage that runs on commits, plus a record of how findings are triaged. The same guidance treats a high density of ignored findings as a sign that the analysis process or tool needs attention, so ask any SAST vendor or internal team for their suppression and exception records, not only a count of tool runs. Confirm with your assessor whether they expect that record to cover each application or only the platform-wide ruleset.
SA-11(8) describes dynamic code analysis as runtime verification, with tools that monitor programs for memory corruption, user privilege issues and other security problems. The guidance counts fuzz testing as a form of dynamic analysis, so a DAST-only evidence set may not satisfy the enhancement on its own. Ask which tests run against a deployed build, which environment hosts them, and whether a DAST scan results in a retained report tied to a release. Because SA-11 is a developer obligation, also confirm which party performs each test and whether that party's results flow back to the development team and into the same tracking system.
What you receive from each approach
This table compares the artifacts a SAST engagement and a DAST engagement typically hand over, from raw output to retest evidence. Read the one-time rows as setup you pay for once and the recurring rows as output you should expect every run, then check the statement of work for each.
| Deliverable | SAST (source or compiled code) | DAST (running application) |
|---|---|---|
| Raw tool output | Findings report from the analyzer, typically tied to a file and line number, produced on every scan or nightly build | Scanner report listing URLs, parameters and alert types, produced per scan against a running target |
| Triaged findings | Each alert confirmed or dismissed by an analyst, with the affected file, line and data flow noted | Each alert confirmed or dismissed by an analyst, with the URL, request and response that reproduce it |
| Evidence per finding | Code path or data flow trace, plus the rule or check that fired | Captured HTTP request and response, payload used and observed behavior |
| Triage record | Log of suppressed or accepted false positives with reason and approver, kept in the tool or ticketing system | Log of excluded URLs, accepted alerts and authentication caveats, with reason and approver |
| Remediation list | Tickets mapped to code owners with suggested fixes, often linked to the repository branch | Tickets mapped to endpoints or components, with the expected fix and any configuration change needed |
| Retest evidence | Rescan of the changed code showing the finding no longer fires, or a documented exception | Rerun against the fixed build showing the alert no longer reproduces, with the same payloads |
| Scan configuration record (one-time setup) | Rule set, language coverage, excluded paths, build integration and compilability assumptions | Target scope, authentication method, crawl depth, attack policy and excluded actions such as logout or delete |
| Recurring versus one-time | Raw output and triage repeat on every scan; configuration is set once and revised as code changes | Raw output and triage repeat per scan window; authentication and scope need upkeep as the app changes |
| Confirm in the statement of work | Whether the analyst triage, the rule tuning and the retest are included, and the number of rescans covered | Whether authenticated scanning, manual validation of alerts and retests on fixed builds are included, and who maintains the scan configuration |
Questions buyers ask before hiring help with SAST or DAST
Can our team run SAST and DAST ourselves?
Yes, many teams do, and the open-source tooling is widely used. The harder part is the program around the tools: choosing rules, triaging results, tuning scans to your frameworks, and keeping scans running in every pipeline. OWASP's tool listings separate source code analysis tools from vulnerability scanning tools, so start by confirming which categories your stack needs. Ask whether someone on your team can own triage every week, because an unowned scanner tends to produce a backlog no one reads. A short internal pilot on one application will show the effort more clearly than any estimate.
What drives the effort and time in a fixed-scope SAST or DAST engagement?
The main drivers are the number of applications, their size and language mix, how many user roles and workflows need authenticated testing, and whether the work includes configuration, pipeline integration, triage and handover. Fixed-scope engagements agree deliverables and timelines in writing before work starts, so the scope document is where these drivers are set. Ask for each application, its technology stack, the environments in scope, the number of pipelines to integrate, and the form the final output should take. Any duration you are given should trace back to those written items.
What do we need to provide for a SAST or DAST engagement?
The usual inputs are:
- Source code access, with the branches to scan and build instructions that compile the code
- Test accounts for each role the application supports, so DAST can reach authenticated functions
- A staging environment that mirrors production closely enough to test, with agreed windows for scans
- Named contacts for application owners and pipeline administrators
DAST that runs against production carries more risk than against staging, so confirm the target environment early. Ask the provider to list every input it needs before the scope is signed.
How do we reduce false positives from SAST and DAST?
Start by treating a high density of ignored findings as a signal that the analysis process or tool needs tuning, which is the point NIST makes in its guidance on SA-11(1). Tune rules to your frameworks, suppress findings only with a recorded reason, and separate findings by file or route so developers can act on them. For DAST, scope the crawl to the right hosts and provide authenticated sessions so the scanner reaches real code paths. Ask any provider to show its triage method and how suppressions are reviewed, because accuracy depends on that work as much as on the tool.
Can DAST replace a penetration test?
No. PCI SSC's Penetration Testing Guidance describes penetration testing as essentially a manual process and states that simply running an automated tool does not satisfy the penetration testing requirement. DAST finds classes of issues such as cross-site scripting and SQL injection, but it does not reason about business logic or complex access control the way a tester does. OWASP's Web Security Testing Guide also says no single technique is enough. Treat DAST as recurring automated coverage and a penetration test as a separate, tester-led exercise. Confirm the exact requirement with your assessor or the standard's owner.
What does a quote for SAST or DAST services actually cover?
A quote follows from the written scope, not from a standard price list. DeployOpen does not publish a price list. Expect the quote to break out the planning, the setup and integration work, any tuning and triage, the handover documentation, and any recurring support or testing retainer as a separate line. Ask whether each item is one-time or recurring, what is excluded, and which deliverables trigger completion. Ask for the scope and assumptions in writing so you can compare quotes on equal terms.
Which SA-11 enhancements should a scoped engagement reference?
A useful scope names the SA-11 enhancements it supports. SA-11(1) covers static code analysis, SA-11(8) covers dynamic code analysis such as runtime monitoring and fuzz testing, and SA-11(9) covers interactive application security testing. NIST's SA-11 catalog lists nine enhancements in total, so ask a provider which ones the work addresses and how each produces evidence. If your obligation comes from a federal or contractual baseline, confirm with your authorizing official which enhancements apply to your system.
What drives cost and effort for each approach
SAST and DAST are priced and staffed differently, but both costs follow the same pattern: tool or service fees, setup work, and the human time spent deciding what a finding means. The cards below separate what drives each approach, what is shared, and what is one-time versus recurring, so a quote can be compared on the same terms.
SAST drivers
SAST effort scales with the languages in scope, the size of the codebase, and how deeply the scanner is wired into the build. Teams that run it on every commit pay mostly in setup and rule tuning. The largest recurring cost is often triage: false positives are high, so someone must confirm each alert before it reaches a developer. Ask any vendor or partner how many languages and build systems the quote covers.
DAST drivers
DAST effort grows with the number of applications and APIs, the complexity of login flows, and the depth of each scan. Authenticated scanning of multi-step sessions usually needs scripted configuration per application. Scans also need a staging environment that resembles production, or results describe a system that never ships. Confirm whether the quote includes that environment and who maintains it.
Shared triage and tuning
Both approaches produce findings that need an owner, and tuning decides whether the output is used. Suppressing noise, mapping findings to real code paths or URLs, and agreeing on severity are ongoing tasks. NIST treats a high density of ignored findings as a sign that the analysis process or tool needs attention. Ask who signs off on suppressions and how that decision is recorded.
Ownership and retest cycles
Someone must own each tool, its configuration, and the retest after a fix. When developers own the pipeline, retest happens within normal sprint work. When a partner owns it, retest is usually a separate scoped task. Clarify in the statement of work who reruns scans after remediation, how many retest rounds are included, and whether retests are billed separately.
One-time versus recurring costs
Setup work, such as pipeline integration, scan authentication, and baseline tuning, is largely one-time. Licenses or subscriptions, scan infrastructure, triage hours, and periodic reviews recur. Open-source engines remove license fees, but not the engineering time to run them. Ask every quote to split setup, licensing, and ongoing support into separate lines so the recurring total is visible.
Which combination a team with one application should start with
For a single application with limited AppSec staff, start with SAST in the build pipeline because it is the earliest point at which flaws are cheap to fix. Run the static analyzer on every change so developers see findings against the file and line they touched. This is an illustrative path, not a prescription: choose the rule sets and failure thresholds with the team that will triage the output, and confirm with each vendor whether the tool handles the languages and build system your application uses. OWASP notes that SAST struggles with code that cannot be compiled and misses most authentication, access control and configuration issues, so the first pipeline is not the finish line.
Once the application runs in staging, add DAST against that environment, not production. Point the scanner at a non-production instance with test accounts, and configure authentication so it reaches logged-in pages, since an unauthenticated crawl covers little of a typical application. The scanner will catch issues such as cross-site scripting and injection in the running system that SAST can miss. Track ignored findings from both tools as a tuning signal: NIST SA-11(1) guidance says a high density of ignored findings points to a problem with the analysis process or the tool, so review suppressions each sprint and confirm that rules are tuned to the application.
Then schedule a tester-led penetration test to cover business logic and access control, the areas both automated tools handle poorly. Its scope should draw on the SAST and DAST results, and the team should confirm the test cadence with its auditors or contract owners. CIS Controls v8.1 Safeguards 18.2 and 18.5 ask for external and internal penetration tests at least annually, and Safeguard 18.4 asks that security measures be validated after each test so detections cover the techniques the testers used. Ask the testing provider how findings will feed back into the SAST rules and DAST scan configuration.
When compliance frameworks call for each method
This sequence shows how a team moves from knowing which frameworks apply to holding evidence that static and dynamic testing, plus tester-led work, meet each obligation. Each step ends with an artifact an assessor can review.
Confirm which frameworks apply
Start by listing the regulations, contractual standards and certification schemes that cover the application and its data. Ask your regulator, assessor or qualified security assessor to confirm applicability in writing, because the obligations differ by sector, entity type and the role the system plays. Record each framework with its named owner. The output is a scoped register that tells the team which testing requirements it must meet.
Map each obligation to a testing method
For each framework, note the testing types it names. DORA Article 25(1) lists vulnerability assessments and scans, open source analyses, source code reviews where feasible, scenario-based tests and penetration testing. PCI SSC's penetration testing guidance treats the test as essentially manual work. CIS Controls v8.1 Safeguards 18.2 and 18.5 call for external and internal penetration tests at least annually. The output is a matrix linking each requirement to a static, dynamic or tester-led control.
Check whether automation alone satisfies the requirement
Verify whether each requirement accepts automated tools or needs human testing. PCI SSC states that simply running an automated tool does not satisfy the penetration testing requirement, so a DAST scan cannot stand in for the penetration test. SAST and DAST pipeline results count as evidence of ongoing scanning, but they do not replace a tester-led engagement. Confirm this reading with your assessor. The output is a note per requirement stating whether automated results are sufficient.
Schedule static and dynamic scanning in the pipeline
Configure SAST to run on each code change and DAST against a staging build on a fixed cadence. Your pipeline produces the scan logs, configuration files and build identifiers that show when testing ran and what it covered. Record which rules are enabled and which findings are suppressed, since a high density of ignored findings signals a problem with the analysis process. The output is a pipeline evidence folder that ties every scan to a specific build.
Plan penetration and threat-led tests
Book tester-led work on the schedule your frameworks set. Under DORA Article 26, threat-led penetration testing is required at least every 3 years for entities their competent authority identifies, so confirm whether that applies to you. For CIS Safeguard 18.2 and 18.5, plan external and internal tests at least annually. Agree the scope, rules of engagement and deliverables in writing before testing begins. The output is a signed statement of work that names the frameworks each test supports.
Validate detections after each test
After each penetration test, check that your monitoring and pipeline rules catch the techniques the testers used. CIS Safeguard 18.4 expects security measures to be validated after each test so detections cover those techniques. Where a tester exploited a flaw that SAST or DAST missed, add a rule, adjust the scan configuration or open a tracked change. The output is a retest or validation record showing which findings now trigger alerts or scan failures.
Assemble the evidence package for assessors
Gather the framework register, the requirement matrix, pipeline logs, signed scopes, test reports and validation records into one package organized by requirement. DeployOpen can prepare systems, controls and evidence for a compliance assessment, but independent auditors and certification bodies issue any report or attestation. Confirm with your assessor which formats and retention periods they expect. The output is an indexed evidence set that lets an assessor trace each requirement to its proof.
How DeployOpen scopes, delivers and supports SAST and DAST programs
DeployOpen plans, implements, integrates, documents and supports self-hosted open-source testing tooling inside your own infrastructure, so scanners run where your code and environments already live. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How we scope
- Written scope names the applications, branches, repositories and language stacks that static analysis will cover.
- Scope defines which running environments dynamic scanning may target, such as staging, with authentication details agreed up front.
- Written scope records which findings triage, suppression rules and ownership responsibilities sit with your team versus DeployOpen.
How we build
- We integrate static analysis into your CI pipeline so each code change is scanned automatically, with results routed to the file and line affected.
- We configure dynamic scanning against a non-production target and tune authentication, crawl depth and exclusions for your application.
- We tune rule sets to reduce false positives and track ignored findings, since a high density of ignored findings signals a process problem.
How we hand over
- Deliverables include pipeline configuration, scanner settings and runbooks documenting how each tool is run and maintained.
- We document which SAST and DAST findings were triaged, which were accepted as risk, and the evidence behind each decision.
- Handover sessions walk your engineers through triage workflow so they can operate the program after the engagement closes.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers once the initial program is in place.
- Retainers can cover scanner version upgrades, rule updates and reviews of new applications added to the pipeline.
- Confirm with us during scoping which support window, response expectations and reporting cadence your retainer will include.
