Static Application Security Testing (SAST) scans source code, bytecode, or binaries for security flaws before an application ever runs. Checkmarx, founded in Israel in 2006 and acquired by Hellman & Friedman for roughly $1.15 billion in 2020, built its business on this "white-box" approach and remains one of the category's most recognized names through products like Checkmarx One and the legacy CxSAST engine. But SAST was designed for a world of monolithic codebases and quarterly release cycles, not one where a single microservices application pulls in hundreds of open-source packages and ships multiple times a day. Understanding what SAST actually catches — and where scanning source code alone leaves blind spots across the software supply chain — matters more in 2026 than it did when Checkmarx wrote its first scanning rules. This glossary entry breaks down how SAST works, what it misses, and how a modern supply chain security approach fills the gaps.
What Is Static Application Security Testing (SAST)?
SAST is a testing method that analyzes an application's source code, bytecode, or compiled binaries for security vulnerabilities without executing the program. Instead of running the app and probing it like an attacker would, a SAST engine parses code into an abstract syntax tree, builds control-flow and data-flow graphs, and pattern-matches against known-bad coding constructs — things like unsanitized SQL string concatenation (mapped to CWE-89, SQL Injection) or improper input validation (CWE-20). Because it inspects code directly, SAST can run early in the SDLC, often as a pre-commit hook or a pull-request gate in CI, catching issues before a single line reaches a staging environment. Gartner has tracked the "Application Security Testing" market since the mid-2000s, and SAST — alongside DAST, IAST, and SCA — is one of its four foundational pillars. Checkmarx CxSAST, first released in 2006, was among the earliest commercial tools to support this at enterprise scale, eventually covering more than 25 programming languages and frameworks.
How Does SAST Differ From DAST And SCA?
SAST inspects code at rest; DAST attacks a running application; SCA inventories third-party dependencies — and most organizations need all three. Dynamic Application Security Testing (DAST) tools like OWASP ZAP or Burp Suite send live HTTP requests to a deployed app and observe its responses, which means they find runtime issues (misconfigured headers, session handling flaws) that never appear in source code but also can't pinpoint the exact vulnerable line. Software Composition Analysis (SCA), by contrast, doesn't scan an organization's own code at all — it scans manifest files and lockfiles to flag known-vulnerable open-source dependencies, the class of risk behind incidents like Log4Shell (CVE-2021-44228) in December 2021, which SAST tools largely could not have caught because the vulnerable code lived in a third-party library, not the scanned application. A 2023 Synopsys "Open Source Security and Risk Analysis" report found open-source code makes up roughly 76% of the average commercial codebase, which is precisely the portion classic SAST engines don't examine.
Why Did Checkmarx Popularize SAST — And Where Does It Fall Short Today?
Checkmarx popularized SAST by making enterprise-scale, multi-language static scanning commercially viable starting in 2006, but its architecture reflects assumptions from an era before the software supply chain became the primary attack surface. Checkmarx's core engines were built to answer one question — "is this line of first-party code vulnerable?" — and they answer it well for classic web application flaws like injection and cross-site scripting. What they weren't built for is verifying the integrity of the build pipeline, the provenance of a compiled artifact, or whether a dependency was tampered with after publication, as happened in the 2021 Codecov Bash Uploader breach, where attackers modified a build script rather than an application's source code. Checkmarx has expanded into SCA and container scanning under the Checkmarx One platform, largely through acquisitions (it acquired open-source scanning vendor Dustico and SCA vendor Custodela's IP over the years), but customers report that stitching these modules together still produces siloed findings rather than a single risk score tied to a shipped artifact.
What Vulnerabilities Can SAST Actually Catch — And Miss?
SAST reliably catches a well-defined subset of the OWASP Top 10, roughly six of the ten categories, but structurally misses vulnerabilities that only manifest at runtime or that live outside the scanned codebase entirely. It's strong on Injection (A03:2021), Security Misconfiguration patterns expressed in code, and Insecure Design smells like missing authorization checks; it's weak on Broken Access Control that depends on runtime session state, Server-Side Request Forgery that requires knowledge of live network topology, and business-logic flaws where the code is technically "correct" but the workflow is exploitable. Independent benchmarking, including NIST's SATE (Static Analysis Tool Exposition) research initiative, has repeatedly found commercial SAST tools — Checkmarx included — post false-positive rates in the 30–50% range on real-world codebases, meaning a team scanning a 500,000-line application can easily face several hundred findings that need manual triage before a single fix ships. That triage tax is a leading reason SAST rollouts stall: a scan that developers don't trust is a scan they route around.
What Does SAST Cost, And What Return Does It Deliver?
Enterprise SAST licensing from established vendors typically runs from roughly $20,000 to well over $250,000 annually depending on lines of code, number of applications, and seat count, and the return depends entirely on how early in the pipeline a flaw is caught. IBM's long-running Systems Sciences Institute research, cited across the industry, estimates that a defect caught in the design or coding phase costs roughly 6x less to fix than one caught after release, and up to 15x less than one caught in production — the core economic argument for shifting security left. IBM's 2023 Cost of a Data Breach Report separately put the global average breach cost at $4.45 million, up 15% over three years, which is the number security leaders cite when justifying SAST spend to the board. But cost-per-finding matters as much as license cost: if 40% of flagged issues are false positives, the effective cost per real vulnerability found roughly doubles, eroding the ROI case that vendors like Checkmarx lead with in sales conversations.
How Do Teams Fit SAST Into a Modern CI/CD Pipeline?
Teams get the most value from SAST by running it as an incremental, PR-level gate rather than a full-codebase nightly batch job, because incremental scans return results in minutes instead of hours and keep security feedback inside the same review cycle as code review itself. A full-repository SAST scan on a large monorepo can take anywhere from 20 minutes to several hours depending on engine and codebase size, which is why mature DevSecOps programs configure diff-aware scanning that only re-analyzes changed files and their dependency graph, then reserve deep, full-codebase runs for a nightly or weekly cadence. This is also where policy-as-code matters: gating a merge only on newly introduced high-and-critical findings, rather than the full historical backlog, is what lets teams adopt SAST without freezing an entire release train on day one.
How Safeguard Helps
Safeguard is built around the premise that source code is only one link in the software supply chain, and securing it in isolation — the traditional SAST model Checkmarx helped establish — leaves the artifact, build pipeline, and dependency graph unverified. Rather than asking teams to run a standalone SAST product and then separately stitch together SCA, container, and provenance data, Safeguard correlates static code findings with software bill of materials (SBOM) data, dependency provenance, and build attestation in a single risk view tied to the actual artifact that ships to production. That means a SQL injection flaw a SAST engine finds in a pull request is evaluated alongside whether the artifact it ends up in was built from a verified, untampered pipeline and whether any of its dependencies carry known exploited vulnerabilities from CISA's KEV catalog — collapsing what would otherwise be three or four disconnected dashboards into one prioritized queue. Safeguard also targets the false-positive tax head-on: findings are automatically enriched with reachability context, so teams triage the subset of static findings that are actually exploitable in a running deployment rather than every pattern match a scanner surfaces. For teams evaluating a move off legacy SAST-only tooling, Safeguard's supply-chain-native approach is designed to answer not just "is this code vulnerable?" but "is what we're about to ship trustworthy end to end?" — the question SAST alone was never built to answer.