Static Application Security Testing (SAST)

• Static Application Security Testing (SAST) is a white-box analysis technique that inspects source code, bytecode, or binaries to identify vulnerabilities without executing the program.
• It uses diverse analytical models—including AST, control-flow, taint analysis, and Code Property Graphs—to support various domains such as web, mobile, blockchains, and embedded systems.
• SAST is integrated throughout the software lifecycle from CI/CD pipelines to real-time IDE feedback, balancing precision, recall, and effective warning triage, often through hybrid approaches with LLMs.

Searching arXiv for recent and foundational papers on static application security testing (SAST) to ground the article in published work. Static application security testing (SAST) is the static, white-box analysis of source code, bytecode, or binaries to detect security vulnerabilities without executing the program. In the current literature, SAST spans rule-driven analyzers, taint and data-flow analyses, control-flow reasoning, query-based systems such as CodeQL, and domain-specific analyses for cryptographic APIs, web applications, Android apps, embedded software, blockchains, and smart contracts. Its operational role is equally broad: SAST is used during implementation, code review, CI/CD, and, increasingly, inside integrated development environments rather than only as a separate post hoc audit step (Silva et al., 2022, Esposito et al., 2024, Nagaraj et al., 2022).

1. Core analytical model

SAST systems are commonly defined by two coupled elements: a static program representation and a vulnerability model. The representations vary from syntax and AST traversals to control-flow, data-flow, taint, and query-oriented relational models. The vulnerability model is typically encoded as a rule set specifying insecure patterns, source-to-sink paths, forbidden API usages, or violations of domain-specific security policies. In cryptographic misuse analysis, for example, the rules may define correct and incorrect API-usage patterns; in repository-scale vulnerability detection, the detector is formalized over all functions in a repository, with $\mathcal{X} = \{x_0,x_1,\ldots,x_n\}$ and per-function labels $\mathcal{Y}$, so that the task becomes identifying vulnerable functions without pre-filtering files or methods (Silva et al., 2022, Zhou et al., 2024).

A recurring design choice is how much semantic context the analyzer carries. Some systems remain largely pattern-based; others construct richer intermediate forms. Graph-oriented post-processing work makes this explicit through the Code Property Graph, which unifies AST, CFG, and PDG information and enriches nodes with vectorized Jimple code, node-type encodings, and violation flags, thereby turning a SAST finding into a graph-classification problem rather than a purely syntactic match (Ohlmer et al., 11 Mar 2026). Query-based systems such as CodeQL use a different abstraction: an extractor builds a relational database of program facts, and a query suite executes over these facts to emit alerts with locations, metadata, and CWE tags (Ferrand et al., 8 May 2026).

This diversity of representations explains why SAST is better understood as a family of static security analyses than as a single technique. Some instances prioritize tractable rule evaluation; others prioritize interprocedural taint propagation, policy equivalence, or graph-level context.

2. Placement in the software lifecycle

A persistent theme in the literature is that the timing of SAST is as important as its underlying analysis. Conventional use places scanning in build processes, for example nightly builds, producing extensive lists of security notifications after implementation has already progressed. That model creates interruption, context loss, and delayed remediation. In response, one line of work repositions SAST as “continuous immediate feedback” in the IDE through a client–server architecture in which a SAST engine continuously feeds results to plugins for IntelliJ, Eclipse, and Visual Studio Code; preliminary measurements report average notification latency under a second, with red underlines in the editor, on-demand pop-ups, and in-code annotations to suppress specific warnings (Silva et al., 2022).

This IDE-centered view is also an interaction model. It assumes that developers need understandable notifications, examples of how to fix an issue, adaptive control over notification volume, and low false negatives even when confidence thresholds are tuned. The same work proposes adaptive analysis strategies selected according to time budget, user-defined confidence rating, and recorded false positive rate for a given issue class and strategy, so that some checks run quickly while others iterate for precision (Silva et al., 2022). A related implication is that SAST becomes part of everyday programming rather than a separate audit ritual.

At the organizational level, SAST is often framed as an early secure-SDLC mechanism. A mapping-oriented study built a three-way alignment between Checkmarx queries, OWASP Top 10 categories, and CWE/SANS Top 25 entries, treating SAST findings not only as defects to be detected but as items to be prioritized and remediated under a common taxonomy (Li, 2020). Another line of work goes further by deriving SAST directly from runtime application security protection: a two-phase abstract interpretation first analyzes the base program and then abstractly executes the policy-enforcement “meta” code, so that static and dynamic enforcement share the same policy semantics without duplicating policy implementations (Pupo et al., 2021).

3. Empirical performance and evaluation disputes

