SAST vs DAST vs IAST: which one a team with one application should start with
A team with one application and no AppSec staff should start with static analysis (SAST) in the build pipeline, then add dynamic scanning (DAST) against a staging copy once the application runs there. SAST reads code the team already owns, reports the file and line affected, and can run on every commit with little tuning. DAST probes the running application from outside for issues such as cross-site scripting, SQL injection and insecure server configuration. IAST, which watches the application from inside while tests run, usually needs an agent built for your language and framework and more setup, so it rarely makes sense as a first tool for a small team. Start with the tool that matches your deployment and your compliance question, not the one with the longest feature list.
Three points from NIST SP 800-53 shape that choice. SA-11 Developer Testing and Evaluation lists static code analysis, dynamic code analysis and interactive application security testing as enhancements, but SP 800-53B does not select any of them in any baseline. The requirement therefore comes from your own risk assessment, contracts and regulators, so confirm with the customer or assessor which testing evidence they expect. NIST's guidance on SA-11(1) also notes that a high density of ignored findings signals a problem with the analysis process or tool, so budget time for triage in the first months. Expect to tune the scanner, not just run it. The OWASP ASVS 5.0.0 requirements on business logic and access control cannot be fully verified by either tool, so plan for a manual review or a penetration test of those areas.
Combine the tools once the first pass is stable. A practical sequence is SAST on every merge, DAST on a schedule against staging, and a targeted manual test before a major release or a customer audit. IAST becomes worth evaluating when the team has a supported agent for its stack, a staging environment that exercises real flows, and someone to triage results. Ask any vendor or DeployOpen for a written scope that names the languages, the pipeline stages and the evidence you will receive. Confirm with your assessor whether they accept a SAST report alone or expect dynamic testing as well.
How the three approaches compare on scope, method and deliverables
This table sets SAST, DAST and IAST side by side on goal, input, where they run, skill needed, findings, blind spots and the NIST SA-11 enhancement each maps to. Read it to match a method to the code, environment and triage capacity you actually have.
| Dimension | SAST | DAST | IAST |
|---|---|---|---|
| Primary goal | Find security flaws in source or compiled code before or as it is built | Find flaws in a running application by testing it from the outside | Find flaws by observing the application from inside while tests or users exercise it |
| Input needed | Source code or compiled code with build access | A running test instance and its URLs or API definitions | An instrumentation agent deployed into the running application, plus test traffic |
| Where it runs | Nightly builds or continuous integration, per the OWASP source code tooling guidance | Staging or test environments, normally from the outside | Test and staging environments where the agent can be installed; confirm production use with the vendor |
| Skill needed to run and triage | Developers can read results with file and line references; AppSec staff help tune rules | Security or QA staff configure authentication and scope; developers fix confirmed issues | Developers and platform staff install agents; triage needs knowledge of the framework and libraries in use |
| What it finds | Flaw patterns such as buffer overflows and SQL injection, with file and line affected | Cross-site scripting, SQL injection, command injection, path traversal and insecure server configuration | Runtime-observed flaws in code paths the tests reach, with data flow context; confirm the coverage for your languages with the vendor |
| What it misses | Authentication, access control and cryptography issues are hard to find automatically; configuration issues are often missed | Flaws in code paths the crawler or test scripts never reach, and issues that need business context | Code paths no test or user exercises, and anything outside the instrumented runtime |
| False positive pattern | High false positive rates are noted by OWASP; a high density of ignored findings signals a tuning problem | Findings depend on response patterns, so noisy results often come from weak scope or authentication setup | Usually fewer false positives than static tools when the agent sees the flow, but accuracy depends on test coverage; confirm with the vendor |
| Typical deliverable | Scan report listing rule, file, line and severity, ideally filtered in the build | Scan report listing URL, parameter, evidence and risk, with the scan configuration recorded | Runtime findings linked to the code path and request that triggered them |
| NIST SA-11 enhancement it maps to | SA-11(1) static code analysis | SA-11(8) dynamic code analysis | SA-11(9) interactive application security testing |
| Standalone sufficiency | Not enough alone; OWASP ASVS notes that automated tools cannot fully verify access control or business logic | Not enough alone for access control or business logic; a tester-led review still adds value | Depends on test coverage, so it complements rather than replaces the other two |
What SAST, DAST and IAST find and miss
Each testing method sees a different slice of the application, and each has blind spots that matter for access control, business logic and configuration. The cards below set out what each method finds, what it misses, and the process signals that show whether the tooling is working.
SAST scales and catches flaws early
SAST tools examine source or compiled code, so they can run in nightly builds or on every commit and point to the file and line affected. Because they work before deployment, a finding costs less to fix than one raised in production. For a single application, check that the scan runs automatically on each change, not only before a release, and that developers receive results in the tool they already use.
SAST misses authentication and access control
OWASP lists authentication, access control and cryptography issues as hard to find automatically, and notes that only a small percentage of flaws are found this way. Configuration issues are often missed as well. Expect SAST to confirm that code uses a pattern correctly, not that the logic behind a login or permission check is sound, and plan a human review for those areas.
SAST false positives need a triage owner
OWASP reports high false positive rates for SAST. Left unmanaged, a noisy scanner trains developers to dismiss its output. NIST SA-11(1) treats a high density of ignored findings as a sign that the analysis process or the tool needs attention. Before turning on blocking rules, name one person to review suppressions and record why each finding was dismissed.
DAST finds runtime and server configuration issues
DAST scanners test a running application, usually from the outside, for cross-site scripting, SQL injection, command injection, path traversal and insecure server configuration. They need no source access, which makes them useful when code is outsourced or hard to build. Open-source options such as OWASP ZAP are licensed under Apache-2.0. Check that the scanner authenticates to the application, since unauthenticated scans miss most of the features users reach after login.
DAST cannot see code or business logic
A DAST scanner reports the URL or request where a problem appears, but not the line of code that causes it. OWASP ASVS 5.0.0 states that automated DAST and SAST tools cannot fully verify many requirements, especially those on business logic and access control. A scanner can confirm that a discount field accepts a negative value only if the test case anticipates that abuse. Plan manual test cases for workflows that handle money, roles and approvals.
IAST depends on language and framework support
IAST, described in NIST SA-11(9), watches the application from inside while tests run, using access to code, libraries, frameworks and backend connections. That view can improve accuracy, but only where an agent supports the application's language, framework and runtime. Before adopting IAST, confirm that the vendor or open-source agent covers every stack in your application, and that the instrumentation can run in test or staging environments without slowing the pipeline beyond what your team accepts.
Why false positives pile up and how to keep triage workable
False positives build up for different reasons in each approach, and the pattern matters because it tells you what to fix. SAST reports flaws from code patterns without knowing whether the input can reach the sink at runtime, so it flags code that is unreachable or already sanitized. DAST sends payloads and reads responses, so it can misread error pages, generic 200 responses or reflected content as vulnerabilities, and it often misses configuration issues it cannot see from outside. IAST reports from inside the running application, which usually makes its findings more precise, but its noise comes from instrumentation gaps, unsupported frameworks and test traffic that never reflects real user paths. Expect the largest volume from SAST on a first scan, and expect DAST results to need replay evidence before anyone acts on them.
NIST SA-11(1) treats a high density of ignored findings as a signal that the analysis process or the tool is wrong, not as a backlog to close. When developers routinely mark findings as not applicable, the rule set, scan scope or configuration needs review. Track the ratio of suppressed to confirmed findings per rule, and retire or tune rules that are suppressed repeatedly. Confirm with your tool vendor how rule sets are versioned and how suppressions are stored, since a suppression that disappears after an upgrade will resurface old noise.
Before the first scan, a small team should make three decisions in writing. First, decide which rules block a build. A short list of high-confidence rules, such as hard-coded credentials or known injection sinks, is workable; everything else should report without blocking. Second, name one owner for triage, with a backup, and set a review cadence so findings do not age unseen. Third, define how an exception is recorded: who approves it, the finding identifier, the reason, the compensating control and an expiry date. An exception without an expiry is a permanent blind spot. Ask your tool provider and your test partner to show how these records export for audit evidence.
Which combination a team with one application should start with
This sequence gives a single application with no AppSec staff a layered, low-noise testing program that starts early in development and adds depth where automated tools run out. It produces a repeatable pipeline gate, a scheduled staging scan, and a planned human review for the flaws tools cannot judge.
Turn on SAST in continuous integration for the main branch
Start with a static analysis tool that runs on every change to the main branch, since NIST SA-11(1) guidance says static analysis works best early in development when each code change can be scanned automatically. The development team owns the setup, using a narrow, deliberately chosen rule set so that only high-confidence findings can block a merge. Each reported finding points to a file and line, which lets developers fix issues before the code reaches a shared environment. The step is done when a deliberately seeded test flaw fails the build, and the team has a written list of which rules block and which only report.
Triage the first SAST results and tune the rules
Review the initial findings with the developers who wrote the code, classify each as a true issue, a false positive, or an accepted risk, and record the decision in the tool or a shared log. OWASP notes that SAST produces many false positives and misses configuration issues, so expect noise in the first weeks. NIST SA-11(1) guidance treats a high density of ignored findings as a sign that the analysis process or tool needs attention, so a rising ignore count is a signal to tune rules, not to accept more risk. The step is done when the blocking rule set produces findings the team acts on and the ignore rate has been reviewed.
Deploy the application to a staging environment
Build a staging deployment that mirrors production configuration closely enough for a dynamic scan to be meaningful, including authentication, database connections, and the same web server and TLS settings. The operations or platform team usually owns this, and the cost is mostly the hosting and the time to keep staging current. Without a running staging target, DAST has nothing to test, so this step is a prerequisite rather than optional. The step is done when a tester can log in to staging with test accounts and the team has documented how the environment differs from production.
Schedule DAST scans against staging
Add an open-source dynamic scanner such as OWASP ZAP, which is listed under the Apache-2.0 license, and run it against staging on a fixed schedule and after significant releases. DAST tests from the outside for issues such as cross-site scripting, SQL injection, command injection, path traversal, and insecure server configuration, so it complements the code-level view from SAST. Configure authenticated scans with test accounts so that pages behind login are covered. The step is done when scheduled scans run without manual starting, the results go to a named owner, and the team has confirmed which findings are verified against staging.
Decide whether IAST fits the stack
Before adding instrumentation-based testing, check two conditions: the application's language and framework must be supported by the IAST product, and the staging environment must be able to host the agent without destabilizing the application. NIST SA-11(9) describes IAST as observing the application as it runs during testing, using access to code, libraries, frameworks, and backend connections, so it needs an agent inside the runtime. If either condition fails, record that IAST is deferred and continue with SAST and DAST. The step is done when the team has a written yes or no decision, with the supported versions confirmed with the vendor and the staging owner's agreement on the agent.
Plan a scoped human review for access control and logic
Add a manual review step, either a penetration test or an ASVS-led review, scoped to access control, authorization rules, and business logic. OWASP ASVS 5.0.0 states that automated DAST and SAST tools cannot fully verify many requirements, especially those on business logic and access control, so this step covers the gap that the earlier tools leave. OWASP WSTG says no single technique is enough and recommends a mix that puts more weight on early development phases, which is why the human review should be fed by the threat model and the SAST and DAST findings rather than run cold. Ask providers to confirm their method, the tester qualifications they use, and how they report on each ASVS requirement tested. The step is done when a written statement of work names the scope, deliverables, and retest criteria.
Feed review results back into the pipeline
Convert each confirmed finding from the human review and the scanners into a regression check where possible, such as a unit test, a new SAST rule, or a DAST test case, so the same flaw does not return in a later release. NIST SP 800-115 notes that organizations often combine techniques to reach an in-depth assessment at an acceptable level of risk, and this loop is how the combination improves over time. Keep a short register of open findings with owners and due dates set by the team's own policy. The step is done when the next release's pipeline run includes at least one new check that came from a human-reviewed finding, and the register is reviewed on a regular cadence.
When compliance frameworks call for each approach
No single framework tells you to buy SAST, DAST or IAST by name. What the supplied frameworks do is list testing types and leave the choice to you, so the first job is to confirm which requirements apply to your organization and application. DORA Article 25(1) lists tests that include open source analyses and source code reviews where feasible, alongside vulnerability scans and penetration testing. If you are an EU financial entity, ask your competent authority or compliance lead whether those tests are expected for this application and how they will judge "where feasible." Source code review is the item most likely to need a documented justification if you skip it.
PCI SSC's penetration testing guidance says that running an automated tool does not on its own satisfy a penetration testing requirement, so DAST output alone will not close that item. Plan for a tester-led exercise on top of any scanner. Separately, CIS Safeguard 18.4 asks that security measures be validated after each test so that detections cover the techniques testers used. In practice, this means a DAST or IAST finding that leads to a fix should be followed by a check that the fix holds and that monitoring would notice the technique. Confirm with your assessor whether they expect that evidence in the form of retest records, pipeline logs or both.
NIST SP 800-53B selects SA-11 Developer Testing and Evaluation in the moderate and high baselines, but it does not select any of SA-11's enhancements, including static code analysis, dynamic code analysis and interactive application security testing, in any baseline. For a federal or contractor system, that means the control obligation is to test, while the choice of technique is yours to document. Ask your authorizing official or contracting officer whether they want a named tool class in the system security plan, and record the reasons for the combination you pick. Treat the enhancement list as a menu you justify against your risk, not a checklist you must fully tick.
What drives cost and effort for each approach
Cost for SAST, DAST and IAST rarely comes from the license line alone. It comes from who configures the tools, who triages their output, and who verifies what they miss. The cards below separate those components so you can ask vendors and DeployOpen for a written scope that prices each one.
Tool licensing versus open-source tooling
Commercial SAST, DAST and IAST products are usually licensed per application, per developer or per scan volume, and the terms are set by the vendor. Open-source options change the line item but not the work: OWASP ZAP is licensed under Apache-2.0, so the tool itself carries no license fee, while staff time, hosting and support still do. Ask whether the quote covers licenses, hosting, updates and vendor support separately, and who owns the rule tuning.
Setup and CI integration effort
SAST runs against source or compiled code, so its setup is mostly build access, a scanner configuration and a decision about which findings block a merge. OWASP notes that SAST tools scale well and can run in nightly builds or continuous integration. DAST and IAST need a running application to test, so their setup is heavier. Ask who wires the scanner into the pipeline, who maintains that job when the build changes, and whether the quote includes the first full tuning pass.
Staging environment and test data
DAST scanners test from the outside and need a deployed instance that is safe to attack, with working logins, seeded data and reachable backends. Many teams underestimate this. A staging environment that is not production-like produces scans that miss flaws in real routes and configurations. Ask who provisions and refreshes the environment, who owns the synthetic data, and what happens to the environment cost if the scan runs on every build.
Language and framework coverage for IAST
IAST reads the application from inside while tests run, so it depends on an agent that supports your language runtime, framework and version. Coverage gaps appear as blind spots, and the effort to close them can be significant. Before you compare prices, confirm in writing which languages, frameworks and deployment types the product supports for your application, and who installs and maintains the agent in each environment.
Triage time for false positives
OWASP lists high false positive rates as a known SAST weakness, and NIST SA-11(1) guidance notes that a high density of ignored findings signals a problem with the analysis process or tool. Triage is recurring labor that scales with scan volume and codebase size. Ask for a baseline of expected findings from a pilot, the rule set used, and who suppresses, justifies and rechecks each finding over time.
Cost of a tester-led follow-up
Automated tools do not verify access control, business logic or many authentication flows, and OWASP ASVS 5.0.0 says automated DAST and SAST tools cannot fully verify many of these requirements. A follow-up manual review or penetration test is a separate, scoped purchase with its own deliverables and timing. Ask whether the quote lists which requirements the follow-up covers, whether retesting after fixes is included, and whether it is fixed-scope or a retainer.
Questions buyers ask before hiring outside help on SAST, DAST or IAST
How much effort does a first SAST or DAST setup take, and what drives it?
The effort depends on the application's language and framework, how many repositories and build pipelines are involved, and how many environments need scanning. The first setup usually includes choosing tools, wiring them into the build or a staging job, tuning rules, and triaging the first results, which tends to be the largest chunk. Ask any provider to break the quote into those steps, to state which environments and repositories are in scope, and to say who configures credentials and test accounts. No fixed duration is supplied for this work, so agree the timeline in writing against the written scope before work starts.
Can our own team run SAST and DAST without outside help?
Often yes for the tooling itself. OWASP describes SAST tools as scaling well and running in nightly builds or continuous integration, and it lists OWASP ZAP as an open source DAST scanner under Apache-2.0. The harder part is judgment: deciding which findings are real, which are false positives, and which need a developer fix. The OWASP ASVS 5.0.0 guidance states that automated SAST and DAST cannot fully verify many requirements, especially business logic and access control, so a team with one application and no AppSec staff should plan for a named owner who reviews results on a regular cadence.
What does a consultant do that the scanners do not?
A consultant can read the design, the code paths and the business rules, then test the things scanners miss. OWASP lists authentication, access control and cryptography issues as hard to find automatically, and notes that configuration issues are often missed by SAST. A tester can check whether one user can see another user's records, whether a workflow can be skipped, and whether a control is applied consistently. Ask the provider which ASVS or WSTG areas they will cover by hand, how findings are validated before they reach your developers, and how retests are handled.
How long before the scanning results become useful?
Useful results usually arrive after the first scan has been triaged, not when the scan finishes. The time depends on application size, how many scan targets exist, how many findings the first run produces, and how quickly developers and staging owners can respond. Because scope drives this directly, the timeline should be stated in the written scope and agreed before work begins. Ask the provider to show what an initial report contains, how they separate confirmed issues from noise, and what happens if the first run turns up a large backlog.
What does the work need from developers and staging owners?
The work needs developers to fix confirmed issues and to review findings that touch their code, and it needs staging owners to provide a non-production environment that matches production closely enough for DAST to be meaningful. For DAST, you will usually need test accounts with different roles, seeded data that the scanner can change safely, and an agreed window when scans can run. For SAST, you need read access to the repositories and a build job where scans can run. Ask for a written list of these dependencies before the engagement starts, since a missing staging environment is a common reason DAST work stalls.
Is IAST worth it for a single application?
It can be, but for one application it is often a later step. IAST works by watching the application from inside while tests run, which requires an agent or instrumentation in the running application. NIST SA-11(9) describes this as using access to code, user interaction, libraries, frameworks, backend connections and configurations. That gives good visibility but adds deployment work and depends on the language and framework being supported. Start with SAST and DAST, then consider IAST once a team can run it in a staging environment and has someone to maintain the instrumentation.
How do we check a SAST or DAST vendor's claims?
Ask for evidence rather than accepting a headline detection rate. Request the list of vulnerability classes covered, the languages and frameworks tested, and a sample report from a comparable application. Check whether the vendor says how false positives are reduced and how many ignored findings the tool produces, since NIST SA-11(1) guidance notes that a high density of ignored findings signals a problem with the analysis process or tool. Run a time-boxed proof of concept against a known vulnerable test application you control, and compare the results against your own findings rather than against the vendor's marketing.
What a fixed-scope AppSec testing engagement covers
If you are choosing between SAST, DAST and IAST for one application, the first decision is not the tool but the scope you will sign for. DeployOpen plans, implements and supports these tests inside your own infrastructure, whether that is your cloud accounts, data center or an air-gapped network, so the scanners, the CI runners, the staging environment and the findings all stay under your control. Before any work starts, confirm in writing which components are in scope: the repository or build pipeline that feeds the static analysis, the staging URL and authenticated test accounts that the dynamic scanner will use, and whether instrumentation will be added to a test build of the application for IAST.
Most engagements are fixed-scope, meaning the scope, deliverables and timelines are agreed in writing before work begins. For this topic, a useful statement of work names the languages and frameworks covered, the triage process for findings, the settings that will be tuned to reduce false positives, the pipeline gates that will block or only report, and the format of the evidence delivered. Ask for each deliverable to be listed as a separate item so you can see what is handed over at closure and what is still open. DeployOpen does not publish a price list, so a quote follows from this written scope, and the scope is what drives the effort.
Tuning does not end at closure. Running SAST and DAST well means someone reviews ignored findings, updates suppression rules when the code changes and re-runs scans after new releases, and that work recurs. DeployOpen offers ongoing support and continuous testing as retainers, which is the usual route when you want those tasks maintained after the initial implementation. DeployOpen prepares systems, controls and scan records that can support a compliance assessment, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations, so confirm early which evidence your assessor will accept.
How DeployOpen scopes, delivers and supports SAST, DAST and IAST
DeployOpen plans, implements, integrates, documents and supports self-hosted open-source platforms inside the client's own infrastructure, and runs application security testing as part of that work. For SAST, DAST and IAST, we agree the scope in writing first, then set up the tools, tune them against your application and hand over the results and the process to your team.
How we scope
- Written scope names the applications, repositories, environments and pipelines covered by each testing method.
- We record which SA-11 enhancements the agreed testing is meant to address, so expectations are clear from the start.
- The scope states which parts need manual review, such as access control and business logic, and which stay out of automated coverage.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before any work begins.
How we build
- We install and configure SAST, DAST or IAST tooling inside your cloud accounts, data centers or air-gapped networks.
- Static analysis is wired into your build pipeline so scans run on defined triggers rather than by hand.
- Dynamic scans run against a staging target that you control, with authentication and test data set up as the scope requires.
- We triage early findings with your developers to tune rules and suppress confirmed false positives with documented reasons.
How we hand over
- You receive configuration files, pipeline definitions and run instructions stored in your own version control.
- Documentation records what each tool covers, what it misses, and which findings were reviewed and why.
- We walk your engineers through triage so they can classify new findings and recognize high-volume ignored-finding patterns.
- Handover covers the manual review items that automated tools cannot verify, with a list of who owns each one.
How we support
- Ongoing support, tool upgrades and continuous testing are available as retainers after the initial handover.
- A retainer can cover rule tuning as the codebase changes and as new releases of the tools are adopted.
- Ask any quote to state who maintains the pipeline integration, who triages new findings and who approves suppressions.
- Support scope, response expectations and upgrade responsibilities should be written into the agreement before work starts.
