Open Source Cybersecurity in 2026 is a Mess. Maintainers Need Help. Now.

Let's talk about the open source landscape and how AI is the cause of (and solution to?) all of life's problems.

I'm not going to go into the hype cycle and value of LLMs and how they affect software security. People who maintain projects are well aware of the ongoing slow train-wreck that is happening now. I don't think that is up for debate anymore. Mythos is real. GPT Astra is real. Custom AI tooling is also real (in some cases. There's bad actors selling snake-oil out there, but that's not new to cybersecurity.) Advanced harnesses and prompts can enhance the cyber capabilities of smaller models. Now that we have that statement out of the way...

The real problem isn't that we have new powerful tools to find vulnerabilities in software, it's deeper than that. There are systemic problems in open source development, community building, and sustainability that have led us to where we are today.

The Symptom - Maintainers are getting buried in reports of both low and high quality.

Often just a glorified inbox, maintainers receive security reports from the public, validate that a security problem is a real issue, and write a fix. In early 2025 this was not an issue. Depending on the size and complexity of your project, your time addressing issues was a sizable but not unmanageable part of software development.

Today, we have maintainers receiving security reports at an unprecedented rate. This overwhelming pile is part nonsense and part reality, and it's extremely had to extricate the two. LLM based reports can be coming from a random person with no software engineering experience who used a public tool to find a potential issue and report it with the confidence of a professional with 20 years of experience. Or, conversely, it could be the product of a state of the art LLM-based tooling run, that was hand-validated by senior engineers. The reports look the same until you spend time with them, and it's far far too many reports for maintainers to spend time on each valid report, let alone taking the extra time to eliminate all of the slop.

The Real Problem

The open collaboration on software with open source code is the load-bearing pillar that has created trillions of dollars in value for the world. But the Achilles Heel of open source has always been that maintainers have limited time. From the small solo-maintained project to corporate-run open source programs with entire dedicated teams, there is a limit on the amount of work that can be done building, improving and maintaining a project.

This bandwidth is dynamic and assigned to tasks based on the maintainers preferences and what the project needs to continue to succeed.

Some time is spent on security, but that depends entirely on the maintainer, their level of knowledge about writing secure code, and how much time they want to spend making sure a typo or misunderstanding an API doesn't bring down the whole ecosystem.

The value derived from open source has always been the business case. That's not to say that free software isn't itself valuable. But when we see the giant $8,000,000,000,000 valuations of open source, they are talking about economic activity that otherwise wouldn't be enjoyed if we didn't have it.

This connects directly back to maintainers, communities, and governance. The value generated by these projects drives reinvestment into those projects at abysmal rates, with a few exceptional projects that have been deemed valuable enough for support. This core issue has created an environment where projects are chronically underfunded. They can't afford commercial security tools, they can't afford the cloud hosting for fuzzing. They can't even get easy access to free security tools to review their code. Many projects today don't have security testing in their CI pipelines. Not because they don't want it, but because it is too complex to manage alone. You switch on some tools, and get overwhelmed with the reports and understanding what is a real issue and what is a false positive. (Sound familiar?)

This chronic under-investment in open source security has left the worlds codebases in a state that doesn't quite fall apart, rather than well supported and reinforced foundations that we can (should?) build the worlds economy on top of. The world has tacitly chosen a bridge made of sticks and glue over stainless steel beams and welded rivets.

Security focused LLM tooling has only allowed us to examine things at a new scale. This has happened before with SAST, and again with fuzzing, but this time the scale is orders of magnitude larger, because we can analyze billions of lines of code with electricity and GPUs instead of decades of knowledge and dedicated research time. The rot has always been there, we've just invented a better nose.

The Event Horizon has been Crossed. We Can't Go Back.

I do not say this lightly. There are millions of bugs that need to be found, properly triaged, and fixed before an open source Mythos lands and attackers have the same capabilities as defenders, and we don't know how long we have until that happens. We can't rely on maintainers to do this alone. It's going to take engineers, community building, money, good-faith dialogue with maintainers, strategy, and policy to prevent disaster. We can't wait for someone to save us or go back to the old ways. Things have changed, and we need to adapt, quickly.

How to Help

Companies, Foundations, Governments:

Build programs to get security engineers on this problem as quickly as possible. Don't just assign them to scan code and dump even more problems on open source maintainers. Make sure that you're offering verified security bugs, shaping your reports to sensible, succinct and readable, and real solutions alongside your security reports. (Do not AI-generate fixes without verification by a human expert. It's a bad idea.)

Reach out to your communities. If you don't know who your communities are, check your Software Bill of Materials for your software. If you don't have an SBOM, build one. Everyone on that list needs your help. Find out how bad their backlogs are, and how much help you can provide, and what the maintainers actually need from you.

Invest in the foundations that support the software you use. These foundations directly help keep the lights on, and help allocate security resources to projects and keep them afloat.

Researchers:

Don't spam maintainers with bad reports. They should be succinct, describe the affected function, how it's supposed to work, why there's a bug in that code that causes unexpected behavior, and a POC that shows that the problem is real and exploitable. Check their documentation to ensure that your findings fit into their threat model. If they say that all inputs are trusted and that they don't care about stack overflows or denial of service issues for their library, respect that and do not submit an issue.

When providing vulnerability reports, offer at least some remediation steps. If the fix is complex, help the maintainer with making non-breaking changes. Don't AI generate fixes unless they are extremely simple checks or one-line corrections, and even then hand check to make sure that what you're submitting as a fix makes sense.

Don't put too much pressure on maintainers for immediate fixes, especially if you don't pay them in any way.

Maintainers:

Be more vocal about how bad the situation is. If you are buried in security reports, ask trusted organizations for help or advice. They can either help you directly or point you to helpful resources that can help you manage the influx.

Help researchers give you better reports. Include your threat model in your documentation (many of the best LLMs/harnesses look in security.md first for validating issues). If you get invalid reports from someone, make sure there is an easily accessible public place for an LLM to read about your rejection and why. If your documentation is off of your git, be sure to include this specific documentation inside of your git. This is particularly big in 2026 as LLMs often get rate limited when trying to pull docs from other sources, and then will continue to give you bad reports. Additionally, be mindful that LLMs have limited context windows, so if you want to prevent a large volume of bad reports, you can't rely on researchers looking in PRs or Issues for clues. The right docs in the right place will reduce the spam.

Volunteer for security scanning if you have time for it. This will optimize your time and energy. Significantly hardening your codebase will dramatically reduce the rate of incoming reports. Multiple organizations either already have built or are building programs to make that as easy as possible. Reach out to the foundations that work in your ecosystem to see what scanning programs they have. Failing that, there's also people at the OpenSSF, Alpha-Omega, OSTIF, OpenAI's Patch the Planet initiative, and more.