The empirical literature does not support a single universal verdict on SAST accuracy; rather, it shows that results depend strongly on benchmark construction, granularity, and operational setting. In a controlled Java evaluation covering 1.5 million test executions, eight SAST tools had 79 unique expected CWEs but only 38 unique actual CWEs, leading the authors to conclude that SASTTs exhibit high Precision while falling short in Recall (Esposito et al., 2024). In that setting, the central weakness is missing vulnerability types and false negatives, not pervasive over-reporting.

Repo-level and workflow-oriented studies reveal a different profile. A comparison of 15 SAST tools against open-source LLMs for repo-level Java, C, and Python vulnerability detection found that SAST tools obtained low vulnerability detection ratios, with maxima of 44.4% for Scenario 1 and 33.3% for Scenario 2, while keeping marked function ratios between roughly 0.0% and 5.2% (Zhou et al., 2024). A secure-code-review study over 815 vulnerability-contributing commits in 92 C/C++ projects found that a single SAST can produce warnings in vulnerable functions of 52% of VCCs, and that prioritizing changed functions with SAST warnings improved precision by 12%, recall by 5.6%, and Initial False Alarm by 13%; yet at least 76% of the warnings in vulnerable functions were irrelevant to the VCCs, and 22% of VCCs remained undetected (Charoenwet et al., 2024).

Longitudinal measurements further complicate the picture. Across 114 versions of CodeQL, 3,993 CVEs, and 1,622 repositories, CodeQL identified 171 CVEs in total, and 83 were detectable by a version released before the fix. The same study also showed non-monotonic behavior across versions: 21 CVEs were no longer detected following a version change, and 17 were never redetected (Ferrand et al., 8 May 2026). This suggests that the common claim “SAST mainly suffers from false positives” is too coarse. A more defensible statement is that SAST performance is task-dependent: controlled benchmarks may expose limited coverage and low recall, while real engineering workflows foreground warning irrelevance, triage cost, and version-to-version instability.

4. Triage, remediation, and warning management

Because SAST outputs can be voluminous and noisy, a substantial body of work focuses not on discovering new vulnerabilities but on classifying, filtering, and prioritizing findings. One Java web-application study used OWASP Benchmark and FindSecBugs to label SAST outputs as true or false positives, represented flagged code lines with Word2Vec embeddings, and applied SVM, Random Forest, XGBoost, and an ensemble. In the reported baseline, 73% of warnings were false positives; after ML filtering, false positives dropped from 4,970 to 447, or about 6.5% of all warnings (Nagaraj et al., 2022).

Graph-based false-positive prediction pushes the same idea deeper into program structure. FP-Predictor represents each CogniCrypt report by a method-level Code Property Graph, applies a GCN with a sigmoid output interpreted as false-positive probability, and uses a threshold of 0.8 to classify reports. It achieved 100% accuracy on an 80/20 CamBench train-test split and up to 96.6% overall accuracy on CryptoAPI-Bench after detailed qualitative inspection of supposedly misclassified cases (Ohlmer et al., 11 Mar 2026). Notably, many of those apparent errors corresponded to conservative security judgments rather than simple model failures.

Prioritization can also be performed above the level of individual warnings. VIVID aggregates all taint traces emitted by a SAST platform into a directed graph of Vulnerability Data Flows and applies graph metrics to prioritize remediation targets. In that framework, out-degree, betweenness centrality, in-eigenvector centrality, and cross-clique connectivity were associated with files exhibiting high vulnerability traffic, whereas out-eigenvector centrality, PageRank, and in-degree were associated with nodes enabling vulnerability flow and sinks (Budhwani et al., 22 May 2025). The practical claim is not that these metrics replace vulnerability detection, but that they can identify files where refactoring or input sanitization yields disproportionate security benefit.

A more taxonomy-driven remediation strategy appears in the OWASP/SANS–Checkmarx mapping framework, which uses standardized categorizations to filter low-value findings and focus on project-owned vulnerabilities. In its case study, an initial scan was dominated by findings in external libraries; after scoping remediation to internal code, the rescan reported 17 vulnerabilities, and a third scan left only one low-severity vulnerability remaining (Li, 2020). This suggests that remediation quality depends not only on detector precision but also on how findings are organized, contextualized, and connected to actionable repair pathways.

5. Learning-based and LLM-augmented SAST

Comparisons between rule-based SAST and learning-based models predate current LLM systems. An empirical study of rule-based SAST tools and software-vulnerability-prediction models found similar detection capabilities for the positive class, but better overall detection and assessment performance for SVP models, while also concluding that unification of the two approaches is difficult because of lacking synergies (Croft et al., 2021). More recent work revisits the same boundary under LLM conditions, but usually preserves SAST as a deterministic first stage.

