Static Application Security Testing (SAST)

SAST tools analyse source code to surface security vulnerabilities before deployment. This empirical analysis quantifies how much SAST reduces CVEs in production.

Executive summary Link to heading

Static Application Security Testing (SAST) includes techniques that examine source code without executing it to identify security weaknesses. In modern CI/CD pipelines, SAST typically runs as an automated check on pull requests and merges, catching issues early and flagging regressions introduced in later commits.

We analysed 300 of the most popular open-source projects, built from the 100 most popular projects in npm, PyPI, and Maven. Our findings show that enabling SAST is associated with an 8.2% reduction in lifetime CVEs, lowering the average from 2.21 to 2.04 CVEs per project.

Because SAST evaluates thousands of issue patterns, and many security flaws never receive a CVE, reported CVEs likely represent only a small fraction of underlying security issues. As a result, SAST’s primary value is often preventative: it reduces latent defects before they reach production and become exploitable vulnerabilities.

1) Defining SAST Link to heading

Definition Link to heading

Static Application Security Testing (SAST) analyses program text and structure to detect insecure code patterns. Typical analyses include:

• Syntactic pattern matching (e.g., dangerous APIs, insecure defaults)
• Dataflow/taint tracking (e.g., untrusted input reaching SQL execution sinks, leading to injection)
• Control-flow reasoning (e.g., missing authorization checks along certain paths)
• Semantic checks via language-aware rules (e.g., deserialization hazards, SSRF patterns)

SAST tools generally operate at one or more of these levels:

• Source code AST analysis (language parsers)
• Intermediate representations (control-flow graphs, SSA forms)
• Bytecode analysis (common in Java ecosystems)

What SAST does not cover well Link to heading

From a computer science perspective, SAST trades completeness for scalability and usefulness:

• It does not “prove” absence of vulnerabilities (static analysis is limited by undecidability and approximations).
• It often struggles with runtime configuration, environment-dependent behaviour, and complex dynamic dispatch/reflection.
• It is complementary, not a replacement, for:
  • DAST (dynamic testing), fuzzing
  • SCA (dependency vulnerability management)
  • Manual secure code review and threat modelling

Hybrid security tools increasingly blur the line between SAST, DAST, and SCA, and some now add LLM review as well. This paper focuses on SAST because it’s well established and testable, but the trend is toward combining it with DAST and SCA in a single toolchain.

2) Why SAST matters in open-source pipelines Link to heading

Benefits split into two groups: security and business.

Security benefits Link to heading

• Earlier defect discovery
  • Findings appear during PR review rather than after release, improving mean time to remediation.
• Reduction in externally reported vulnerabilities
  • This reflects the reduction in lifetime CVEs reported above.
• Standardization
  • SAST converts “tribal knowledge” into consistent automated checks across contributors.

Business benefits Link to heading

• Lower remediation cost
  • Fixing issues pre-release is typically cheaper than post-release patching, coordination, and incident response.
• Improved trust signals
  • CI badges and clear security policies increase enterprise confidence and adoption.
• Improved governance
  • SAST results provide measurable signals for security posture: trends, hotspots, rule coverage, and policy compliance.

3) Implications of enabling SAST Link to heading

Enabling SAST changes how engineering teams handle code changes and security work; it’s more than a “turn it on” decision.

Pipeline implications Link to heading

• CI time and compute cost: Static analyses can be CPU- and memory-intensive, especially for large monorepos or multi-language projects.
• PR workflow impact: Findings may block merges if configured as “required checks.”
• Signal quality management: Rule selection and tuning determine whether developers perceive SAST as helpful or noisy.
• Security policy decisions: Teams must decide what constitutes “fail the build,” “warn only,” or “defer with ticket.”

Cultural implications Link to heading

• Developer enablement: Contributors need clear guidance on how to interpret and remediate findings.
• Ownership model: Maintainers must decide who triages results (security team, module owners, developers etc.).
• Sustained maintenance: Rules and baselines must evolve as code and dependencies change.

4) Managing legitimate findings and false positives Link to heading

A practical SAST program is largely about triage and prioritization: ongoing interpretation and remediation dominate the cost, not installation.

Categories of findings Link to heading

Findings are categorized into

• true positives, which are legitimate issues requiring investigation, fixing, testing, and coordinated release; and
• false positives, which need to be suppressed and justified to prevent repeated re-triage.

Effort required & the workflow Link to heading

• Initial rollout (one-time)
  • Select tools
  • Integrate into CI
  • Establish baseline (existing findings) triage historical debt
  • Define severity thresholds and merge policies
• Ongoing operations (recurring)
  • Triage new findings before merge
  • Fix or suppress with documented rationale
  • Periodic rule updates and tuning
  • Metrics review (false positive rate, time-to-fix, hotspots)

Techniques to control false positives and workload Link to heading

• Baselining: Record existing issues and slowly reduce them.
• Scoped rulesets: Start with high-confidence, high-severity rules (e.g., injection, deserialization, path traversal).
• Auto-fix where safe: Some ecosystems/tools can propose safe refactors.
• Suppression with auditability: Require justification comments/links to avoid blanket ignore files.
• Ownership routing: Automatically assign findings to code owners to reduce maintainer bottlenecks.

5) Research summary and results Link to heading

Scope Link to heading

• Top 100 projects from each of NPM, PyPI, Maven representing a combined 300 of the most popular JavaScript, Python, and Java repositories.
• Popularity measured by GitHub stargazers.
• Example repos include: React, Pandas, PyTorch, Spring-Boot.
• 294 of these projects exist on GitHub for pipeline analysis.

Process Link to heading

• Gathered repo metadata (stars, size) and pipeline definitions.
• Pipelines searched for signatures of 20 popular SAST tools, including known variants of each tool.

Tool adoption Link to heading

CVE impact Link to heading

Across the lifetime of projects in the cohort:

• No SAST: average 2.21 CVEs
• SAST enabled: average 2.04 CVEs
• Relative reduction: 8.2%
• Total CVEs across the 294 projects: 630

Interpretation Link to heading

• The result is a measurable reduction in externally identified CVEs correlated with SAST enablement.
• CVEs are a lagging indicator; SAST is an upstream control that catches issues before they reach that stage.

6) Recommendations for repo maintainers & stakeholders Link to heading

• Enable SAST by default for new projects; baseline for mature projects
  • Avoid blocking contributor flow by gating only on new issues at first.
• Start with one high-coverage tool aligned to your ecosystem
  • Example patterns seen in the cohort: CodeQL for broad security queries; Semgrep for flexible rules; linters like Pylint can catch some security-adjacent issues but are not full SAST substitutes.
• Define a triage SLA and severity policy
  • A small number of maintainers can succeed if they focus on high-severity, high-confidence findings and keep suppressions auditable.
• Treat dependencies as a parallel risk stream
  • Most projects consume dependencies; managing vulnerability inheritance requires SCA (Software Composition Analysis) and upgrade automation in addition to SAST.

Conclusion Link to heading

The reduction reported above is an association, not a proven causal effect: projects that adopt SAST may already be more security-conscious in other ways, so the real effect of flipping the switch alone could differ from that figure in either direction. That caveat aside, the direction is consistent with what SAST is designed to do.

Given that 65.6% of the studied projects do not use SAST in pipelines, there is substantial room for industry-wide risk reduction through low-friction adoption: a baseline-first rollout paired with a small set of high-confidence rules. Because software projects are composed of dependencies that themselves accumulate vulnerabilities, SAST should be paired with SCA to manage both first-party and third-party risk effectively.