GitHub Funded 67 Open Source Projects to Fix Security. Here's What Changed

TL;DR

• GitHub's Secure Open Source Fund paid 67 projects $670K to ship measurable security improvements in a 3-week sprint
• Across all sessions: 138 projects, 191 new CVEs issued, 600+ leaked secrets resolved, 500+ CodeQL alerts fixed
• Session 3 covered everything from CPython and Node.js to pandas, Jenkins, and curl — projects with billions of monthly downloads
• This matters because your production stack depends on these projects, whether you know it or not

The Big Picture

Your code runs on open source. So does your CI pipeline. And your package manager. And the runtime that executes your AI models. When curl breaks, billions of systems stop moving data. When a Python vulnerability ships, every data science workflow inherits the risk.

The problem is that most of these projects are maintained by small teams with no dedicated security budget. They're expected to harden authentication, prevent supply chain attacks, and respond to CVEs — all while shipping features and reviewing pull requests. Security becomes the work that happens after hours, if at all.

GitHub's Secure Open Source Fund flips that model. It pays maintainers $10,000 per project to complete a 3-week security sprint, then checks in at 6 and 12 months with additional funding tied to sustained improvements. Session 3 just wrapped with 67 projects completing the program. The results are concrete: 99% of participants enabled core GitHub security features, and the cumulative impact across all three sessions includes 191 new CVEs issued, 600+ leaked secrets resolved, and 500+ CodeQL alerts fixed in the last six months alone.

This isn't charity. It's infrastructure maintenance for the internet. And the projects involved aren't niche — they're the invisible dependencies your stack is built on.

How It Works

The fund operates as a structured sprint, not a grant-and-forget program. Each session runs for three weeks, led by GitHub Security Lab and external security experts. Maintainers get training in threat modeling, secure coding, AI security, and vulnerability management. They also get office hours, incident response exercises, and a private community where they can surface high-risk concerns and get expert feedback.

Funding is tied to outcomes. Projects receive $6,000 during the sprint, then $2,000 at 6-month and 12-month check-ins if they maintain their security posture. They also get Azure credits for infrastructure and access to GitHub's security tooling, including CodeQL, secret scanning, and dependency review.

The sprint structure forces focus. Maintainers aren't asked to solve every security problem — they're asked to ship the improvements that matter most for their project. For some, that means enabling secret scanning and fixing leaked credentials. For others, it's setting up CodeQL to catch vulnerabilities before they ship. For projects like SciPy, it meant going from zero security scans to continuous checks on every commit and release.

Session 3 included 67 projects spanning core languages (CPython, Node.js, LLVM), networking libraries (curl, urllib3, Netty), build tools (Jenkins, webpack, GoReleaser), data science infrastructure (pandas, SciPy, OpenSearch), and security frameworks (Keycloak, external-secrets). These aren't experimental projects. They're the foundation of modern software, with billions of monthly downloads between them.

The training modules are designed to scale beyond the sprint. Many maintainers are now publishing their incident response plans, making their security playbooks forkable, and training their contributor communities on the same practices. That's how you get one-to-many impact: teach the maintainers, and they teach their ecosystems.

One signal stood out in Session 3: AI security modules produced the largest self-reported increase in security understanding of any topic. Maintainers aren't just hardening their projects — they're learning how to secure the AI workflows that depend on them. That's critical, because projects like pandas, SciPy, and PyMC are increasingly embedded in production AI systems, not just research pipelines.

What This Changes For Developers

If you've ever run pip install pandas or npm install webpack, you've depended on projects in this program. The security improvements they shipped flow downstream to every build, every CI pipeline, and every production system that depends on them.

Take curl. It moves data for billions of systems, from package managers to CI pipelines to embedded devices. When curl maintainers harden their release process, sign their artifacts, and enable secret scanning, that reduces risk for every developer who assumes curl just works. The same logic applies to CPython, Node.js, and LLVM — when language runtimes improve their security posture, everything built on top of them inherits that resilience.

For data science and AI developers, the impact is even more direct. Projects like pandas, SciPy, and PyMC are now running continuous security scans on every commit. That means vulnerabilities get caught before they ship, not after they're embedded in your model training pipeline. OpenSearch and OpenMetadata are hardening the infrastructure that powers search and metadata management in production AI systems.

Build tooling matters too. Jenkins, webpack, and GoReleaser run with elevated privileges and broad access. Compromising them compromises the entire supply chain. Session 3 maintainers focused on securing workflows that often run unattended, preventing tampering before software ever reaches users.

The shift isn't just technical — it's cultural. Maintainers moved from reactive patching to proactive threat modeling. They went from isolated security work to shared practice, publishing playbooks and training their communities. That's the kind of change that compounds. When one project hardens its release process, others fork the playbook. When one maintainer learns to run incident response drills, they teach their contributors.

This also ties into broader trends in open source sustainability. As maintainer burnout accelerates, programs like this provide not just funding, but structure and community. Security becomes less of a burden when you're not figuring it out alone.

Try It Yourself

If you maintain an open source project, you can apply for Session 4, which starts in April 2026. The application is open to any project that's widely used, actively maintained, and willing to commit to a 3-week sprint plus two follow-up check-ins.

Here's what you need to know:

• Eligibility: Your project should be critical infrastructure — something that other projects depend on, whether that's a language runtime, a build tool, a networking library, or a data science framework.
• Commitment: Three weeks of focused security work, plus 6-month and 12-month check-ins. You'll need to enable GitHub's security features, complete training modules, and ship measurable improvements.
• Funding: $10,000 total per project, paid via GitHub Sponsors. $6,000 during the sprint, $2,000 at each check-in.
• Support: Office hours with GitHub Security Lab, access to a private security community, Azure credits, and hands-on training from security experts.

If you're not a maintainer but want to support this work, you can become a funding or ecosystem partner. The program is backed by companies like Microsoft, Stripe, Vercel, and Datadog, plus foundations like the Alfred P. Sloan Foundation and organizations like OpenSSF and Mozilla.

You can also check which projects in your dependency tree have participated. If you're using CPython, Node.js, pandas, curl, Jenkins, or any of the 138 projects across all three sessions, you're already benefiting from this work. Consider sponsoring those maintainers directly or contributing security improvements upstream.

The Bottom Line

Use this if you maintain a widely used open source project and want structured support to ship real security improvements. The funding is non-dilutive, the training is hands-on, and the community is built for maintainers who are tired of figuring out security alone.

Skip it if your project is early-stage, experimental, or doesn't have significant downstream dependencies. This program is designed for infrastructure-level projects where security improvements have systemic impact.

The real opportunity here is leverage. When you harden a project like curl or pandas, you're not just protecting one codebase — you're reducing risk for every system that depends on it. That's millions of builds, thousands of production deployments, and countless developers who assume their dependencies are trustworthy. This program makes that assumption less dangerous. If your project fits that profile, apply. If you depend on projects that do, push them to apply. The next session starts in April.

Source: GitHub Blog