At repository level, the trade-off is stark: SAST tools obtain low vulnerability detection ratios with relatively low false positives, whereas LLMs can detect up to 90% to 100% of vulnerabilities but with high marked function ratios; under ensemble settings, combined LLMs were preferred for Java, while SAST ensembles performed better for C and Python (Zhou et al., 2024). Hybrid designs therefore tend to use SAST as a conservative front end and LLMs as selective reasoning or triage layers. LSAST exemplifies this pattern by giving a locally hosted Llama-3-70B both the code and the SAST findings from Bearer, instructing it to report only additional vulnerabilities not already found by the scanner; in the reported experiments, Raw-LSAST achieved an $F_1$ score of 76.54%, compared with 38.71% for the raw LLM baseline (Keltek et al., 2024).

SAST-Genius makes the hybridization more explicit. It combines Semgrep with a fine-tuned Llama 3 8B model for intelligent triage, exploit generation, and enriched bug descriptions. On 25 open-source projects totaling about 250,000 LOC and 170 ground-truth vulnerabilities, it reported 89.5% precision, 100% recall, and a 94.5% $F_1$-score, while reducing false positives from 225 to 20 and reducing analyst time-to-triage by 91% (Agrawal et al., 18 Sep 2025). SemTaint follows a different route: rather than classifying findings after the fact, it uses multiple LLM agents to extract taint specifications—sources, sinks, first-party call edges, and third-party flow summaries—for CodeQL. Integrated with CodeQL, it detected 106 of 162 vulnerabilities previously undetectable by baseline CodeQL and uncovered 4 novel vulnerabilities in 4 popular npm packages (Ghebremichael et al., 15 Jan 2026).

The difficulty of realistic automation is underscored by SastBench, a benchmark for agentic SAST triage built from 299 true-positive CVE entries and 2,438 approximate false positives, for a class imbalance ratio of 8.15:1. In the reported comparison, the best agent reached an MCC of 0.148 (Feiglin et al., 6 Jan 2026). A plausible implication is that future hybrid systems will matter less as monolithic “AI scanners” than as carefully staged pipelines in which SAST contributes deterministic program facts and LLMs contribute contextual ranking, taint specification, or exploitability reasoning.

6. Domain-specific adaptations and socio-technical adoption

SAST repeatedly becomes most effective when specialized to the semantics of a domain. In open-source embedded software, advanced SAST tools are rarely used—only 3% of projects go beyond trivial compiler analyses—but a large-scale CodeQL study over 258 projects reported 709 true defects with a false positive rate of 34%, including 535 likely security vulnerabilities; 376 were confirmed by maintainers, and 2 CVEs were issued (Shen et al., 2023). The technical message was not only that SAST finds real defects, but that build integration and workflow packaging are decisive adoption factors.

Consensus-critical blockchain code requires even narrower specialization. In the Cosmos ecosystem, CodeQL rules aimed at sources of non-determinism initially produced many false positives; a refactored ruleset restricted analysis to consensus-critical code paths and increased per-project precision by 42.5% to 100%, with an average precision increase of 80.64% (Surmont et al., 2023). Smart-contract analysis shows a different pattern: using a taxonomy of 45 vulnerability types and a benchmark of 788 files with 10,394 vulnerabilities, one study found that existing SAST tools fail to detect around 50% of vulnerabilities and that precision does not surpass 10%; combining multiple tools reduces false negatives effectively but flags 36.77 percentage points more functions (Li et al., 2024).

Android presents yet another adaptation problem: tools differ not only in algorithms but in what they count as a vulnerability. VulsTotal unified 67 Android vulnerability types across 11 open-source tools, with tool coverage ranging from 15 to 45 types. Its CVE analysis showed that 79% of unsupported real-world CVE types required scenario-specific logic or deep semantic understanding, indicating a structural limit of predominantly pattern-based Android SAST (Zhu et al., 2024). In enterprise-like governance settings, tool combination is often explicitly socio-technical: the SOREG e-government case treated SAST as part of a human-driven security gate and concluded that combining tools can improve performance, but that SAST should be used with triangulated approaches for human-driven vulnerability assessment in real-world projects (Nguyen-Duc et al., 2021).

Taken together, the literature portrays SAST not as a stable commodity but as an evolving security-analysis ecosystem whose performance depends on representation, rule scope, lifecycle placement, warning management, and domain specialization. Its persistent tensions are well defined: recall versus precision, whole-repository coverage versus actionable locality, deterministic rule semantics versus contextual reasoning, and automation versus human triage. The most mature research directions do not discard SAST; they reorganize it around better taxonomies, tighter workflow integration, graph- and benchmark-aware triage, and hybrid systems that preserve static-analysis structure while compensating for its blind spots.