Skip to content

Back to the catalog

endorlabs.comarticle

What Is SAST? Static Analysis in the Age of AI-Generated Code | Endor Labs

Explainer on Static Application Security Testing. It covers how SAST builds an AST and runs taint analysis from sources to sinks, which flaw classes it catches (SQLi, XSS, hardcoded secrets, weak crypto) and which it misses (IDOR and other access-control bugs). It compares SAST with DAST and SCA, cites false-positive and false-negative figures (91% false positives in a 2025 study of about 3,000 repositories; 47–80% of vulnerabilities missed), and argues for reachability analysis and reasoning-based AI SAST. It ends with evaluation criteria and a rollout plan; the vendor's own benchmark claims are preliminary.

TL;DR Vendor explainer on SAST: how taint analysis works, its false-positive and false-negative limits, SAST vs DAST vs SCA, and how reachability and AI reasoning cut noise.
Open original ↗
Document

What it is

Endor Labs' vendor explainer on SAST, arguing for reachability analysis and reasoning-based "AI SAST" (its own product). The parts below are the specifics and procedure that the catalog summary leaves out.

Figures beyond the headline

  • False-positive study: 180 of 2,116 findings were real across nearly 3,000 open-source repositories (2025 study of traditional SAST tools).
  • Missed C/C++ flaws: in a 2024 study of 815 vulnerable C/C++ commits, 22% triggered no SAST warning.
  • Triage cost: an IDC study (2024) found developers spend about 3.5 hours a week reviewing scan findings.
  • Alert noise: in a 2025 Black Duck survey of over 1,000 professionals, more than 71% said a significant portion of their alerts are noise.
  • Vendor benchmark: Endor classified 95% of findings as false positives, 4.5% as true positives and 0.5% as unknown. It reports one IDOR caught that rule-based SAST missed. It also cleared one SHA-1 finding because an ASN.1 DER spec requires SHA-1.

What to do

Evaluation criteria the page gives:

  1. Accuracy: low false positives and false negatives, ideally verified by reachability.
  2. Coverage: confirm the tool actually parses C/C++, Bazel monorepos and generated code before committing.
  3. Workflow fit: results in the IDE, pull request and CI/CD pipeline.
  4. Remediation quality: each finding carries evidence (code path, snippet, CWE) and a fix.

Rollout sequence:

  1. Start with one high-value repository and a small rule set.
  2. Turn on reachability so developers see exploitable findings first.
  3. Wire results into pull requests, then expand to more repositories.
  4. Track false-positive rate and time-to-fix, and adjust.

Have each vendor run against your own repositories rather than a canned demo. The page says the false-positive rate on your code is the number that predicts how your team will experience the tool.

Caveats

  • The page's own benchmark is described as "early" and "preliminary". The IDOR and SHA-1 examples are single cases, not measured detection rates.
  • The 95% false-positive figure comes from Endor's classification of findings, with no independent verification stated.
  • The 47–80% miss range is cited from a study the page does not name or detail.
  • Broken Access Control is OWASP Top 10 A01, yet it is the class the page says rule-based SAST handles worst, so check how any candidate tool handles it.
  • The page does not describe how its AI SAST was tested beyond these anecdotes, and it ends in a demo pitch.

Technologies named here

Techniques named here

Related in AppSec