Static Application Security Testing (SAST)

SAST tools analyse source code to surface security vulnerabilities before deployment. This empirical analysis shows it decreases CVEs by 8.2%.

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 is typically integrated as an automated check on pull requests and merges, helping teams detect issues early, reduce remediation costs, and maintain continuous assurance as the codebase evolves.

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: reducing latent defects before they reach production and become exploitable vulnerabilities.

1) What SAST is - and what it is not 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 → 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

As the industry evolves, a growing number of hybrid security application tools are blending the lines between SAST, DAST and SCA, and even adding a new addition - LLM review. This paper focuses on SAST because it is well established and testable, but the state of the art is to identify tooling that increases the security reach.

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

Benefits are separated into those for Security, and for business

Benefits - security 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 research indicates 8.2% fewer lifetime CVEs when SAST is enabled.
• Standardization
  • SAST converts “tribal knowledge” into consistent automated checks across contributors.

Benefits - business 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, security policies, and visible automation 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 is not only a “turn it on” decision; it changes how engineering teams handle code changes and security work.

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 - effort Link to heading

A practical SAST program is largely a triage and prioritization program. The dominant cost is not installation; it is ongoing interpretation and remediation.

Categories of findings Link to heading

Findings are categorized into

• true positives, which represent 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 measured outcome is a measurable reduction in externally identified CVEs correlated with SAST enablement.
• Since SAST searches for thousands of defect patterns and many vulnerabilities never receive a CVE, CVE counts under-report total security defects. Put differently: CVEs are a lagging indicator; SAST is an upstream control.

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

This research indicates that SAST enablement in open source CI/CD pipelines is associated with an 8.2% reduction in lifetime CVEs. While CVEs are an important metric, they likely represent only a small portion of actual security weaknesses present in complex software. SAST primarily delivers value by detecting vulnerabilities earlier-before release, before exploitation, and often before formal disclosure.

Given that 65.6% of the studied projects do not use SAST in pipelines, there is substantial room for ecosystem-wide risk reduction through low-friction adoption patterns: baseline-first rollout, targeted high-confidence rules, and a clear triage process. Finally, 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.