Open Source Is Free. Keeping It Secure Isn't.

We built the modern software economy on an extraordinary act of collective generosity, and we mostly forgot to notice.

In 2025, developers pulled 9.8 trillion packages from the major open source registries : Maven Central, npm, PyPI, NuGet.

Not billions. Trillions.

That number grew 67% year on year. Every one of those downloads was software that someone else wrote, that someone else maintains, that someone else is responsible for.

Given away for free and consumed at an industrial scale by organisations that mostly have no idea who wrote it or why they did.

98% of audited commercial codebases contain open source components. That figure is now effectively universal. BlackDuck says the average application pulls in 1,180 open source components, mostly transitive dependencies. The average npm project carries 79 transitive dependencies. While Java projects are likely double that. Most developers couldn’t name the maintainer of any of them.

Open source is treated as infrastructure, like electricity or water, reliable, available, taken for granted, assumed to keep working.

Unlike electricity or water, open source has no utility company, no regulator, no guaranteed funding model. It has people. Often one or two of them. And unlike utility companies, the output is free.

That assumption of abundance and reliability is what’s being tested right now. The cracks are showing. Conversations about fundamental elements like public repositories and who pays are happening. And a new commercial model is emerging to fill the maintenance gap. One that’s necessary, but not without its own dangers.

That’s what I want to talk about here.

In December 2021, Log4Shell hit. CVE-2021-44228, remote code execution in Apache Log4j, CVSS 10/10, affecting hundreds of millions of systems. The maintainers, a small group of volunteers, gave up a weekend to fix a vulnerability affecting almost the entire internet. They worked like a professional security engineering team. They received zero pay and no thanks.

What made it worse was the assumption underneath the pressure: that they had a legal and commercial obligation to fix it. Organisations sent demands. Lawyers got involved. The licence said “AS IS, WITHOUT WARRANTIES OF ANY KIND” but that didn’t stop anyone.

Rich Hickey, creator of Clojure, described the underlying belief as “a pervasive sense of communal entitlement”. A mythology that makes maintainers feel obligated to manage communities, fix issues, follow vulnerability disclosure practices, and respond to corporate legal teams, none of which they signed up for.

The FTC had to explicitly remind companies in January 2022 that the duty to mitigate known vulnerabilities sat with the organisations using the software, not the unpaid volunteer maintainers.

After Log4Shell, some maintainers in the Java ecosystem walked away. The ones who stayed took note.

Four years later, Webtide, the commercial steward of Eclipse Jetty, announced they were ending free EOL releases. For nearly twenty years, they’d published fixes for EOL Jetty versions to Maven Central as a goodwill gesture. From January 2026, that’s over. Commercial customers only. The gratitude dried up. Twenty years of goodwill, exhausted.

Something has to change. The question is what it changes into.

You know how this worked. You bought a product; the vendor supported it: bugs, features, security. At some point, they declared a version end of life. If you weren’t ready to upgrade, you bought extended support. That bought you time: time to find the bugs before you migrated, time to get the compliance cover you needed, time to plan the next step.

Eventually, that extended support ran out too. And at that point you’d typically have done one of three things. Migrated. Retired the application. Or decided, without much real concern, that you could live with the bug risk. The app was stable; no changes planned. Move it behind a firewall and leave it alone.

That last option often worked. For a long time, it was a perfectly rational decision. A stable, isolated, unchanged application running known-good software was a manageable risk. The commercial support contract was for the volatile phase: the period when you were finding problems but not ready to upgrade. Once the app stabilised, you were done.

That world is gone. The bell that marks its end sounds in September, and it’s called CRA.

Four things have changed simultaneously, and together they make the old model untenable.

Attackers are not artisans hunting for vulnerabilities one at a time. They run automated tools across the internet at scale, probing for known weaknesses in known versions. If your application is running and network-reachable, it is being probed. The firewall assumption was always fragile. It’s now a fiction. Mythos and Fable have seen to that.

Log4Shell demonstrated just how myopic the traditional defence of “it’s not internet-facing” has always been. The recent spate of attacks on build and deployment tooling makes the point even more sharply. The old heuristics about how and why an organisation gets attacked are gone. Any component in your supply chain is a potential entry point, whether it faces the internet or not.

