We’re excited to announce that Ruby Central has been awarded a grant from Alpha-Omega to help improve the security of the Ruby open source ecosystem. With this support, Ruby Central is funding a team of Security Engineers in Residence to find real vulnerabilities in the gems the community depends on most, verify them, and bring maintainers reports worth their time.

The same AI tooling that helps developers ship faster has made finding vulnerabilities cheap. An attacker can act on a raw signal the moment a tool surfaces it. A responsible reporter cannot. Someone has to confirm the vulnerability is real, work out what it means in practice, and decide it is worth a maintainer's time. That work falls on people, and people are the scarce part.

That scarcity is the whole reason this program exists, and it is what Alpha-Omega's support pays for. With their backing, Ruby Central, which runs RubyGems.org, is funding a security program for the Ruby open source ecosystem built around a single idea: every report that reaches a maintainer should be the work of a person who understood the gem first. AI helps us find candidates faster, but nothing reaches a maintainer until a person has confirmed the report is real, assessed what it means in practice, and decided it is worth that maintainer's time.

Ruby sits at the heart of much of the modern web. Keeping its core, RubyGems, Bundler, and the most widely depended-on gems secure is essential, and the pace of newly discovered, exploitable vulnerabilities risks outrunning the community's capacity to respond. Maintainers are already feeling one side of this: a rising tide of low-quality, AI-generated vulnerability reports that consume time and bury the issues that genuinely matter. This program is built to be the opposite of that. We are glad to be taking it on alongside peer ecosystems facing the same challenge, including the Python Software Foundation, Rust Foundation, PHP Foundation, and others.  We expect to learn a great deal from one another.

In practice, that means we scan prioritized Ruby projects for vulnerabilities, verify what we find so maintainers do not receive noise, assess real-world severity using Ruby-specific deployment context rather than a generic score, and coordinate responsible disclosure directly with maintainers. Where it helps, we produce Ruby-specific security guidance maintainers can use on their own.

This is not an outside team scanning from a distance. The people doing the work are embedded in the ecosystem they are securing. Dushan Karovich-Wynne, Ruby Central's Security Engineer, leads the hands-on scanning, verification, and disclosure, with Colby Swandale on the technical work and Marty Haught, Ruby Central's Director of Open Source, steering the program. They are joined by security consultants Matt Mongeau and Patrick Linnane, the latter a Homebrew maintainer and senior security operations leader, by Maciej Mensfeld, a contributor whose research focuses on the Ruby supply chain, and by Mike Dalessio, our Rails Security team rep, who makes sure findings in Rails and the code beneath it reach Rails Core quickly. The team draws on @kou for the Ruby Core perspective and Andrew Nesbitt for years of work on the structure and security of package ecosystems. That range is the point. It is what lets us judge whether a finding is real, and what it means in practice, before it ever reaches a maintainer.

This is the beginning, and we are still proving the workflow. The first several engagements are deliberately small. Our first was a report of a ReDoS vulnerability in the CSS query tokenizer to the Nokogiri maintainers, which was quickly validated and fixed. This gave us a real case to pressure-test how we scan, verify, and disclose before widening the work. The purpose of these early engagements is to validate how we triage and work with maintainers, and to turn what we learn into a repeatable playbook that future contributors can follow. We would rather earn trust with a process that works than promise broad coverage we cannot responsibly deliver yet.

None of this is about CVE counts, bounties, or building a name. The people doing the work depend on these libraries too. With Alpha-Omega's support, the program answers to the health of the ecosystem, not to a metric or a paying customer. That is what the funding buys: not a number that looks good in a report, but the scarce human judgment that turns a raw signal into a report a maintainer can act on.

You do not have to maintain a gem to be part of this. If you maintain a Ruby project, you can put it forward for review. If you research security and want to bring us a finding, we will work it through with you. And if you have feedback that would make this work better, we want to hear that too. We will launch the program page on RubyGems.org with all these details, a FAQ, and contact information in the next two weeks.

The libraries at the heart of Ruby are kept running by people, often just a few of them, and the rest of the ecosystem builds on that work every day. Looking after it is something we can do for each other, and doing it well means starting small, moving carefully, and earning trust one solid report at a time. That is the work we are starting now.