GlossarySecure DevelopmentTesting

SAST and DAST

SAST analyses source code, DAST attacks the running application. What each finds and misses, where they fit in the pipeline, and why neither replaces a penetration test.

Updated October 7, 2026This page as Markdown

In short

SAST (Static Application Security Testing) analyses source code or binaries without running them and finds patterns such as unsafe functions, injection sinks and hard-coded secrets. DAST (Dynamic Application Security Testing) sends requests to the running application and observes its behaviour. Both are automated, both belong in the build pipeline, and both miss logic flaws, authorisation bugs and anything that needs understanding of the business. That is what manual testing and code review add.

What is SAST and DAST?

SAST and DAST are the two basic forms of automated application security testing.

SAST looks at the application from the inside, without executing it. It parses source code (or bytecode or binaries) and traces how data flows from inputs to dangerous operations: a request parameter that ends up in a SQL query, a network buffer that is copied with memcpy without a length check, a password string in a constant. It knows about every line of code, including the ones no test ever reaches.

DAST looks at the application from the outside, while it runs. It crawls or receives the interface definition, sends crafted requests and observes responses: error messages that reveal a stack trace, parameters that reflect input, redirects that can be abused, missing security headers, outdated server components. It knows nothing about the code, only about behaviour.

Related variants: IAST instruments the running application to combine both views, SCA (software composition analysis) checks third-party components against vulnerability databases and produces the SBOM, and secret scanning looks for credentials in repositories.

Where is it defined?

Neither is a standard; both are tool categories. OWASP lists and describes SAST tools on its Source Code Analysis Tools page and DAST tools on its Vulnerability Scanning Tools page, and the OWASP ASVS defines what the tests should verify. NIST SP 800-218, the Secure Software Development Framework, requires in practice PW.7 that code is reviewed or analysed to find vulnerabilities, and in PW.8 that executable code is tested, with automated tools named as the usual means. The Cyber Resilience Act requires in Annex I Part II that manufacturers apply effective and regular tests and reviews of the product’s security; SAST and DAST in the pipeline are the evidence most manufacturers will show for that.

What it means in practice

Both tools are good at breadth and bad at depth. SAST finds the same bug in 40 places in seconds, and also reports 400 things that are not bugs; without tuning, teams stop reading the results within weeks. DAST finds exposed configuration mistakes reliably and almost never finds an authorisation flaw, because it does not know that user A should not see order B.

In code reviews and web and API penetration tests we see the pattern repeat: the project runs SAST and DAST, the reports are green or ignored, and the critical finding is an IDOR, a broken state machine in the checkout, or a diagnostic routine that skips the authentication check under one condition. None of that is a pattern a tool recognises. The tools earn their place by taking the easy bugs off the table so that humans can spend their time on the hard ones.

Common misunderstandings

A clean SAST or DAST run is not a security statement about the product; it is a statement about the absence of known patterns. “We run a scanner” also does not satisfy a customer, an auditor or a regulation asking for a penetration test; the two are complementary. And SAST does not replace secure coding: it finds instances of mistakes, while training and review reduce the rate at which they are made.

FAQ

Frequently asked questions

Do I need SAST or DAST, or both?

Both, if you develop software that others depend on. SAST runs on every commit and catches bugs where they are cheapest to fix; DAST runs against a test deployment and catches configuration and runtime issues SAST cannot see, such as missing security headers, exposed debug endpoints or authentication that works differently than the code suggests. Start with SAST if you have to pick one, because it needs no running environment.

Does SAST work for embedded C firmware?

Yes, and it is one of the most useful places for it. Static analysers for C and C++ find buffer overflows, integer overflows, use of banned functions and MISRA violations in firmware that will never see a web scanner. The limits: they do not understand your protocol, so a UDS handler that accepts any security-access key looks fine to them. Fuzzing and a manual review of the protocol handlers close that gap.

How much does the pentest overlap with SAST and DAST?

Less than people expect. In a penetration test we assume you already run scanners and we spend our time on what they miss: chaining findings, authorisation logic, business flows, protocol semantics, and verifying that the scanner findings are real. We do read your SAST and DAST results if you share them; it saves time and sharpens the focus.

Sources

← Glossary