From CVE to Production Fix: Red Hat Lightwell at Summit Connect

In the morning keynote of Red Hat Summit: Connect 2026 Utrecht, Vincent Danen introduced Lightwell, “a clearinghouse for open source vulnerabilities”. At 14:00 I went to the breakout that goes deeper: “From CVE to Production Fix: Upgrade-Free Remediation with Red Hat Lightwell Network”. The agenda summed it up as “Fix CVEs without forced upgrades”: Red Hat TPA (Trusted Profile Analyzer) and Lightwell Network scope the blast radius and backport patches “to the versions you already run”.

Two speakers from Red Hat: Darryn Mitchell, EMEA FlightPath Lead and Principal Program Architect, and Nikhil Sharma, Specialist Solution Architect for the Application Platform. They started with the room rather than with slides.

How long does a fix take?

The first Slido poll asked: “For an applicable, non-critical CVE, how long does it typically take from publication to a verified fix in production?”

When I took the photo there were 42 answers. The biggest word in the cloud was 1 week, followed by 30 days, 2 days, 1 month and 3 weeks, then 4 weeks and 1 year. The edges are the interesting part: 51 minutes, 2 hours and 14 hours at one end; 9 months, “Quarter” and “Someday” at the other.

The keynote had already put numbers on this from three sides. Marcel Timmer’s slide gave 24.21 hours as the mean time to deploy a critical software fix across affected production systems; Andrew Brown’s chart put the mean time to exploit at 18 hours in 2026; Vincent Danen’s slide gave more than 40 days on average from patch to production. The room’s answers spread across all of them, for a question about non-critical CVEs. There is no shared baseline, and that is the speakers’ starting point.

Do you know what is deployed?

The second poll went one step earlier: “For what percentage of your production applications can you identify the exact direct and transitive dependencies in the deployed build?”

With 44 answers, the biggest was 50%, and the next biggest was 0. Around them: 30%, 10%, 100%, 80%, 5% and 1%, plus a few jokers (“1248%”, “Null”).

This is the precondition for everything else. Before you can fix a vulnerable library, you need to know which deployed builds contain it, directly or through a dependency of a dependency. If a typical organization in the room can say that for about half of its applications, the other half is guesswork.

What Lightwell does

My photos of the session stop after the opening polls, so for the product itself I go back to the two Lightwell slides from the keynote:

• The clearinghouse. Vulnerable code in open source projects goes through the Lightwell pipeline and comes out as patched Lightwell libraries. A secure CDN serves them to clearinghouse members and network members, who feed vulnerabilities and SBOMs back into the pipeline. The patched libraries also go back to the open source communities.
• Only part of the solution. The second slide, “Lightwell is only part of the solution: security remediation + rapid deployment”, places Lightwell remediation and its repositories in front of the application build (a trusted software supply chain) and the deployment (automation and trusted platforms), on the way to “secured apps in production”, under the same high risk, caution and safe scale.

In other words, patched libraries that arrive already backported to the version you run take the upgrade out of the critical path. They don’t take away the other half: knowing where the library is deployed, which is what the second poll was about.

Thanks to Darryn and Nikhil for starting with the audience’s numbers.

Related

• Red Hat Summit Connect Utrecht: Private AI and a 24-Hour Window, the keynote with the Lightwell slides