- Red Hat says its Lightwell project has remediated over 400 novel vulnerabilities in foundational Java libraries since June, and the Clearinghouse is now generally available.
- Red Hat aims a premium tier at customers who run older, pinned software versions in production, where a fix for the newest release does not help.
- Ask your vendors which versions they patch, how fast, and how they prove what was built. The report gives no breakdown of the 400.
Finding the bug is only part of the job
A security report ends with a fix. For companies running pinned versions, that fix can arrive on the wrong version. The patch lands in the newest release, but the business runs an older one that passed testing and that nobody wants to disturb.
That gap is what Red Hat's Lightwell project is built around. Infosecurity Magazine reported on October 6 that Red Hat says it has fixed more than 400 novel flaws in foundational Java libraries since Lightwell launched in June. The Lightwell Clearinghouse, which went through a pilot, is now generally available.
The lesson here is that a flaw is only closed when the version in your production system is fixed. Red Hat is selling the repair work, not just the discovery.
What Red Hat announced
Gunnar Hellekson, who runs Lightwell at Red Hat, said AI agents "shifted the threat landscape overnight, exploiting old dependencies at machine speed." That is a vendor's view, and the report offers no data behind it. He added that AI agents do not care whether a codebase is ten years old or considered stable.
Hellekson argued that discovery is just one part of the job. The larger task, he said, is putting fixes into live production applications so customers need not trade security for uptime.
The report says Red Hat and IBM were among the first to respond to the flood of AI-powered vulnerability reports. They built ways to confirm which flaws are genuine, and to spare open-source maintainers from noisy or inaccurate submissions.
Eleven financial-sector firms are named as early adopters, among them Citi, Goldman Sachs, Visa and Wells Fargo. The report does not say how they use the service.
How a backport works
A backport takes a fix written for a new release and rebuilds it to fit an older one. Many companies run "pinned" versions, meaning they lock a dependency at one release so nothing changes unexpectedly. Upgrading can break things, so pinning is common. It also means upstream fixes may not reach them.
Lightwell Clearinghouse Premier is aimed at those customers. It is the more advanced tier, offered to a chosen group of large customers whose live systems stay on locked versions. Those customers can submit a specific open-source flaw for priority review and get a fix that works on the older release they still use. Per the report, the steps run like this:
A customer reports a flaw tied to a specific package and version. Red Hat triages it for severity and whether it applies. It writes a patch for that exact supported version and coordinates upstream so the fix suits the project. Red Hat then builds the package on its own infrastructure and signs it, so the customer has a record of what was built. The customer deploys the binary instead of redoing the remediation and validation themselves.
The other product, Lightwell Network, is available from launch. It supplies signed binaries, source code and compliance records, including software bills of materials (SBOMs). An SBOM is a parts list of what a piece of software contains.
Red Hat says delivery runs through secured repositories that plug into existing workflows. In its words, organisations can address hard or novel vulnerabilities "without replacing their current scanners, repositories, CI/CD pipelines or validation processes."
What the report does not say
The 400 figure comes from Red Hat. The report gives no split by severity, library or time to fix. It does not say how many fixes reached customers, or how many were backports to older versions.
It also names no pricing for the Premier tier. Treat this as one vendor's account of its own programme. It is not an independent measure of how much open-source risk has fallen.
Questions to put to your team
Start with an inventory. Which open-source libraries do we run in production, and which of them are pinned to older versions? Your SBOMs should answer this.
Next, ask what happens when a flaw lands in a pinned version. Does the fix come from the upstream project, a vendor or our own engineers? How many days does each route take?
Then ask about proof. Can we show which binary was built, by whom and from what source? Signed and attested builds exist to answer that question.
Last, check whether any new service fits your current scanners and pipelines. Red Hat says Lightwell does. Confirm it in a trial before you rely on it.
The 400 figure does not say how many fixes were backported to older versions. That is the number a company running pinned software most needs, so ask for it before you count the 400 as protection.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Infosecurity Magazine.
