01How SAST works under the hood
SAST engines translate code into intermediate representations – abstract syntax trees or relational program facts – and run control-flow, data-flow and taint analyses on top. CodeQL, for instance, extracts code into a database and expresses vulnerabilities as queries in a Datalog extension; Semgrep matches patterns structurally on the syntax tree, with sources, sinks and sanitizers as taint rules. What separates tool classes is depth: analysis within a single function is standard – interprocedural analysis across file and function boundaries is the differentiator, and at Semgrep, for example, it is reserved for the commercial offering.
02The proven limit: exact is impossible
By Rice's theorem, all non-trivial semantic properties of programs are undecidable – an analysis that finds every vulnerability and never raises a false alarm is mathematically impossible. Every tool therefore picks a side: over-approximation (no missed cases within the modelled space, at the cost of systematic false alarms – the foundation laid by Cousot & Cousot in 1977 with abstract interpretation) or under-approximation (more precise, with gaps). False positives are not an implementation bug but the price of the approach – the only question is who sorts them out.
03What SAST finds reliably
SAST is strongest on flaw classes with a stable shape: injection, unsafe cryptography calls, hardcoded credentials, memory errors in C/C++ – with the exact file, line and code location, long before a testable application exists. That is why OWASP SAMM places automated static and dynamic testing at maturity level 1 of its security testing stream: it is the scalable baseline on which deeper, manual testing builds.
04What SAST structurally cannot find
OWASP names the blind spots clearly: authentication and authorization flaws, misuse of cryptography and business logic errors are hard or impossible to detect automatically – and configuration mistakes are not in the code at all. Measurements confirm it: in an ISSTA study by TU Munich, six C/C++ analyzers missed 47 to 80 percent of 192 known real-world vulnerabilities; even combining all tools still let 30 to 69 percent through. These classes need threat modeling, reviews – or semantic reasoning.
Threat modeling knowledge page →05The false-positive reality
According to consolidated research, between 35 and 91 percent of static analysis warnings are not actionable. A vendor-funded 2025 field study across almost 3,000 public repositories found over 91 percent false alarms in three classic flaw classes – in the extreme case 1,166 findings with 6 real hits. And an evaluation of over 100 million AppSec findings from 178 organisations showed that only 2 to 5 percent require immediate action. Alert fatigue is not a soft factor; it is the most common reason SAST programmes fail.
06What Google and Meta do differently
The two most effective levers are published: at Meta, the fix rate of nightly batch scans was close to zero; once the same analysis appeared as a comment in the code review of the diff, it rose to over 70 percent – same engine, same false-positive rate. Google only admits analyses into the review whose effective false-alarm rate stays below 10 percent; in practice its Tricorder system sits just below 5 percent. The lesson: deployment point and developer trust beat tool quality.
07Evaluating tools seriously
The OWASP Benchmark is a runnable Java application with 2,740 actually exploitable test cases in 11 categories; tools are scored on true-positive versus false-positive rate (Youden index). NIST's Juliet suite adds synthetic test cases across 118 CWEs in C/C++ and 112 in Java. Be wary of vendor claims like “100% detection”: the corpora are public, overfitting is possible – and newer benchmarks such as CASTLE show each tool class has its own failure patterns: formal verification minimises false alarms but fails outside its model; LLMs shine on snippets and weaken as code size grows.
08A tool landscape in upheaval
The coordinates shifted in 2024/2025: Semgrep moved its maintained rules to a proprietary licence in December 2024 – in response, a consortium of about ten security vendors forked the engine as Opengrep (LGPL; after one year: 43 releases and cross-function taint analysis as open source). Sonar likewise pulled its language analyzers out of the LGPL. GitHub split Advanced Security in April 2025 into Code Security (30 US-$ per active committer/month) and Secret Protection (19 US-$). And after a two-year pause, Gartner relaunched the Magic Quadrant for Application Security Testing in October 2025 – with 16 vendors and ASPM as an evaluation dimension.
09What AI changes about SAST
The most robust numbers are in triage: LLM agents behind classic SAST reduced false alarms on the OWASP Benchmark by up to 88.6 percent with only 3.1 percent recall loss; on real CodeQL alerts they identified up to 93.3 percent of false positives. GitHub's Copilot Autofix cuts median remediation time from 1.5 hours to 28 minutes according to beta telemetry. And autonomous systems such as Google Big Sleep or the DARPA AIxCC finalists now find real vulnerabilities on their own. The limits from card 4 are shifting – but not disappearing: AI complements the layers, it does not replace them.
Deep dive: AI Code Security → 
