What is SAST in application security?

Static Application Security Testing analyses source code or bytecode without executing the program. It pattern-matches known vulnerability signatures, traces how data flows through the code, and maps execution paths for logic flaws. Because it needs no running application, it can run from the moment code is written, which is the earliest point any security testing can happen.

What is the difference between SAST and DAST?

SAST is white-box testing that reads the source code without running it, so it can name the exact vulnerable line but cannot see runtime or configuration problems. DAST is black-box testing that probes a running application from outside, so it finds runtime and configuration flaws but cannot point to the code responsible. They are complements, not alternatives, and NIST SP 800-218 lists them as separate practices for that reason.

What are the main limitations of SAST?

SAST is blind to runtime behaviour, so anything that only appears once the application is running and configured escapes it. It has a higher false-positive rate than dynamic testing, because it reasons about code paths that may never execute. It is tied to specific languages, and it requires access to source code, which rules it out for most third-party components.

What Is SAST? Static Application Security Testing

Bugs are cheapest to fix at the moment they are written. Static Application Security Testing, or SAST, reads source code without running it: before compilation, before runtime, before deployment. It is the earliest point in the SDLC at which security testing is possible at all, and the CISSP exam expects candidates to know both what that buys and what it cannot see.

Key Insight

SAST is white-box testing that never executes the program. It reads the code the way a reviewer would, only exhaustively: pattern-matching known vulnerability signatures, tracing data flow from input to sink, and mapping execution paths for logic flaws. That is also the source of its limits. A tool reasoning about code it never runs can name the exact vulnerable line, and can say nothing about what the application does once it is configured and live.

Think Like a Manager

Manager thinking means treating SAST as a cost-control measure and not only a security one. A vulnerability fixed at code-commit time avoids the same fix done at staging, done in production, or done in an incident report, and the cost of the fix rises at every one of those steps. SAST sits at the cheapest end of that curve, which is the argument that gets it funded. DevSecOps is the operating model that keeps it there, by making the check a condition of the build rather than a review someone schedules.

SAST Strengths and Limitations

Strengths	Limitations
Earliest detection available in the SDLC	Blind to runtime and configuration behaviour
Pinpoints the exact line of code	Higher false-positive rate than dynamic testing
Plugs into IDEs and CI/CD pipelines	Tied to specific languages
Catches issues before compilation	Requires access to source code

The false-positive rate is the limitation that decides whether a SAST programme survives. A tool that flags code paths which can never execute in practice trains developers to dismiss its output, and a finding nobody reads is worth nothing regardless of how early it arrived. Tuning the ruleset is not housekeeping, it is what keeps the control effective.

Where SAST Belongs in the Pipeline

SAST is one control in a set, and the exam tests whether candidates know which gaps the others fill.

Run it on every commit, so findings arrive attached to the change that caused them rather than in a quarterly report.
Block builds on critical findings, which is what makes it a control rather than advice.
Pair it with DAST for the runtime and configuration flaws static analysis cannot see.
Pair it with SCA for third-party and open-source components, whose source you generally do not have.

NIST SP 800-218, the Secure Software Development Framework, keeps the same separation: reviewing human-readable code is practice PW.7 and testing executable code is PW.8. They are listed apart because neither substitutes for the other.

How the CISSP Exam Tests SAST

The exam usually describes the constraint rather than naming the tool. No source code available points to DAST or SCA, never SAST. A requirement to find the offending line points to SAST. Anything about third-party libraries or open-source components points to SCA. Anything about behaviour only visible in a running system points to DAST. Read for what the scenario says is available and what it says is needed, and the tool follows.

Testing methodologies are easy to recognise and easy to confuse under time pressure. Our CISSP practice tests put SAST, DAST and SCA in the same scenario, which is how the exam separates candidates who memorised the definitions from those who can apply them.