Project Glasswing launched in April: Anthropic gave AWS, Apple, Cisco, Google, Microsoft, and others access to Claude Mythos Preview to scan critical software for vulnerabilities. Within a month, 50 partners had found more than 10,000 high- or critical-severity vulnerabilities. OpenAI’s Patch the Planet is scanning 19 major open-source projects simultaneously. IBM expanded Project Lightwell to combine AI-powered vulnerability analysis with virtual patching at scale.

Nikesh Arora at Palo Alto: “AI has compressed the window between vulnerability discovery and exploit from weeks to minutes. Traditional patching cannot keep pace.”

FIRST projects 66,000 CVEs for 2026 — 46% above what was expected in February. The same tools work just as well on old codebases as new ones.

Open source is being swept for vulnerabilities at scale. Spare a thought for the maintainers who will be dragged into reviewing and approving the torrent of AI-generated security PRs this creates. Even a well-documented, correct patch is still work. Some maintainers won’t be willing to absorb that workload. And of course we’re still only talking about supported versions. Out-of-support streams won’t just remain vulnerable; they’ll be accumulating hidden exploits faster than ever, with nobody looking.

Open Source maintainers are also subject to AI slop where seemingly valid PRs are raised en masse by AI’s posing as consumers. Overwhelming the maintainers with issues and code to review or reject. The aim is to demoralise the maintainer until they call for help (and ‘willing’ volunteers are ready) and/or to reduce the review time so that malware or vulnerabilities can be sneaked in.

A growing share of new software is being written with AI assistance. Whether guided by experienced developers or not, the output consistently appears less security-conscious than code written by professional developers - who don’t have a great track record either, to be honest.

The attack surface is growing faster than the security culture around it.

Every application in your stack has transitive dependencies that nobody reviewed carefully at the time, and nobody is reviewing now. AI models are, at the moment, even more likely to reach for vulnerable or outdated dependencies than humans are.

Article 14 of the CRA, the early warning and reporting obligation, triggers in September 2026. From that date, manufacturers must notify ENISA within 24 hours of becoming aware of an actively exploited vulnerability in any product they ship. Not “when you get around to it.” Twenty-four hours. For every piece of software you ship. Including the transitive dependencies you’ve usually been ignoring. The broader CRA obligations follow in December 2027, but September is the first real deadline.

Most organisations that have commercial support do so for the obvious things: the operating system, the runtime, the database, the application server. The big-ticket items with obvious vendor relationships and obvious licence agreements.

The rest of the stack, the myriad transitive dependencies, the open source frameworks your application was built on, the logging library, the serialisation library, the HTTP client … Those are treated as free infrastructure. Nobody asks who is responsible for their security.

Paid support may mention them indirectly - most frequently as part of the ‘not included’ element.

For a long time open source components were not even part of the conversation about commercial risk, except when a CVE was discovered by a scanner. Which, because of the way things used to work, was infrequent enough not to be concerning.

You might not have had support for them then. You need it now.

What’s filling this gap is a commercial model built around one specific discipline: security-only, minimum-change patching for software that no longer has an upstream maintainer. No new features. No bug fixes. Just the minimum necessary change to keep a piece of software safe, with the minimum possible knock-on effect on everything else.

It’s genuinely hard work. When you’re running a stable production system, you don’t want a dependency update that changes behaviour you didn’t ask for. You want the vulnerability closed, and everything else left exactly as it was. The skill set spans deep product knowledge, security expertise, and surgical precision.

I spent a few years on IBM CICS L3 Support. That’s the team that handles the major software fire alarms from big business. The sort of work where billions of dollars pass through a system, and the job is to fix it fast, but without breaking anything else.

That experience gave me a deep appreciation for what this discipline actually demands. Which is why I’m sceptical of teams who assume any developer can do it, and especially sceptical of the fork-it-yourself crowd who don’t yet understand the tar pit they’ve walked into.

One of the reasons I joined HeroDevs is that they know how to do this well and at scale. I could wax lyrical about what they’ve delivered just in the time I’ve been there, but you can do that research yourself.

