Red Hat's first Security Signals report argues for remediation speed over CVE counts

Serguey Asael Shinder17 October 2026, 08:323 min read

Red Hat published the first edition of a quarterly report, "Open Source Security Signals | Q3 2026", on 15 October 2026. Its argument is that vulnerability counts say little about risk, and that the useful measures are whether a finding actually exposes a system, how a fix travels through dependency trees, and how fast it reaches the software that needs it. The report draws on Red Hat's Lightwell service, which it says has delivered more than 30,000 validated open source package versions across Java and Python as of 1 October. Readers should keep that context in mind: the report's conclusions point towards the kind of reusable, validated fixes Lightwell sells.

Signal 1: severity is not the whole story. The report says Critical and Important issues should be fixed as soon as possible, but that lower-severity weaknesses deserve more scrutiny because several modest problems can combine. It cites an IBM X-Force analysis of 223 publicly reported vulnerabilities found with frontier AI models: 55.2% were High or Critical, 91.0% remotely reachable and 25.6% allowed code execution. As a supply-chain example it recalls the December 2024 compromise of the Python project Ultralytics, where malicious code reached four PyPI releases through the project's build environment rather than its public source; PyPI's Trusted Publishing, provenance attestations and transparency logs helped investigators narrow the cause to the GitHub Actions cache.

Signal 2: fixes have to travel. One upstream fix often touches several components. The report's example is Netty 4.1.133.Final, a May security release that addressed 12 CVEs across HTTP, HTTP/2, HTTP/3, MQTT, DNS, Redis, proxy and compression code. Fixes also have to reach older versions still in production: Spring Boot 2.7.18 (November 2023) ended open source support for the 2.x line after 5.5 years and 121 releases, and Spring Framework 5.3.19 followed 5.3.18 within two weeks in 2022 because the investigation of Spring4Shell (CVE-2022-22965) turned up a second issue.

Signal 3: one fix, many users. The centrepiece is a model of a hypothetical vulnerability in JAXB, the Jakarta XML Binding implementation that shipped in the JDK up to Java 8. Starting from an estimate of 3 million production Java applications, Red Hat assumes 20% run Java 8 with 90% of those using JAXB (540,000), and 25% of the newer 2.4 million include JAXB as a dependency (600,000) — 1.14 million in total. Applying vulnerable-version persistence rates of 30% and 20.5% gives 285,000 potentially affected applications. At 20 engineering hours and $125 an hour each, independent remediation would cost $712.5 million, or 5.7 million hours. Against an industry average of 54.81 days to fix high and critical application flaws (Edgescan), a 10-day scenario would save 44.81 days per application, 12.8 million exposure-days in total.

Red Hat labels all of these as modelled estimates, and says the 10-day figure is a scenario, not a measured result for Lightwell customers. Each step rests on an assumption taken from third-party surveys, so the totals show orders of magnitude rather than measurements.

Source: Red Hat, "Open Source Security Signals | Q3 2026" — https://www.redhat.com/en/blog/open-source-security-signals-q3-2026