EdgeBreach homeBook a demo

Insights · Security Basics

The Alphabet Soup of Security Testing: SAST, DAST, IAST, SCA, and Pentesting, Explained

Doug Collins · · 7 min read

Chart showing where each testing method looks: SAST at source code, SCA at dependencies, IAST from code through the running app, DAST at the running app, and pentesting from the running app along the attack path

If you’ve ever sat through a security vendor pitch, you’ve heard the acronyms: SAST, DAST, IAST, SCA, and somewhere in the mix, penetration testing. Each one promises to find vulnerabilities. Each one is genuinely useful. And each one looks at your software from a different place, which means each one is blind to something.

This is a plain-language guide to what each method actually examines, what it’s good at, what it misses, and the gap that most combinations of them still leave open.

SAST: reading the code

Static application security testing analyzes your source code without running it. OWASP describes SAST tools as ones that “analyze source code or compiled versions of code to help find security flaws.” Think of it as a very fast, very literal code reviewer that knows thousands of dangerous patterns: user input flowing into a database query, a hard-coded secret, an unsafe deserialization call.

What it’s good at: catching risky code early, often in the developer’s editor or in the pull request, before anything ships. It sees every line, including code paths that are hard to reach from outside.

What it misses: context. SAST can see that input reaches a query, but not whether a framework, a proxy, or a validation layer elsewhere neutralizes it. It can’t see configuration, infrastructure, or how the deployed application actually behaves. OWASP’s own list of SAST weaknesses includes “high numbers of false positives,” and notes the tools are “frequently unable to find configuration issues, since they are not represented in the code,” and that it is “difficult to ‘prove’ that an identified security issue is an actual vulnerability.” The result is a high volume of findings, many of which turn out not to matter in practice.

SCA: checking what you didn’t write

Software composition analysis inventories the open source libraries and packages your application depends on and checks them against databases of known vulnerabilities. This matters because most of the code in a modern application isn’t code your team wrote. Black Duck’s 2026 Open Source Security and Risk Analysis report (Black Duck sells SCA tools), based on audits of 947 commercial codebases, found open source in 98% of them, and at least one known vulnerability in 87%. The 2025 edition of the OWASP Top 10 widened the old “vulnerable and outdated components” category into “Software Supply Chain Failures,” which now ranks third.

What it’s good at: telling you, quickly and reliably, that you are running a library version with a published vulnerability, and which version fixes it.

What it misses: your own code, and whether the vulnerable part of the library is ever used. A flagged dependency might sit on a code path your application never calls. One large study of the Java Maven ecosystem found that fewer than 1% of packages had a reachable call path to the vulnerable code in their dependencies, far fewer than a plain dependency list suggests. SCA also can’t see a vulnerability nobody has published yet.

DAST: testing from the outside

Dynamic application security testing works the opposite way from SAST. It ignores the code and interacts with the running application from the outside, sending crafted requests and analyzing the responses. OWASP describes these scanners as tools that probe web applications “normally from the outside, to look for security vulnerabilities such as Cross-site scripting, SQL Injection, Command Injection, Path Traversal and insecure server configuration.”

What it’s good at: finding problems that only exist at runtime, such as misconfigurations, missing security headers, and injection flaws that are actually reachable over the network. It sees the application the way an outside user does.

What it misses: anything it can’t reach or doesn’t understand. DAST tools work from libraries of known attack patterns and can only test what their crawler reaches, so they struggle with authentication flows, multi-step workflows, and business logic. A widely cited 2010 study of black-box scanners put it bluntly: “Current scanners fail to detect (or even check for) application-specific (or ‘logic’) vulnerabilities.” Scanners have improved since, but logic flaws remain the standard gap. A scanner can tell you whether a parameter reflects a script tag. It won’t notice that changing a price to one cent in your checkout actually works, because nothing about that response looks like a known vulnerability.

IAST: watching from the inside

Interactive application security testing places an agent inside the running application, which instruments it and observes code execution and data flow while the application is exercised, by tests, by a DAST tool, or by real users. OWASP’s DevSecOps guideline describes it as testing “the application while the app is run by an automated test, human tester, or any activity ‘interacting’ with the application functionality,” using “sensor modules, software libraries included in the application code.”

What it’s good at: connecting a runtime behavior to the exact line of code responsible, with fewer false positives than SAST alone, because it sees what actually executes.

What it misses: it only sees code paths that something else exercises, it requires installing an agent in each application, and support depends on your language and framework. It observes; it doesn’t attack.

Penetration testing: thinking like an attacker

A penetration test is different in kind. NIST defines it as testing “in which evaluators mimic real-world attacks in an attempt to identify ways to circumvent the security features of an application, system, or network,” and notes that most penetration tests look for “combinations of vulnerabilities” that “gain more access than could be achieved through a single vulnerability.” Instead of asking “does anything here match a known-bad pattern?”, a pentester asks “if I wanted in, how would I get in?” and then actually tries, chaining findings together, probing business logic, and proving what is exploitable with evidence.

What it’s good at: the things the other tools can’t do. Proving exploitability rather than flagging possibilities. Finding business logic flaws. Combining several individually minor issues into one serious attack path. Testers can also work white-box, with source code access, to go deeper.

What it misses: time. A traditional pentest is a scoped engagement that runs for a week or two, produces a report, and then stops. It evaluates the application as it existed during that window.

The gap they share

Lay these side by side and a pattern appears.

SAST, SCA, and often DAST run constantly. They’re cheap to run, they live in your build pipeline, and they fire on every commit. They are also the tools that produce the most noise and the least proof: findings that say “this might be a problem” and leave someone to figure out whether it is.

Penetration testing is the one method that answers the question you actually care about, which is whether an attacker can exploit this. It’s also the one that runs least often. For most organizations, that means once a year.

So the method that proves things runs annually, and the methods that run continuously can’t prove exploitability. Meanwhile, your team ships every week, or every day. Every release changes what’s exposed, and none of it gets adversarially tested until the next engagement.

That’s the velocity gap, and no combination of the acronyms above closes it on its own.

How to put them together

There’s no single right stack, but a sensible baseline for a team that builds and ships its own software looks like this.

Run SAST and SCA in the pipeline. They are inexpensive, they catch obvious problems early, and SCA in particular is the fastest way to stay ahead of known-vulnerable dependencies. Tune them aggressively so developers don’t learn to ignore them.

Add runtime testing. DAST or IAST, depending on your stack, catches configuration and reachable-injection issues that static tools can’t see.

Make adversarial testing match your release cadence. This is the piece most programs get wrong. Proof of exploitability shouldn’t be an annual event when the application changes weekly. Whether that means more frequent engagements or continuous penetration testing, the goal is the same: the version you ship gets tested by something that thinks like an attacker.

Treat proof as the tiebreaker. When the noisy tools disagree with each other, or produce more findings than you can fix, the question that settles priority is the one a pentest answers: can this actually be exploited?

Where EdgeBreach fits

EdgeBreach is continuous penetration testing. It doesn’t replace your SAST or SCA tooling; it covers the part those tools can’t. Our own reasoning model, trained specifically for software vulnerabilities, tests your running application the way an attacker would, chains findings into attack paths, and proves what’s exploitable with evidence. With source code access, it can test white-box for deeper business logic coverage. And it runs as often as you ship.

EdgeBreach is continuous penetration testing built on our own reasoning model, trained specifically for software vulnerabilities. To see what it finds in your environment, book a demo.

Sources