The thing I want to bring up is the funding model. HeroDevs, like others in the maintenance space, offers a commercial service. HeroDevs’ business is not about open-source projects that are actively maintained. It’s about offering support for the streams that the maintainers have moved on from. The ones from which any future fix is unlikely - ever.

If you need a security fix, you buy a support contract and get one. It’s that simple, and it's commercial because it takes skill and time to achieve, and someone has to pay for that. The maintainers have moved on - there's no one else to do the work (and as I said it’s often quite skilled work).

Plus, the people who want the fix almost always do so because they need it for their commercial interest.

So I think HeroDevs' commercial operating model is reasonable, necessary, and proportional. It’s also supported by many open-source projects themselves. They recognise the situation and are sufficiently comfortable with the idea to promote HeroDevs directly.

The incentive structure for commercial security patching has a shadow side, and it’s worth discussing because I think it could become an established practice.

Several high-profile infrastructure projects have already shifted from open-source licences to “source-available” models: MongoDB, Elasticsearch, HashiCorp’s Terraform and Vault, among them. The code remains visible. The freedoms don’t. The justification usually centres on protecting against cloud providers that profit from OSS without contributing. That argument has some merit. But the direction of travel matters.

The specific scenario that worries me isn’t licence changes on new features. It’s what happens when security patches follow the same logic.

If a company has paying enterprise customers and a free community edition, and a critical CVE arrives, the path of least resistance is to fix it for the customers first. Maybe only for the customers. The community version gets the patch when there’s time, or when the pressure builds, or not at all.

You can construct a reasonable business argument for it. The AI-driven surge in vulnerability discovery creates real costs. That work needs to be funded somehow. If paying customers are the funding mechanism, it’s not entirely unreasonable to ask: why should the patch go to everyone for free immediately?

The answer is that CVE disclosure doesn’t work that way. Once a vulnerability is published, the window between discovery and exploit has compressed to hours. A fix available only to paying customers is a moat. The free users, which in practice means a very large share of the internet, stay exposed - possibly forever.

Rich Hickey’s “pervasive sense of communal entitlement” cuts both ways. Maintainers have every right to stop providing free security work. But organisations that build that calculation into a business model, where vulnerability becomes the sales lever, are doing something that deserves a clear name.

The Webtide decision to end free EOL Jetty releases was at least honest: commercial customers only, and they were upfront that twenty years of gratitude had dried up. That’s defensible. Secretly shipping a patch to enterprise subscribers a week before the community build is something else.

The regulatory environment may accelerate this. If you have to report a vulnerability within 24 hours of knowing about it, as CRA Article 14 requires from September, having a provider that's secretly slipping you fixes before disclosure makes the gap between disclosure and remediation a very specific kind of commercial opportunity.

“Use us, and we’ll give you the fix before the alert, so you never have to spend time on CRA admin and remediation. “

So far, the documented cases of commercial-first security patching for currently supported versions are limited. This is a worry about trajectory, not a widespread current practice. But the economics point in that direction, and the next few years will determine whether commercial OSS security support develops as genuine stewardship or as leverage.

The truth is that paid security maintenance is the better option right now. The old model is broken. Pure volunteer maintenance at the scale AI-assisted discovery demands is not realistic. Upgrading is expensive and risky.

The commercial model is imperfect and carries risks. But it exists, it works, and for the organisations that need security coverage for software they can’t yet migrate, it’s the only credible path.

The thing to watch isn’t whether the commercial model survives; it will. It’s whether it develops norms that keep the broader ecosystem safe, or whether it drifts toward treating vulnerability disclosure as a customer acquisition tool.

Eyes open. That’s about all we can do for now.

This is the second piece in a series. The first — “AI Is Tearing Through Your Stack” — covers what AI-assisted security research looks like in practice. The companion technical piece for developers is on Foojay.

The next piece will look at the EOL landscape in more detail: what information is available, the tools you can use to understand your own exposure, the standards emerging around lifecycle transparency, and where to look for a clear picture of what’s actually running in your organisation. The data is better than most people think. The problem is knowing where to find it.