# SAST vs DAST: what each finds, what both miss, and where a pentest fits

Source: https://penetrationtestservices.com/guides/sast-vs-dast/
Publisher: Excession Labs (penetrationtestservices.com)
Last updated: 2026-11-09

SAST vs DAST in one table: what each method reads, when it runs, what it finds, what both miss (access control, business logic) and where a pentest fits.

> **Short answer:** SAST (static application security testing) reads source code without running it. DAST (dynamic application security testing) attacks a running application from outside, with no source code. SAST finds known code patterns early. DAST finds flaws that appear at run time. Both miss most broken access control and business logic flaws, which a penetration test with several accounts is built to find.

SAST vs DAST is a question about where a test looks. SAST, static application security testing, reads your source code without running it. DAST, dynamic application security testing, sends requests to a running application and watches how it responds. Each finds issues the other cannot see, and both miss a class of flaws that needs two user accounts to prove.

## SAST vs DAST in one table

The two methods differ in what they read, when they run and what they report.

| | SAST | DAST |
|---|---|---|
| Needs | Source code (often a build) | A running application and its URL |
| Runs | While code is written or built, in CI | Against a deployed test or staging app, for example nightly |
| Sees | Code, with file and line number | Requests and responses, as an outside caller |
| Finds well | Known unsafe code patterns such as SQL injection sinks | Input and output validation, authentication issues, server configuration mistakes |
| Misses | Configuration that is not in the code, most access control logic | Code paths the scanner never reaches, logic it cannot judge |
| Output | A list with exact code locations, often with false positives | A list of issues reproduced against the live app |
| Proof of impact | Not shown: you must show the issue is real | Partial: the payload worked, but the business impact is not judged |

