Application security has an acronym problem. You go looking for "a tool that finds bugs in our code" and come back with four categories, each with a vendor insisting it's the one you actually need.

Here's the short version. SAST reads the code you wrote. SCA checks the open-source code you pulled in. DAST pokes at your running app from the outside, like an attacker would. IAST sits inside the running app and watches what happens. Most teams end up with at least two of them, and the order you add them in matters more than which logo is on the box.

SAST reads your code without running it and traces how user input travels through it. If a request parameter ends up in a SQL query without being sanitized, SAST can flag it while the developer still has the file open. That's the big win. Fixing a bug in the IDE costs almost nothing compared with fixing it after a pentest report.

The catch is noise. SAST doesn't know what's actually reachable at runtime, so it flags plenty of things that can't be exploited. Turn on every rule on day one and your developers will learn to ignore it by day three. Start with a small, high-confidence rule set and grow it.

Good first pick if: you've got a big in-house codebase and want to catch issues before code review.

Open any modern package.json or requirements.txt and count. Most of the code you ship came from somebody else. SCA builds an inventory of those dependencies (including the dependencies of your dependencies) and matches them against known vulnerabilities. It'll also flag license problems and spit out an SBOM, which customers and auditors keep asking for.

The feature worth paying attention to is reachability. A good SCA tool won't just say "you have a vulnerable version of this library." It'll tell you whether your code actually calls the vulnerable function. That one feature can turn a 400-item backlog into a list you can finish this sprint.

Good first pick if: you lean heavily on open source, or someone's asking you for an SBOM.

DAST doesn't care what language you wrote in. It points at a running app or API, sends a lot of carefully weird requests, and watches what comes back. That's how it finds things that only exist at runtime: missing security headers, broken session handling, an admin endpoint someone forgot to lock down.

The trade-off is precision. DAST can tell you that an endpoint is vulnerable but not which line caused it, and it runs later in the pipeline, so findings show up after the code's already merged.

Good first pick if: you run customer-facing web apps or APIs.

IAST drops an agent into your running application. While your tests click through the app, the agent watches real data flowing through real code and reports problems with both the runtime proof and the exact line responsible. False positives drop a lot. The limit is coverage: it only sees the code paths your tests actually exercise, and language and framework support varies.

Good first pick if: your automated test coverage is already solid.

For most teams we'd go in this order: