Static Application Security Testing (SAST) scans an application's source code, bytecode, or binaries for security flaws without ever running the program. First commercialized in the early 2000s by tools like Fortify (founded 2003) and Checkmarx (founded 2006), SAST works by parsing code into an abstract syntax tree, then tracing data and control flow to flag patterns such as SQL injection, hardcoded credentials, or unsafe deserialization before a single line reaches production. Today, SAST runs automatically on every pull request in most CI/CD pipelines, often generating hundreds or thousands of findings per scan across a large monorepo. The catch is accuracy: unmodified SAST rulesets are widely reported to produce false positive rates anywhere from 20% to 70%, depending on language and configuration, which is why reachability analysis and AI-assisted triage have become the main differentiator among vendors in 2026. This glossary entry answers the question "what is SAST" at a practical level: how it works, where it fits next to DAST and SCA, and why it became a board-level priority after 2021.
How Does SAST Actually Scan Code?
SAST scans code by converting it into an abstract syntax tree (AST) and building control-flow and data-flow graphs, then matching those structures against a database of known-insecure coding patterns. A typical scan runs in four stages: lexing and parsing the source into tokens, building the AST, performing taint analysis to track how untrusted input (a URL parameter, a form field, an API payload) moves through the program, and finally flagging any path where tainted data reaches a dangerous "sink" — a raw SQL query, a shell command, an eval() call — without passing through a sanitizer. Rule databases are typically mapped to MITRE's Common Weakness Enumeration (CWE), which now catalogs more than 900 distinct weakness types, and cross-referenced against the OWASP Top 10. A CWE-89 (SQL injection) finding, for example, means the scanner traced an unsanitized input variable directly into a query string. Because SAST never executes the application, it can analyze incomplete code, branches that are rarely hit in testing, and dead code paths that dynamic tools would never reach.
What's the Difference Between SAST, DAST, and SCA?
If "what is SAST" is the question, "how is it different from DAST and SCA" is usually the follow-up. The three test different layers of an application and are not interchangeable. SAST ("white-box" testing) examines source code at rest, without running the app, and is typically run in the IDE or CI pipeline — tools include Checkmarx, Veracode, SonarQube, Semgrep, and GitHub CodeQL. DAST ("black-box" testing) attacks a running, deployed application from the outside, the way a real attacker would, using tools like OWASP ZAP or Burp Suite, and it catches runtime issues like misconfigured authentication or server-side request forgery that never show up in source code alone. SCA (Software Composition Analysis) doesn't look at your code at all — it inventories every open-source and third-party package in your dependency tree and checks each one against known-CVE databases like the National Vulnerability Database. A mature AppSec program layers all three: SAST for code you write, SCA for code you import, and DAST for the assembled system in staging or production. Gartner and most enterprise security teams now group all three under the umbrella term "Application Security Testing" (AST).
When Did SAST Become a Boardroom Priority Instead of a Compliance Checkbox?
SAST shifted from a compliance checkbox to a default CI/CD gate after two incidents made software supply chain risk impossible to ignore: the SolarWinds breach, discovered in December 2020, and the Log4Shell vulnerability (CVE-2021-44228), disclosed on December 10, 2021, which affected an estimated hundreds of millions of devices running Apache Log4j. Five months before Log4Shell, on May 12, 2021, the White House issued Executive Order 14028, which directly required federal software vendors to demonstrate secure development practices and produce a Software Bill of Materials (SBOM) — pushing static analysis and dependency scanning into procurement contracts, not just engineering backlogs. By 2024, industry analysts placed the broader application security testing market above $2.5 billion annually, with SAST as one of its largest segments, and NIST's Secure Software Development Framework (SSDF, published February 2022) now names static analysis as an expected control for any vendor selling into the U.S. government. What used to be a once-a-quarter audit scan is now a required gate on every commit.
How Accurate Is SAST, and What Are Its Real Limitations?
SAST's biggest limitation is false positives: because taint analysis works on approximations of runtime behavior, scanners routinely flag code paths that are technically vulnerable but practically unreachable, unexploitable, or already mitigated elsewhere in the stack. Security teams commonly report triaging findings where 20-70% turn out to be noise once a human traces whether the vulnerable function is ever called with attacker-controlled input in the deployed configuration — and every hour spent on a false positive is an hour not spent on a real one. SAST also cannot detect vulnerabilities that only manifest at runtime, such as business logic flaws, race conditions, or misconfigurations in the deployment environment (an exposed S3 bucket, a missing WAF rule). It struggles with dynamically typed languages and reflection-heavy frameworks, where the actual call graph isn't visible from static code alone. Finally, SAST results are only as good as their rule coverage: a scanner tuned for Java Spring applications will miss framework-specific patterns in a Go microservice unless someone maintains a separate ruleset for it. This is why most 2026-era AppSec teams pair SAST output with reachability analysis rather than triaging raw scanner output by hand.
Which SAST Tools Do Security Teams Actually Use in 2026?
The 2026 SAST landscape is led by a handful of tools that split roughly along legacy-enterprise versus developer-first lines: Checkmarx and Veracode (both founded 2006) and Fortify (founded 2003, now under OpenText) dominate large regulated enterprises with broad language coverage and compliance reporting; SonarQube (from SonarSource, founded 2008) is the default for code-quality-plus-security scanning embedded in IDEs; and Semgrep, built on the open-source engine released by r2c in 2020, along with GitHub CodeQL (acquired by GitHub from Semmle in 2019), have become the standard for fast, custom-rule scanning inside developer workflows. Each tool differs meaningfully in language support, scan speed, and — most importantly for engineering teams — how much manual triage its output demands. None of them, by themselves, tell you whether a flagged function is actually exploitable in your running application; that requires connecting static findings to real call paths and deployed configuration, which is where reachability-based platforms have taken over the last stage of the AppSec pipeline.
How Safeguard Helps
Safeguard layers reachability analysis on top of raw SAST and SCA output so security teams only see findings tied to code paths that are actually exploitable in the deployed application, cutting through the 20-70% false-positive noise described above. Griffin, Safeguard's AI analysis engine, reads the surrounding code, call graph, and runtime context to explain why a finding matters (or doesn't) in plain language, and drafts the fix. Safeguard generates and ingests SBOMs natively, so every SAST and SCA finding is automatically cross-referenced against your live component inventory rather than a static snapshot from last quarter's scan. For confirmed, reachable issues, Safeguard opens auto-fix pull requests directly against the affected repo, turning a scanner alert into a reviewable code change instead of a ticket that sits in a backlog. The result is a static analysis pipeline that surfaces the handful of findings that matter instead of the thousands that don't.