Book an Appointment

SAST – testing code before it runs

Static code analysis is the most densely cross-referenced control point in the secure development lifecycle – and the tool with the greatest frustration potential. What SAST delivers technically, where its limits are proven, which standards require it, and what AI is changing about it right now.

Last updated: August 2026 · Valeri Milke, ISO 27001 & ISO 42001 Lead Auditor

47–80%of 192 known real-world vulnerabilities missed by six C/C++ analyzers (ISSTA study, TU Munich)
35–91%of static analysis warnings not actionable, according to consolidated research
70%fix rate at Meta with review comments on the diff (over 70%, up from near zero)
up to 88.6%fewer false alarms through LLM triage on the OWASP Benchmark — with only 3.1% recall loss

SAST (Static Application Security Testing) examines source code, bytecode or binaries for vulnerabilities without executing the program – unlike DAST (testing the running application from outside), IAST (runtime instrumentation) and SCA (dependency analysis). The strength: SAST finds known classes of flaws early, on every line of code, with an exact location – cheap enough for every commit. The price: since a fully automatic analysis that is both complete and correct is theoretically impossible, every tool approximates – producing false alarms or missing flaw classes that have no signature. Using SAST well therefore never means choosing “which tool”, but: which analysis, on which code, at which point in the workflow – and who triages the findings. That triage is exactly where the biggest change in years has been happening since 2024: AI-assisted analysis and prioritisation.

A tool landscape in upheaval

The coordinates shifted in 2024/2025 — tap a milestone for details.

The Essentials at a Glance

Nine topic blocks — tap to expand.

Strengths, limits, reality

What SAST finds reliably, where it is structurally blind, how real the noise is — and which levers Google and Meta have published.

Strengths
  • 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.
  • Findings arrive 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: the scalable baseline on which deeper, manual testing builds.
InjectionCryptography callsHardcoded credentialsMemory errors C/C++OWASP SAMMMaturity level 1
Deep dive · SAST with LLMs and AI

AI SAST: analysis learns to read intent

Since 2024, SAST has been changing faster than in the fifteen years before: language models triage findings, reason semantically across function boundaries and now find real zero-days. In July 2026 Wiz formulated a three-tier model for this — deterministic baseline scanning, continuous AI reasoning on every pull request, targeted agentic deep testing — with the core thesis: “Deep scanning everywhere doesn't scale.” The four most important developments at a glance:

LLM triage behind the scanner

The best-evidenced benefit: an LLM filter behind the deterministic scanner cuts false alarms by 88.6 to 93.3 percent with minimal recall loss — consistent across several independent studies.

Semantic reasoning on every PR

Instead of patterns, the AI examines application structure, trust boundaries and data flows — “like a security researcher would”. Neuro-symbolic approaches such as IRIS double detection compared to CodeQL alone.

Autonomous deep analysis

Systems like Wiz Atlas (over 90% on CyberGym, 200+ previously unknown vulnerabilities) or the DARPA AIxCC finalists find real flaws on their own — discovery is becoming a commodity.

New limits and attack surface

LLM verdicts are non-deterministic and can be manipulated: adversarial code comments fool LLM detectors in over 90 percent of cases. The AI analyst needs the same hardening as any other tool.

Knowledge page: AI SAST — code analysis with LLMs

With full evidence: the research picture, the 2026 tool landscape, risks and governance — including the Wiz tier model in detail.

Our solution · AI SAST in operation

VamiAppSec: six scanners, one backlog, AI triage

Our VamiAppSec platform orchestrates Semgrep, Gitleaks, Checkov, Syft/Grype and the Claude Code Security Reviewer in a single pipeline, normalises all findings into one unified schema and enriches every finding with an LLM – adding context, an exploitability assessment and a concrete patch proposal. The very triage work that sinks classic SAST programmes is taken over by the machine – traceably, and deployable in your own data centre.

6+scanners in one pipeline
−54%median triage time
93%duplicates eliminated
24 hto go live
  • Self-hosted or SaaS – on request entirely on your own infrastructure
  • Integrations: GitHub, GitLab, Bitbucket, Jenkins, Slack, MS Teams
  • As consulting on top: scanning architecture, calibration and exploit validation

Figures from our own measurements against raw scanner output; details at vamiappsec.com.

Standards & Sources

The content on this page is based on the following publicly available guides and studies.

NIST · 2022

SP 800-218: Secure Software Development Framework (SSDF) v1.1

Anchors code analysis in practice PW.7 (and post-release in RV.1.2); the reference table maps PW.7 to IEC 62443-4-1, ISO/IEC 27034 and OWASP ASVS – the densest cross-standard anchor for SAST.

OWASP Foundation · ongoing

Source Code Analysis Tools

Canonical framing of strengths (known flaw classes, exact location) and weaknesses (authorization, business logic, configuration, high false-alarm volumes).

OWASP Foundation · 2016–2026

OWASP Benchmark Project

2,740 runnable, actually exploitable Java test cases in 11 categories; scored via the Youden index. Python variant in progress.

NIST · 2017

Juliet Test Suite 1.3 (SARD)

Synthetic test cases across 118 CWEs (C/C++) and 112 (Java) with good/bad twins for discrimination measurement.

Lipp, Banescu, Pretschner (TU Munich) · 2022

An Empirical Study on the Effectiveness of Static C Code Analyzers (ISSTA)

Six analyzers against 192 real vulnerabilities in 27 projects: 47–80% missed; combining tools only narrows the gap to 30–69%.

Distefano et al. · 2019

Scaling Static Analyses at Facebook (CACM)

The diff-scan evidence: fix rate near zero for batch scans, over 70% after switching to review comments on the diff – with identical analysis.

Sadowski et al. · 2018

Lessons from Building Static Analysis Tools at Google (CACM)

The 10% rule: analyses above this effective false-alarm rate are removed from review; Tricorder actually sits just below 5%.

BSI · 2024

TR-03185: Secure software lifecycle, part 1

PROD.DEV.F.2: automated static code analysis SHOULD additionally be performed – with cross-references to CON.8, SSDF (PW) and IEC 62443-4-1.

BSI · 2023

IT-Grundschutz compendium, module CON.8 software development

Basic requirement CON.8.A7: development-time testing, complemented by the SHOULD recommendation for automated static code analysis.

PCI Security Standards Council · 2024

PCI DSS v4.0.1, requirement 6.2.3

Code review of bespoke and custom software before production – manual or automated; mandatory as a future-dated requirement since 31 March 2025.

Veracode · 2025

State of Software Security 2025

Telemetry from over 1.3 million applications: fix half-life of 252 days (+47% in 5 years); 74% of organisations carry security debt, 70% of critical debt comes from third-party code.

Gartner · 2025

Magic Quadrant for Application Security Testing

Relaunched on 6 October 2025 after a two-year pause; 16 vendors evaluated, ASPM integrated as an evaluation dimension.

Nature Scientific Data · 2025

Consolidated dataset on static analysis alert actionability

Consolidates the research on alert fatigue: 35–91% of static analyzer warnings are not actionable.

Introduce SAST, declutter it, or accelerate it with AI?

In a no-obligation intro call we look at your pipeline: which analysis runs where, how much noise your team carries, and where AI triage has the biggest leverage.