Static Application Security Testing (SAST) is a testing method that scans an application's source code, bytecode, or binaries for security flaws without executing the program. A SAST engine parses code into an abstract syntax tree, builds a data-flow and control-flow model, and matches that model against a library of known-bad patterns — SQL queries built from unsanitized input, hardcoded AWS keys, insecure use of eval(), and hundreds of other weaknesses catalogued in MITRE's Common Weakness Enumeration (CWE) list. The category dates back to Fortify Software (2003) and Coverity (2002), both of which productized static analysis originally built for bug-finding in C/C++ compilers. Today SAST runs inside IDEs, pre-commit hooks, and CI pipelines, typically completing a scan of a mid-sized repo (50,000–200,000 lines) in 5–20 minutes. Gartner classifies SAST as one of the four pillars of application security testing, alongside DAST, SCA, and IAST — each covering a different layer of the software supply chain.
What Is Static Application Security Testing (SAST) and How Does It Work?
SAST works by analyzing an application's own source code for exploitable patterns before the code ever runs. The scanner builds an abstract syntax tree (AST) from the code, traces variables through control-flow and data-flow graphs, and flags any path where untrusted input reaches a sensitive "sink" — a database call, a shell command, a file write — without passing through a sanitizer. For example, a SAST rule for CWE-89 (SQL Injection) traces a Java HttpServletRequest.getParameter() call through to a Statement.executeQuery() call; if no parameterization or escaping happens along that path, the tool raises a finding with the exact file, line number, and taint path. Because it doesn't need a running application, SAST can scan code the moment it's committed — some CI-integrated tools like Checkmarx or Semgrep return results in under 90 seconds on a single pull request's diff, rather than the full codebase.
How Is SAST Different From DAST and SCA?
SAST inspects an application's own source code from the inside, while DAST attacks a running application from the outside, and SCA inventories third-party open-source dependencies. A SAST scanner can catch a hardcoded credential on line 214 of auth.py before the code is even deployed, but it has no visibility into a vulnerable version of Log4j sitting in pom.xml — that's SCA's job, which is why the Log4Shell vulnerability (CVE-2021-44228, disclosed December 9, 2021) was found by dependency scanners, not SAST engines. DAST, by contrast, sends live HTTP requests at a deployed staging environment to find issues like misconfigured headers or broken authentication that only manifest at runtime. OWASP's Testing Guide recommends running all three together, since Forrester's 2023 State of Application Security report found organizations using only one testing type missed 30-40% more confirmed vulnerabilities than those combining SAST, DAST, and SCA in the pipeline.
What Vulnerabilities Does SAST Actually Catch?
SAST is most effective at catching injection flaws, insecure data flows, and hardcoded secrets — the classes of bugs that live entirely inside first-party code logic. The OWASP Top 10 categories it covers well include A03:2021 (Injection: SQL, command, LDAP), A02:2021 (Cryptographic Failures, such as use of MD5 or a hardcoded AES key), and A07:2021 (Identification and Authentication Failures, like missing session invalidation). Concretely, a SAST scan of a Node.js app might flag child_process.exec(userInput) as CWE-78 (OS Command Injection), or catch a res.send(req.query.name) pattern as CWE-79 (Reflected XSS) before either line reaches production. It's also reliable at finding insecure deserialization (CWE-502), the class of bug behind the 2017 Equifax breach, where an unpatched Apache Struts deserialization flaw (CVE-2017-5638) exposed 147 million records. What SAST cannot see are flaws that only exist at runtime — business logic abuse, race conditions across services, or misconfigurations in the deployed environment.
Why Do SAST Tools Generate So Many False Positives?
SAST tools over-flag because static analysis has to reason about every possible code path without actually running the program, which forces the engine toward conservative, "when in doubt, flag it" heuristics. A 2022 study by the NIST-affiliated SATE (Static Analysis Tool Exposition) project found commercial SAST tools reporting true-positive rates ranging from 19% to 68% depending on the codebase and rule set, meaning security teams routinely triage findings where more than half turn out to be non-exploitable. This happens because legacy SAST engines flag a tainted variable reaching a sink even if that code path is unreachable in production, sits behind a feature flag that's permanently off, or is already mitigated by a framework-level control the scanner doesn't recognize. The result, documented repeatedly in AppSec team surveys (including a 2023 GitLab DevSecOps survey where 47% of respondents cited "too many false positives" as their top complaint about security tooling), is alert fatigue that causes developers to ignore SAST output entirely.
When Should SAST Run in the Development Lifecycle?
SAST should run at every commit, not just once before a release, because the earlier a flaw is caught, the cheaper it is to fix. The often-cited IBM Systems Sciences Institute research puts the relative cost of fixing a defect during coding versus after production release at roughly a 1:15 ratio — a bug that costs a few minutes to fix in the IDE can cost hours of incident response, patching, and re-deployment once it's live. Practically, that means running a lightweight SAST scan on the diff in the IDE or as a pre-commit hook (catching issues in seconds), a fuller repo scan on every pull request via CI (GitHub Actions, GitLab CI, or Jenkins), and a scheduled deep scan of the full codebase weekly to catch cross-file taint paths that a diff-only scan would miss. Teams that gate merges on SAST findings need the tool tuned tightly enough that it doesn't block PRs on low-severity or unreachable findings — otherwise engineering velocity becomes the casualty.
How Safeguard Helps
Safeguard layers reachability analysis on top of raw SAST output so teams see which findings sit on a code path an attacker could actually reach from an exposed entry point, cutting through the 19-68% true-positive noise documented in independent tool studies. Griffin AI, Safeguard's security-focused model, triages each finding, explains the taint path in plain language, and drafts an auto-fix pull request with the sanitization or parameterization change applied inline — turning a flagged CWE-89 SQL injection into a reviewable, mergeable diff instead of a ticket. Because vulnerable first-party code often depends on vulnerable third-party libraries, Safeguard also generates and ingests SBOMs (CycloneDX and SPDX formats) so a SAST finding in your code and a CVE in your dependency tree show up correlated in one view rather than two disconnected backlogs. The net effect is a SAST pipeline that flags fewer things, but the things it flags are exploitable, explained, and already have a fix attached.