AI Summary
- AI‑accelerated development boosts open‑source reuse, and the inheritance of other people’s risk; Static Application Security Testing (SAST) is the upstream, preventative control that scales with that speed.
- In 294 high‑profile GitHub projects, enabling SAST is associated with an 8.2% reduction in lifetime common vulnerabilities and exposures (from 2.21 to 2.04 per project).
- 65.6% of popular projects still run no SAST in continuous integration and delivery (CI/CD), leaving easy wins on the table for risk reduction and trust signaling.
- CVE records catalog publicly disclosed vulnerabilities (not every latent flaw), so they’re a lagging indicator of risk; SAST reduces issues before public disclosure exists.
- Start pragmatic: enable SAST on new code, baseline the rest, tune a small set of high‑confidence rules and track fix‑rate, false‑positive rate and time‑to‑remediate.
Executive Summary
Software delivery is accelerating, thanks to automation, AI coding assistants and heavy reuse of open‑source components. That velocity compounds a familiar leadership problem: how to ship faster without inheriting more risk. SAST helps by identifying security issues faster. SAST inspects code before it runs, flagging risky patterns before merge rather than after release.
In this study, 294 of the open sources communities more popular packages showed that those with SAST enabled had an 8.2% reduction in lifetime Common Vulnerabilities and Exposures (CVEs), versus those without (2.04 vs. 2.21 per project).
The cohort also reveals 65.6% of these popular projects have no SAST in their pipelines at all.
The magnitude matters. CVE systems catalog publicly disclosed issues; they don’t reflect all latent defects that never reach disclosure. SAST’s primary value is preventative: it resolves many issues before they turn into CVEs, incidents and damage.
This paper explains what changes when you enable SAST, what effort it really takes, the evidence behind the impact and a pragmatic adoption path that protects velocity. The goal is not tool deployment; it’s operational assurance for enterprises that build on open‑source at scale.
Foreword
Security rarely fails because teams don’t care, it fails because problems surface too late.
In reviewing hundreds of real‑world software projects, what stood out to me wasn’t reckless development, but how many issues could have been avoided with earlier visibility. This paper quantifies the improvement from building security checks into development, and why preventing problems early can be more effective than fixing them later.
Head of Agentic Engineering