IBM, Red Hat Commit $5 Billion To Secure Open Source Supply Chains 47
IBM and Red Hat are committing $5 billion to a new initiative called "Project Lightwell," which aims to secure open-source software supply chains with AI-assisted vulnerability discovery, triage, patch validation, and upstream maintenance. Longtime Slashdot reader wiggles shares a press release from IBM: IBM and Red Hat today announced Project Lightwell, a $5 billion commitment backed by new frontier AI capabilities and a global force of more than 20,000 engineers to help enterprises secure open source software. Together, these investments establish a new model for enterprise use of open source software, from upstream development through production environments.
Project Lightwell will establish a trusted enterprise clearinghouse combined with a global force of engineers to identify and fix vulnerabilities at scale. The clearinghouse will serve as a security coordination layer, using advanced AI capabilities to validate and test fixes across an unprecedented volume of open source code. These capabilities will be offered through commercial subscriptions, allowing enterprises to integrate secure patches directly into their existing software supply chains with enterprise-grade validation and lifecycle management.
IBM and Red Hat have already begun collaborating with a select group of early adopters on Project Lightwell, including Bank of America, BNY, Citi, Goldman Sachs, JPMorganChase, Mastercard, Morgan Stanley, Royal Bank of Canada, State Street, Visa and Wells Fargo. The real-world insights from these initial deployments will actively shape how vulnerabilities are identified, validated, and remediated at scale across complex software supply chains.
Project Lightwell will establish a trusted enterprise clearinghouse combined with a global force of engineers to identify and fix vulnerabilities at scale. The clearinghouse will serve as a security coordination layer, using advanced AI capabilities to validate and test fixes across an unprecedented volume of open source code. These capabilities will be offered through commercial subscriptions, allowing enterprises to integrate secure patches directly into their existing software supply chains with enterprise-grade validation and lifecycle management.
IBM and Red Hat have already begun collaborating with a select group of early adopters on Project Lightwell, including Bank of America, BNY, Citi, Goldman Sachs, JPMorganChase, Mastercard, Morgan Stanley, Royal Bank of Canada, State Street, Visa and Wells Fargo. The real-world insights from these initial deployments will actively shape how vulnerabilities are identified, validated, and remediated at scale across complex software supply chains.
There it is (Score:5, Informative)
Selling security patches as a subscription service instead of submitting them upstream to fix the problems for all users.
An abominable abuse of open source.
Re:There it is (Score:5, Insightful)
Selling security patches as a subscription service instead of submitting them upstream to fix the problems for all users.
"from upstream development through production environments."
"to secure open source software at its source and across the entire supply chain."
"Share fixes upstream so that open source communities can include them in long-term maintenance."
"Upstream maintenance alongside open source community leaders;"
Please read the whole thing.
An abominable abuse of open source.
You do understand that the freedom and licenses you're defending, specifically allow others to use your work for purposes you don't agree with, right?
If you're opposed to "evil" (but legal) uses of FLOSS, you're opposed to the core values of FLOSS.
Re: (Score:3)
"Share fixes upstream so that open source communities can include them in long-term maintenance."
I do not see those words in the summary above.
You do understand that the freedom and licenses you're defending, specifically allow others to use your work for purposes you don't agree with, right? If you're opposed to "evil" (but legal) uses of FLOSS, you're opposed to the core values of FLOSS.
I did not say "evil" nor did I say it was illegal. I said it was abusive.
-If they do in fact upstream the fixes (as you assert) then it is not abusive.
Re: There it is (Score:3)
"You do understand that the freedom and licenses you're defending, specifically allow others to use your work for purposes you don't agree with, right?"
No they fucking do not. The licenses disallow placing additional restrictions on redistribution. Just because IBM is violating this now doesn't make it not a violation
Re: (Score:2)
And until we see how this project shakes out we won't know if it's even going to suffer any of the same issues. As the situation is fairly different with no one is selling bug-for-bug implementations of WebSphere or JBoss deployments of stale Spring or Hibernate packages.
So the "we released the code upstream somewhere at about the same time as our backport, but we don't want to tell you want the exact combination so there's no 'arguably-exact' clones" isn't as relevant because the whole point is that the cl
Re: (Score:2)
If it weren't IBM, I wouldn't assume the worst. Unless it was e.g. Oracle.
Re: (Score:2)
So yeah, Red had is evil and abusing open source, the OP is correct: their motivations are suspect.
Re: (Score:2)
[had/Hat]. Autocorrect is such a pain.
Re: (Score:1)
There is nothing in the the GPL 2.0 licensing, the linux kernel, that says you have to publicly redistribute your code i think? So can I pay the subscription and use that source code as a reference to patch and distribute my own patched kernel?
Re: (Score:2)
They do publicly share code according to licenses of packages to the people they distribute their packages to. The debate is in the terms of service of their customers saying that those people will get cut off if they share that on. So those customers have the right to share it on, but if they do they don't get any more updates. But that's even then it's not the fixes themselves which they publicly work on in CentOS Stream. So it's just about it's getting all of the exact same packages versions to be able
Re: There it is (Score:2)
"I have always seen the GPL as a license requiring any changes to published code be documented and not much else"
Try reading it.
Re:There it is (Score:5, Informative)
There is undoubtedly a disconnect here on what's happening and your understanding.
The license on kernel does not cause the packages source to be released. The licenses on the individual Open Source packages themselves require distribution of the source code. RHEL in their OS packages distributes the code in SRPM [wikipedia.org] to the subscribers, but the terms of service prevent the subscribers from sharing that code on. But Red Hat also distributes all the code in their immediate upstream CentOS stream and they provide the fixes to the upstream projects themselves.
This new product isn't OS packages, but application packages used as dependencies. The service will be patching those dependencies especially old ones that are no longer receiving patches. Think of a project that's currently using v2.3.4, but someone is stuck on v1.1.1. Suppose a vulnerability is found that affects both v1 and v2, but the project only fixes v2.
This service would "backport" the fix to v1.1.1a and update the deployed app to use v1.1.1a. If the application was an Open Source license Red Hat would be required to share the code of 1.1.1a to their subscriber. But their moral obligation would be to share the 1.1.1a with the upstream project.
The disconnect for Local ID10T is their assumption that IBM/Red Hat won't share the code with the upstream project, the people on the service just get the immediate backported patch before it has a chance to trickle down the usual channel from the upstream. Not that the code won't be shared.
Re: (Score:2)
The disconnect for Local ID10T is their assumption that IBM/Red Hat won't share the code with the upstream project, the people on the service just get the immediate backported patch before it has a chance to trickle down the usual channel from the upstream. Not that the code won't be shared.
Yeah, we thought IBM/Redhat followed the GPL, but then they started placing additional restrictions on the software sent to subscribers, which is a direct violation of the GPL. It is not a defense that they are doing it in a separate license either, because that's the only place where they could do it as the GPL is copyrighted, so they can't legally just add a clause permitting it there because they'd be creating an unauthorized derivative work.
Given that they used to not do this, but they are doing it now,
Not Pirates (Score:2)
Re: (Score:2)
If you alter the code and distribute a binary, you are required to distribute the code too. You can only get around distribution if you only use the code internally, which is how so many 'internet' companies get around GPL since they keep everything server side.
Required to distribute source code ... (Score:2)
If you alter the code and distribute a binary, you are required to distribute the code too. You can only get around distribution if you only use the code internally, which is how so many 'internet' companies get around GPL since they keep everything server side.
You are required to distribute source code. There is nothing preventing you for charging for distributing a binary. Open source allows you to do it yourself or pay someone else to do it for you. This new service seems to fall into the latter.
Re: (Score:2)
They are not required to submit upstream (Score:2)
Who says they won't be submitting them upstream.
They are not required to submit upstream. They are only required to provide source code to those they provide a binary to. The key to open source is that the person you provided that binary and source code to is free to share the source code with anyone they want to. They cannot be prevented from doing so.
Re: (Score:2)
I didn't say that they are required to, but if current trends are followed they will.
The key to open source is that the person you provided that binary and source code to is free to share the source code with anyone they want to.
That said this is also the problem with past SRPM saga in that threatening to end a subscription isn't technically preventing the sharing, but against the spirit. But they don't even have the same motivations here anyways, because no one cares about bug-for-bug compatibility with a weird collection of each clients unique set of out-of-date Spring/Hibernate dependencies on WebSphere/JBOSS.
Re:There it is (Score:5, Insightful)
They know the letter of OSS, not the spirit.
Nope, just charging for distribution (Score:2)
An abominable abuse of open source.
Nope. Completely within the open source rules. They are charging for distribution of the binary, which is allowed. The only problem would be if they did not make the source code available.
allowing enterprises to integrate secure patches directly into their existing software supply chains with enterprise-grade validation and lifecycle management
Basically it sounds like they are offering an administration service. And open source allows for you to do it yourself or pay someone else to do it for you. Again, Open Source is about the source code being freely available, not money changing hands in other respects.
IBM "and" Red Hat? (Score:3)
They're not independent entities.
Re: (Score:2)
... but they have separate sets of engineers, and this clarifies that engineers from both organizations will be included.
Re: (Score:3)
Red Hat is still pretty independent. Call them Big Purple Hat on a forum or Reddit and you'll get Red Hat engineers bristling.
The IBM side still has a bunch of products [wikipedia.org] like WebSphere that they like to run on RHEL or OpenShift and Red Hat has JBoss. Throw in Red Hat doing a lot of backports on upstream projects already and it's a pretty big intermix between divisions.
So with this targeted at updating Maven POMs first, makes sense to get both names on the presser if it'll be for both the big iron products.
Re: (Score:2)
How about if I call them DeadRat? Is that OK?
Re:IBM "and" Red Hat? (Score:5, Interesting)
From the outside, Red Hat operates as a largely independent subsidiary of IBM. I think it's only in the last year or two that they've even been merging the "business operations" parts like HR.
In some ways, it feels like IBM buying Red Hat was as much about keeping anybody else from buying them (and changing them). Since Red Hat was a public company, anybody with enough cash/stock could have tried to take them over (and it sounds like there were some other interested parties), so IBM making a good offer kept them operating as Red Hat. Imagine for example if Oracle had bought them instead... things would be quite different.
Re: (Score:2)
Re: (Score:2)
In some ways, it feels like IBM buying Red Hat was as much about keeping anybody else from buying them (and changing them).
Yes, because IBM wanted to change them — from not violating the GPL, to violating the GPL. And that's exactly what they are doing by placing additional restrictions on the redistribution of sources delivered to customers.
The morality of Open Source. (Score:4, Insightful)
Any funding for Open Source Maintainers?
Or is this another example of how companies refuse to fund Open Source, and will only pay if it directly benefits themselves?
I doubt the morality of Open Source.
Re:The morality of Open Source. (Score:4, Interesting)
Any funding for Open Source Maintainers?
You mean, besides all the salaries that IBM and Red Hat pay to maintainers[*]? A lot of the maintainers are funded via salaries by large corporations (not just IBM/RH). How many maintainers' salaries do you pay for?
While its true that companies typically only fund/hire the parts of FLOSS that they benefit from, can you blame them? If you're favorite part of FLOSS isn't funded, why is it someone else's fault?
[*] disclosure - I'm one of the maintainers being 100% funded by Red Hat.
Re: (Score:2)
Let's also be fair that a summary on a non-technical press release about subscription service to AI patches is undoubtedly going to get backlash without a deep dive into the actual situation. "Why not release the fixes upstream or support the upstream" seems like an easy answer when it's not in the release pointing out that both of those things are already happening or going to happen. Just with a paid service to get the backports right away.
Re: (Score:2)
Re: (Score:2)
Missing Important Technical Bit (Score:3, Informative)
When a vulnerability is identified, Project Lightwell backports fixes to the exact dependency versions already tested and deployed in production, delivering patched artifacts without requiring upgrades. No access to source code is required. Project Lightwell operates on dependency manifests such as pom.xml, ensuring your application code remains fully within your environment while patched artifacts are delivered to repositories you control.
Initial ecosystem focus includes Maven/Java, where regulated industries have the greatest need for pinned-version remediation
These capabilities will be offered through commercial subscriptions
Java backport subscription updating Maven poms with backported deps, but with IBM AI branding. So it's just expanding the backporting beyond OS packages starting with Java. Makes sense for large enterprise stuck on not being able update dependencies quickly, but even then 5 billion USD seems like a lot for that service even at enterprise rates. The press release trying to strike a comparison to Mythos/Glasswing however is priceless to the investor relations team.
Just like their backports for RHEL end up benefiting upstream, I wish them well. And if they can make a profit off tacking on another subscription to WebSphere for dinosaurs and then contributing back, everybody wins.
Impossible (Score:5, Interesting)
I have a student who is writing a paper about exactly this topic. Almost any large project nowadays uses dozens of external libraries, which in turn use dozens or hundreds more. This creates a huge, almost unknowable dependency tree. Any of those libraries may be updated at any time, and be pulled into a new release of your software. Any of those libraries may contain a security flaw that could be discovered and exploited. Any of those libraries may be deliberately compromised - and how would you know?
As a current example, consider the recently discovered flaw in Starlette [arstechnica.com], which the developer claims is downloaded 325 million times per week. Never heard of Starlette? That's because it is a fundamental building block buried deep in that dependency tree. Despite the title of the article, this flaw affects far more that just AI apps.
IMHO, the best solution - if you can afford it - is to write as much of your own code as you can. Sure, you may also have security flaws, but you are a far smaller and less interesting target. If there is a better solution, I don't know what it is...
Re: (Score:3)
Your example is core Python web networking. Expecting anyone to fully maintain their own full networking stack is bonkers.
There is definitely a problem in the current situation [xkcd.com], but no one is going to be able to afford own whole entire stack end-to-end stack themselves. From the kernels through last little details in app deps all have this issue.
Re: (Score:2)
So it's the Canonical business model (Score:2)
What do you mean, "IBM and Red Hat?" (Score:2)
What do you mean, "IBM and Red Hat?"
IBM has owned Red Hat since 2019;
AI assisted? Good luck with that... (Score:2)
I guess they are not serious about actually securing anything.