OWASP describes DAST as a "black-box" method that finds weaknesses "in a running application" and works "without needing the source code" ([OWASP DevSecOps Guideline](https://owasp.org/www-project-devsecops-guideline/latest/02b-Dynamic-Application-Security-Testing)). Its list of areas where DAST helps most is input or output validation, authentication issues and server configuration mistakes. For SAST, see the next section.

## What does SAST do, and where does it stop?

SAST analyzes code at rest and points at the line that looks unsafe. It runs on every commit or build, so a developer sees the issue before the code ships.

OWASP's page on source code analysis tools lists what they are good at: finding "certain well-known vulnerabilities" such as buffer overflows and SQL injection flaws, pinpointing them "by filename, location, line number", and running repeatedly on a lot of software ([OWASP Source Code Analysis Tools](https://owasp.org/www-community/Source_Code_Analysis_Tools)).

The same page lists the limits. SAST tools find "only a relatively small percentage of application security flaws". They produce "high numbers of false positives". They are "frequently unable to find configuration issues, since they are not represented in the code". It is "difficult to 'prove' that an identified security issue is an actual vulnerability". Authentication problems and access control issues are on its list of hard-to-automate categories.

In practice this means a SAST report needs triage. A person reads each finding, decides whether untrusted input really reaches the flagged line, and closes the rest. Teams that skip triage learn to ignore the tool.

## What does DAST do, and where does it stop?

DAST attacks the deployed application the way an outside caller would. It crawls pages or reads an API description, injects payloads into inputs, and reports responses that show a flaw.

Because it needs no source code, it works on any web app you are allowed to test, including a vendor product or a legacy system. It sees what is actually deployed: the web server settings, headers, cookies and the behavior of the real framework. OWASP notes that these tools can run as part of a nightly scan and need little interaction once configured.

DAST stops where its crawl stops. It only tests pages and endpoints it can reach. A feature behind a multi-step flow, a role it has no account for, or an endpoint that is not linked anywhere can go untested. Authenticated scanning needs login steps that you must set up and keep working.

DAST also reports what it can recognize. A payload that reflects in a response is a signal it knows. Whether a refund endpoint lets a user refund the same order twice is a rule only your team knows.

## What do neither SAST nor DAST find?

Broken access control and business logic flaws are the two big gaps. Both depend on who the caller is and what your application is supposed to allow, which a scanner cannot know.

Take object-level authorization. OWASP API1:2023 says attackers exploit it "by manipulating the ID of an object that is sent within the request" ([API1:2023](https://owasp.org/API-Security/editions/2023/en/0xa1-broken-object-level-authorization/)). Each request in such an attack looks normal: a valid token and an existing ID. The flaw only shows when you compare two accounts. The [IDOR testing guide](/guides/idor-testing/) shows how testers prove it.

> **Demonstration only:** This is a demonstration. No real customer system was tested. "Harbor Notes" is a fictional app.
> 
> A DAST scan of Harbor Notes requests `GET /api/notes/4021` with Alice's token and gets a 200. It requests the same URL with no token and gets a 401. Both responses look correct to the scanner. A tester then requests note 4021 with Bob's token and gets Alice's note. The tool had no rule that said note 4021 belongs to Alice, so it had nothing to compare.
Business logic is the same problem with a different shape. The OWASP Web Security Testing Guide has a whole section on it, with tests for data validation, forged requests, integrity checks, process timing, the number of times a function can be used, and workflow circumvention ([WSTG, business logic testing](https://wstg.owasp.org/latest/)). See [business logic vulnerabilities](/guides/business-logic-vulnerabilities/) for examples and how to test them.

Multi-tenant platforms add a third gap: tenant isolation. Proving that tenant A cannot see tenant B's data needs accounts in both tenants. Read [multi-tenant isolation testing](/guides/multi-tenant-isolation-testing/).

## Which should you pick? A decision table by situation

Pick the method that fits what you hold and what you need to prove. This table maps common situations to a starting point.

| Your situation | Start with | Add next | Why |
|---|---|---|---|
| You write the code and ship often | SAST in CI | DAST on staging | Fast feedback on code, then a check of the deployed app |
| You have no source access (vendor or legacy app) | DAST | A penetration test | DAST is the only automated option, and a pentest covers logic |
| Small team, no security staff | DAST on staging, with a short triage rule | A pentest before launch | Low setup cost, and a person checks what tools miss |
| API only, no UI | DAST with an API description | A pentest with two roles | DAST needs the endpoint list, and authorization needs two sessions |
| Multi-tenant SaaS | SAST and DAST as hygiene | A pentest focused on tenant isolation | Neither tool compares tenants |
| A customer or standard asks for a pentest | A penetration test | Keep SAST and DAST running | A scan report does not meet a request for a pentest |

The last row needs care. Some standards name penetration testing in their text and some accept scans for other controls. Read the exact wording in [PCI DSS penetration testing requirements](/guides/pci-dss-penetration-testing-requirements/) and ask your auditor.

## How do IAST and SCA fit in?

IAST and SCA are two related methods, and most teams meet them as add-ons to SAST and DAST.

IAST, interactive application security testing, watches the application from the inside while something exercises it. OWASP defines it as testing "while the app is run by an automated test, human tester" or another activity that interacts with the app ([OWASP DevSecOps Guideline](https://owasp.org/www-project-devsecops-guideline/latest/02c-Interactive-Application-Security-Testing)). It needs an agent inside the app, and it only sees code paths that a test actually runs.

SCA, software composition analysis, checks your third-party libraries against lists of known vulnerable versions. It reads your dependency manifest. It does not look at your own code logic. It answers a different question from SAST: is a library you pulled in known to be vulnerable?

## Where does a penetration test fit?

A penetration test is the third method. A tester uses tools, including DAST-style scanners, and adds judgment: two or more accounts, abuse of your business rules, chained small issues and controls that show which protections held. The output is a set of proven findings with evidence, not a list of possible ones. See [what is penetration testing](/guides/what-is-penetration-testing/) for the full definition.

NIST SP 800-115 treats technical testing as part of a planned assessment, with a planning phase before and a reporting phase after ([NIST SP 800-115](https://csrc.nist.gov/pubs/sp/800/115/final)). Published in 2008 and still listed as final, it predates today's tool names, but the sequence holds.

A practical setup: SAST and DAST run continuously as hygiene, and a pentest runs before launch, after major changes and when a customer asks. For the neutral comparison of scans and pentests, read [pentest vs vulnerability scan on pentestcompare.com](https://pentestcompare.com/guides/pentest-vs-vulnerability-scan/). To see the tools involved, read [penetration testing tools](/guides/penetration-testing-tools/).

## Questions

### Do I need both SAST and DAST?

Most teams that ship code benefit from both, because they look at different things. SAST reads code and runs early. DAST tests the deployed app. If you have no source access, for example for a vendor product, DAST is the only one of the two you can run.

### Can DAST replace a penetration test?

No. A DAST tool sends automated payloads and reports what it can detect. It does not hold two accounts and compare their data, and it does not understand your business rules. A penetration test adds a person who proves impact and runs controls.

### Is SAST or DAST better for APIs?

It depends on what you hold. SAST can read API handler code if the tool supports your language. DAST needs a spec or traffic to know the endpoints. Neither checks whether user A can read user B's object unless you give it two sessions and a rule.

### What is the difference between SAST, DAST and IAST?

IAST watches the application from inside while a test, automated or human, exercises it. SAST reads code at rest. DAST attacks from outside. OWASP lists all three as separate methods in its DevSecOps Guideline.

## Sources

- [OWASP DevSecOps Guideline: Dynamic Application Security Testing](https://owasp.org/www-project-devsecops-guideline/latest/02b-Dynamic-Application-Security-Testing)
- [OWASP DevSecOps Guideline: Interactive Application Security Testing](https://owasp.org/www-project-devsecops-guideline/latest/02c-Interactive-Application-Security-Testing)
- [OWASP Community: Source Code Analysis Tools](https://owasp.org/www-community/Source_Code_Analysis_Tools)
- [OWASP API Security Top 10 2023: API1 Broken Object Level Authorization](https://owasp.org/API-Security/editions/2023/en/0xa1-broken-object-level-authorization/)
- [OWASP Web Security Testing Guide: Business Logic Testing](https://wstg.owasp.org/latest/)
- [NIST SP 800-115: Technical Guide to Information Security Testing and Assessment (2008, final)](https://csrc.nist.gov/pubs/sp/800/115/final)