In late May, Red Hat and its parent IBM announced they would allocate $5 billion and 20,000 engineers to Project Lightwell, "to help enterprises secure open source software" alongside a group of big-target financial services companies.
The project, which the companies describe as "a trusted enterprise clearinghouse" for open source code, is exactly what Red Hat has always done: backporting security patches and upstreaming them, securing customers first and improving the entire ecosystem over time.
Even the mechanism is similar. Project customers point their build tools to the Red Hat registry and Red Hat takes care of scanning, backports, and patching, plus managing the upstream contributions.
See also: IBM muscles into OSS security space with $5 billion “Lightwell” project
But the project's plans to address the broader application landscape, including "independent libraries, language toolchains, AI frameworks, and data streaming platforms", is where it diverges from securing a discrete set of packages.
And that complicates matters – starting with who gets to decide what is covered.
When it expands beyond the early adopters, Red Hat chief product officer Ashesh Badani told The Stack Lightwell will likely have two contract tiers.
Those who only need the patches will be able to choose a "read-only mode", with a premium option for those who want to be involved in determining which packages Lightwell will include.
Places in that read-write tier may be limited, but it is not yet clear how many seats there will at the table, and how many may be filled by industry bodies for high-risk institutions, such as in the financial services sector.
Managing scale
Lightwell was born out of Anthropic's Mythos model up-ending the security ecosystem, said Badani, and the dramatically different requirements that brings.
"Customers who had access to Mythos start wondering about the extent of their exposure and then how they were going to go address it."
Red Hat's initial response was that it could help – with the distributions it provides. But customers pushed back, seeking assurance across all the open source packages they use in production.

The company is not entirely comfortable with the project being seen as insurance, or as a means to reassure regulators who are also more than a little concerned about what Mythos heralds.
Instead, the pitch is all about the software.
"This is the critical thing: we are fixing code," said Julio Guijarro, CTO for EMEA at Red Hat. First for paying members, then upstream. Which means users have the same choice as they do in, say, Linux distributions, to opt into commercial support or to wait for upstream patches.
From Red Hat's perspective, it is just widening the scope of support.
"We're still in the business of providing you lifecycle management around Linux or Kubernetes," said Badani. "But in addition to that, we are willing to go off and address specific vulnerabilities in specific packages and libraries."
See also: Multi-billion install cURL takes security reports summer holiday
How long non-participants will have to wait for patches to go upstream is a complicated question.
Red Hat wants to balance giving customers enough time to patch with the risk of exploits emerging in the wild, while answering to regulators in various fields that have very specific expectations on how vulnerabilities should be managed.
Another element to that equation is how much customers can speed up their patching; accelerating time-to-patch to match the AI-driven cycle is the subject of "active conversations", says Badani.
Getting into more communities
But what happens if open source projects can't keep up with that cycle? Red Hat does not want to own forks while waiting on maintainers far behind on pull requests, says Badani. Does that create an incentive to get more involved in projects not moving fast enough?
"Yes," he tells The Stack, "We might find ourselves in communities, either newer communities or communities where maybe we didn't have as much presence in before, to help customers address this."

Another part of the problem that must be addressed is technical debt, says Badani, and the associated tangle of versions in critical environments.
"We're finding customers that they have the same library hundreds of times, different versions, different variants," said Guijarro.
The endpoint ecosystem
Others are trying to solve the same problem in various different ways, and using various different funding models. Alpha-Omega, for instance, is an Open Source Security Foundation project with backing from the hyperscalers and AI majors.
Ultimately, says Badani, there will likely be "a shakeout and you'll end up with two or three" such groups that help secured open software.
Until then, it might be a bit noisy, with duplicate effort.
As he admits: "We're at that early stage where there are a lot of folks rushing in to try to solve a problem."