IBM's "Project Lightwell" [LWN.net]

IBM has sent out a press release touting a claimed $5 billion investment into an operation called Project Lightwell:

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.

Toward the bottom, it does also mention sharing vulnerability information with upstream projects.

to post comments

I hope they do something useful

Posted May 28, 2026 14:26 UTC (Thu) by davecb (subscriber, #1574) [Link] (1 responses)

Merely finding bugs and then producing buggy patches is already a problem. This might be a good use for formal methods. I'd wish each patch to contain a literate explanation and a formal proof that the old code is wrong, according to some criteria, and the new code is tight, not adding additional bugs.

I just asked Claude to analyze a moving average implementation on go, and express it as syllogisms. It replied with things like:

Syllogism 4: Incomplete Buffer Handling
Major premise: All sliding window calculators must distinguish between full and partial buffers.
Minor premise: MovingAverage tracks slotsFilled and uses filledValues() to return only valid data.
Conclusion: Therefore, MovingAverage correctly handles calculations on both partial and full buffers.

It’s both bland and verbose, but I can look at it and say “this program does what I wanted”.

I hope they do something useful

Posted May 29, 2026 7:28 UTC (Fri) by daenzer (subscriber, #7050) [Link]

One issue being that LLMs are great at generating something like that which looks perfectly convincing at first glance, but when taking a closer look, turns out to be nonsense.

Sharing vulnerability information and fixes with upstream

Posted May 28, 2026 15:01 UTC (Thu) by hailfinger (subscriber, #76962) [Link] (6 responses)

Sharing this with upstream will soon (December 2027) be an obligation of every manufacturer serving the market in the EU. I'm glad to see that some actors are planning to do this even before being forced by the law.

Quoting the EU Cyber Resilience Act:
> Preamble, Recital 34: [...] Where, in the exercise of due diligence, the manufacturer of the product with digital elements identifies a vulnerability in a component, including in a free and open-source component, it should inform the person or entity manufacturing or maintaining the component, address and remediate the vulnerability, and, where applicable, provide the person or entity with the applied security fix.
> Chapter II, Article 13, No. 6: Manufacturers shall, upon identifying a vulnerability in a component, including in an open source-component, which is integrated in the product with digital elements report the vulnerability to the person or entity manufacturing or maintaining the component, and address and remediate the vulnerability in accordance with the vulnerability handling requirements set out in Part II of Annex I. Where manufacturers have developed a software or hardware modification to address the vulnerability in that component, they shall share the relevant code or documentation with the person or entity manufacturing or maintaining the component, where appropriate in a machine-readable format.

Sharing vulnerability information and fixes with upstream

Posted May 28, 2026 17:49 UTC (Thu) by archaic (subscriber, #111970) [Link] (1 responses)

Perhaps decades of reading RFCs has tainted my use of language, but I'm not sure how strong of a claim one can make based on the use of "should" and "shall" instead of "must". At the very least, lawyers can find all manner of wiggle room there.

Sharing vulnerability information and fixes with upstream

Posted May 28, 2026 18:39 UTC (Thu) by hailfinger (subscriber, #76962) [Link]

Good point. At least in the CRA, "shall" and "should" are used in the RFC 2119 meaning, i.e. "shall" is equivalent to "must": https://datatracker.ietf.org/doc/html/rfc2119#section-1
Now in the quoted text there is both "should" and "shall". Fortunately, the "should" is only in the Preamble (which is there to clarify what the law is intended to do), but the legally binding text in subsequent chapters uses "shall".

Sharing vulnerability information and fixes with upstream

Posted May 28, 2026 18:05 UTC (Thu) by linuxrocks123 (subscriber, #34648) [Link] (3 responses)

Fun fact, Britain and France each have a lower GDP per capita than Mississippi, which is the poorest state in the United States! It's so fun to see how coercive government policies like the one you quoted can affect national prosperity!

You know better

Posted May 28, 2026 18:12 UTC (Thu) by corbet (editor, #1) [Link]

This is not the kind of place for that kind of comment. Please take it to one of the many places on the net where such discussion is welcome.

Sharing vulnerability information and fixes with upstream

Posted May 28, 2026 20:26 UTC (Thu) by dskoll (subscriber, #1630) [Link] (1 responses)

And yet, Britain and France have much higher life expectancy at birth than Mississippi (81.3 and 83.33 vs 72.6), much lower infant mortality rates (4.5 and 4.4 vs 9.65/1000), and much higher HDIs (0.946 and 0.920 vs 0.868).

So yes, when you are only concerned with GDP per capita, you optimize for the wrong things and your populace can be significantly worse off.

Sharing vulnerability information and fixes with upstream

Posted May 28, 2026 23:28 UTC (Thu) by linuxrocks123 (subscriber, #34648) [Link]

Direct reply to you: https://soylentnews.org/comments.pl?noupdate=1&sid=67...

Further discussion here please: https://soylentnews.org/~linuxrocks123/journal/20404