By Yesenia Yser
Introduction: Why We Need a Fight Club for Open Source Security
Let’s face reality, open source software powers the world.
According to the GitHub Octoverse report, GitHub has had over 121M+ increase in new repositories, with a global contribution of active developers of 180M+. If we take a step back to everyone’s favorite and memorable year, 2020, Developer Tech reported 60M+ new repositories with 56M active developers. The absolute number of new repositories per year has nearly doubled between 2020 and 2025.
The start of this boom is thanks to our user vibe-friendly and viral AI movement sweeping the world. For context, this is only GitHub statistics. It does not consider any of the other source code management repos, such as bitbucket, GitLab, and internal repositories that are forked from these public repos.
Innovation in both public and private repositories has rapidly increased around the globe. With the GitHub report stating that net new devs in globe regions have grown in the millions between 2024 to 2025, such as APAC with +13M, Europe with +6.3M, and Africa & Middle East with +3.4M.
As an open source advocate, this growth is spectacular to witness. There is the surge in innovation and the increasing use of leveraging open source as a catalyst for building and scaling ideas. These numbers reflect both a growing developer ecosystem, the expanding use of GitHub, and the collective power of communities building in the open.
While these numbers highlight explosive innovation in OSS, accelerated by AI and quantum readiness, security and compliance rarely evolve at the same pace—often arriving after risks have already materialized.
This unfortunately often rests on the shoulders of maintainers who are already stretched thin. A passion hobby turned into a nightmare with pull requests, emails, and messages screaming compliance, regulations, and bugs. As projects scale, sustainability depends on intentionally onboarding and distributing responsibility among additional trusted maintainers—so growth doesn’t become a single point of failure. Many are wary of malicious actors attempting to compromise projects—like the XZ Utils incident—or the steady influx of automated bots and first-time contributors leveraging AI tools to submit changes at scale.
When that first critical vulnerability hits, it rarely arrives gently. It often shows up as a public issue, a CVE notification, or much worse– a security research tagging the project and blasting them on social media. For many small projects, there is no one to call for backup or support. Maintainers suddenly find themselves navigating coordinated disclosure processes, assessing exploitability, triaging pull requests, managing public relations, and so much more–all while trying to maintain their own lives and jobs, as well as determining whether the report is legitimate, actively exploitable, or even fully understood.
Depending on the dependency chain and the popularity of a project, corporations quickly move into risk-mitigation mode. These corporations may be breathing down the necks of maintainers, imposing unrealistic deadlines, and treating our dear unpaid maintainers with the same demands they have for a vendor which they pay for their support. The pressure can feel disproportionate, as if they are being held to enterprise standards without the enterprise resources.
The OpenSSF’s 2023 State of Open Source Security report found that 96% of applications use open source libraries, and 84% of vulnerabilities are found in transitive dependencies and presumably there is very little evidence of popular open source that has no open source dependency.
When 84% of vulnerabilities come from transitive dependencies, how often do organizations need help from the open source maintainers to resolve these issues?
With nearly every application relying on open source software and most vulnerabilities hiding in indirect dependencies, maintainers ultimately own their projects. But ownership should not mean standing alone.
At today’s scale, OSS security demands structured support: expert guidance, shared tooling, coordinate disclosure processes, and advisory networks – much like pro bono legal systems that provide reinforcement when the stakes exceed individual capacity.
Who are you going to call?
Imagine a global network of open source security engineers—volunteers from across the industry and the globe—ready to jump in, share expertise, and help projects strengthen their defenses. These volunteers are professionals from across the industry and academia with a network and knowledge including but not limited to vulnerability researchers, secure code reviewers, supply chain security specialists, governance and compliance advisors, and experienced maintainers who understand the realities of sustaining OSS at scale.
That’s the vision: a “fight club” for open source security. Not a secret society, but a transparent, collaborative corps dedicated to making OSS safer and more resilient.
With this, I’ll state my first rule of open source fight club.
You do not ignore your dependencies.
The Problem
Security in open source is a hard problem. It’s unreasonable to expect every project to have deep security expertise or the resources to respond to incidents effectively. The ecosystem is vast, diverse, and interconnected—yet support systems haven’t kept pace with the growing expectations around security, compliance, and reliability.
Imagine Yolanda creates a tool during a semester at college. She becomes passionate about the tooling and brings a few friends on board to help her finish a feature list she had. Somehow, the tool goes viral and each day more folks download the library and expand the scope of the library. Yolanda starts seeing in flux of pull requests, contributors, and conversation around the tool she was passionate about.
Months later, life kicks in. Yolanda graduates, starts a new job and finds new hobbies to fulfill her. It had been almost a year since she last touched the repo, it’d become too much for her to handle with her other responsibilities.
Yet engineers all over the world continuously bring in the library into their innovation from the OSS world all due to it being vibe coded or it was an answer on Stackoverflow. No verification, no validation, and no testing, simply a method to solve the engineer’s problem.
One day as Yolanda is on a much needed vacation, she receives an email from a corporation demanding she patch a security vulnerability discovered and an additional laundry list of requests so that the corporation can meet regulatory compliance. The corporation demands are aggressive with potential lawsuit or regulatory fine if she did not comply.
What is Yolanda to do?
While this story isn’t true, it reflects the reality of what open source maintainers go through. A passion project, a quick innovation to solve their problem, or even a college program, can turn viral and necessary overnight, making its way into a corporation software which has regulatory compliance, financial impact, and other requirements not on the mind of our OSS maintainers at the time of innovation.
Yolanda’s story exposes the fragility of our current approach. Every vulnerability starts as trust without verification. This gap leaves projects vulnerable and maintainers overwhelmed. We need a new model—one that scales trust, expertise, and collaboration across communities.
Now the second rule of open source fight club:
Trust must be verified—every dependency, every patch
The Vision: Open Source Security Engineers in Residence
Enter the Open Source Security Engineers in Residence (SEIR): a mission-driven collective providing security expertise to projects that need it most. Driven with the open source model, a collective group of open source security engineers from around the globe come together to build a centralized conversation and action hub to collaborate openly. This isn’t an elite security club or a room full of experts guarding secrets. It’s a support network designed to work alongside maintainers, not above them.
Open source gives maintainers freedom to innovate. Security ensures maintainers can keep it.
The mission of the SEIR is to create a global, community-driven network of security engineers dedicated to strengthening the open-source ecosystem by:
- Sharing knowledge and expertise to address emerging and complex security incidents.
- Providing accessible security guidance for maintainers and contributors to implement best practices and controls within their projects.
- Developing and distributing educational resources across foundations, languages, and ecosystems to raise security awareness and capability.
- Collaborating on scalable solutions for dependency and supply chain security challenges that impact open source software worldwide.
The SEIR exists to close the gap between growing security risks and the limited resources available to maintainers. It’s a collaborative force designed to make security expertise accessible, actionable, and community-driven. Our mission is to empower open source projects with the knowledge, tools, and support they need to thrive securely in an interconnected world.
My personal favorite – third rule of fight club:
We share knowledge, not just code.
Why Alpha-Omega Matters
Alpha-Omega acts as a catalyst for this movement—connecting security experts with open source maintainers and fostering cross-foundation collaboration. Through virtual meetups and in-person sessions at OSS conferences, Alpha-Omega is creating a space where ideas turn into action. And now, we are taking that action further by leveraging artificial intelligence to help identify, triage, and fix vulnerabilities in open source projects—always with the approval and in partnership with the maintainers themselves.
Our work operates on two critical dimensions. First, we are helping maintainers manage the growing volume of security-related contributions and issues—providing relief from what can only be described as AI slop: an unrelenting flood of automated, low-quality inputs that consume time and energy without meaningfully improving security. Second, and equally important, we are actively enabling maintainers to use modern large language models and analysis harnesses to scan their own codebases and upstream dependencies for security flaws, and to get real support toward potential fixes. This is not about replacing the maintainer’s judgment—it’s about arming them with tools commensurate with the scale of the problem.
One tool at the center of this effort is Scrutineer, an open source security analysis tool now publicly available at github.com/alpha-omega-security/scrutineer. Scrutineer leverages publicly available AI models to scan repositories for security flaws and helps surface candidates for remediation. We encourage maintainers and security engineers alike to use it for their own scanning—and to join the contributor community, where collective learnings feed back into improving the tool for everyone. The more projects and contributors participate, the smarter and more effective this shared resource becomes.
Early findings from this work are sobering. Across analyzed repositories using modern AI-assisted scanning, a significant proportion—roughly half—contained flaws that warrant triage and remediation. This is not a fringe problem. It is endemic, and it is hiding in plain sight across ecosystems large and small.
Funding this work at meaningful scale is a question we are actively exploring—including how to make funding go further by thinking smaller and more targeted. Not every ecosystem is Python. Consider the Erlang ecosystem: a smaller but critical community where a focused stipend—perhaps in the range of $50,000—could fund a dedicated security engineer in residence, a “firefighter” for that ecosystem. The math changes when you stop thinking about funding monolithic programs and start thinking about right-sizing support to the community that needs it. We believe this model of targeted, ecosystem-specific investment could unlock security capacity in places that have historically been overlooked.
Over the past several years, Alpha-Omega has built relationships with major foundations, package managers, and organizations that power the open-source ecosystem. These partnerships have sparked critical conversations about supply chain security and dependency risks. It’s an open invitation for the community to help scale solutions to one of the industry’s most pressing pain points.
Now, Alpha-Omega is calling on maintainers, contributors, and security professionals to join the movement. Together, we can transform these early conversations into sustainable practices that protect the software powering the world.
The empathic fourth rule of fight club
We respect the maintainer’s burden.
Key Challenges We Must Solve Together
Incident Response & Trust Networks
Think of this as building an “Open Source Fire Department” or a “CVE ER.” When a security crisis hits, time matters. We need trusted responders, clear protocols, and a network that can mobilize before incidents spiral. This means creating systems that scale trust, funding, and expertise across projects and foundations.
Mentorship & Sustainable Growth
Today, security knowledge spreads organically—often through informal channels. While that’s valuable, it’s not enough to meet the scale of modern threats. We need structured mentorship programs, contributor ladders, shifting the expertise knowledge to the developers, and practical playbooks to reduce burnout and welcome new talent into the security ecosystem.
Data-Driven Insights
Security decisions should be informed by data, not guesswork. Tools like Ecosyste.ms and dependency mapping help us identify high-impact projects and allocate resources where they matter most. By leveraging these insights, we can prioritize efforts and make measurable progress toward a more secure open-source ecosystem.
AI-Assisted Scanning & the Scrutineer Community
Identifying flaws at scale requires purpose-built tooling. Scrutineer is an open source security analysis tool now available at github.com/alpha-omega-security/scrutineer. It leverages publicly available AI models to scan repositories and surface candidates for remediation. We must collectively solve the challenge of scaling this scanning practice across the broader ecosystem—building shared contributor knowledge and expanding coverage over time. Every maintainer who runs a scan contributes a signal. Every contributor who improves the tool multiplies its impact. This is a community-scale challenge that requires community-scale participation, and Scrutineer is a practical place to start.
Call to Action: Join the Conversation
This is a hard problem—and we can’t solve it alone. We’re inviting security engineers, maintainers, OSS advocates, and organizations that depend on open source software to join this conversation and help shape the future of open source security.
Ways to get involved:
OSS Volunteers
- Join our virtual calls and async forums
- Use and contribute to Scrutineer—run it against your repositories, share your findings, and help improve the tool for the whole community
- Co-author with us—PRs welcome, and so is your voice in shaping the contributor ladder for security roles in OSS
Corporate Volunteers & Supporters
- Second your security engineers to open source projects as volunteer security reviewers—lending your team’s expertise where it is needed most
- Fund the firefighters—even modest, targeted stipends can sustain a dedicated security engineer in a critical ecosystem. The math is different for every community. Let’s talk about right-sizing support to the ecosystems your organization depends on.
- Integrate and share—use tools like Scrutineer as part of your own supply chain security processes and share what you learn with the broader community
Grants for AI Security Engineers in Residence
- We are actively funding grant programs to fund AI-assisted Security Engineers in Residence (SeiR) roles across underserved open source ecosystems. To learn more visit the Alpha-Omega blog. At the time of this blog publication, the following AI-assisted Security Engineers in Residence (SeiR)s have been announced:
- If this speaks to you or your organization, we want to hear from you now. The cheer squad builds before the game starts.
We’re not building a secret club. We’re building a community of action. If you care about OSS security, this is already your fight.
Lastly, final rule of fight club:
We fight together – community over chaos.
About the Author
Yesenia Yser, Sr. Security Program Manager, Microsoft and Open Source Security Advocate, OpenSSF’s BEAR Working Group
Yesenia specializes in architecting secure AI and software systems by combining 12+ years of application security, supply chain defense, digital forensics, and open-source security leadership with deep hands-on research in AI supply chain security, Agentic Identity & Privilege Escalation, and software / AI lifecycles. She has built scalable frameworks and security architectures that reduce organizational risk, accelerate developer productivity, and set industry standards—currently, empowering the world with changes for AI Safety & Security and Open Source Security at Microsoft. Within OpenSSF, she is the co-host of the “What’s in the SOSS” podcast and co-lead of the BEAR (Belonging, Empowerment, Allyship, and Representation). Yesenia holds a Bachelors of Science in Computer Science from Florida International University and a Masters of Science in Digital Forensic from University of Central Florida.
