Red Hat: Open Source Security Needs More Than Vulnerability Counts

Red Hat is calling for a broader approach to open-source security, one that goes beyond vulnerability counts and severity ratings to examine practical exposure, dependency relationships, and remediation speed.

In its inaugural Open Source Security Signals report, published through IBM Newsroom on October 15, 2026, Red Hat examines how security teams can identify the vulnerabilities that matter most, understand how weaknesses connect across software environments, and deliver fixes to the applications that depend on them.

The report brings together several areas of concern: vulnerabilities identified with frontier AI models, a software supply-chain compromise involving the Python project Ultralytics, observations from Red Hat's Lightwell package analysis, and a modeled assessment of the potential cost of independently remediating a vulnerability affecting JAXB in Java applications.

Its central message is that identifying a vulnerability is only one stage of the security process. Teams must also determine whether an attacker can reach it, understand the surrounding environment, choose an appropriate remediation, and get that fix into production.

The report organizes its findings around three themes:

• Risk depends on context. Severity ratings need to be considered alongside exploitability, reachability, dependencies, privileges, and existing controls.

• Security requires continuous work. Vulnerability research and software fixes evolve as maintainers investigate issues and publish updates.

• Reusable remediation creates leverage. A validated fix for a widely used component can reduce repeated engineering work across organizations.

Why Vulnerability Severity Is Not Enough

Severity ratings help security teams compare vulnerabilities, but they do not always indicate how much risk a particular organization faces.

A critical flaw may have limited practical exposure in an environment where the affected component is unreachable or protected by effective controls. Conversely, a vulnerability with a lower severity rating could become more dangerous if an attacker combines it with another weakness, abuses compromised credentials, or takes advantage of permissive configuration.

Red Hat argues that this distinction matters as AI-assisted vulnerability discovery advances. Security teams may need to evaluate more findings while also considering whether an attacker can combine individual weaknesses into a more consequential attack path.

An IBM X-Force analysis cited in the report examined 223 publicly reported vulnerabilities discovered using frontier AI models. The analysis found:

• 55.2% were rated High or Critical.

• 91.0% were remotely accessible.

• 25.6% supported code execution.

These figures describe the vulnerabilities included in that analysis. They should not be interpreted as a measure of all vulnerabilities discovered by AI or as evidence that every remotely accessible flaw is exploitable in every environment.

For defenders, the practical challenge is to distinguish findings that represent meaningful exposure from those that are less reachable or better contained. That requires looking beyond a vulnerability's individual score to the route an attacker could take through the wider system.

The Ultralytics Incident Shows Why Attack Paths Matter

The December 2024 compromise of Ultralytics, a widely used Python project, illustrates how an attack can target the infrastructure used to build and distribute software rather than the publicly visible source code alone.

According to Red Hat's report, attackers compromised the project's GitHub Actions build environment and inserted malicious code into packages published to the Python Package Index (PyPI). The injected code was not present in the project's public GitHub source, and four affected releases were subsequently removed from PyPI.

The incident highlights an important distinction between inspecting source code and verifying the integrity of the complete software delivery process. A repository can appear normal while a compromised build environment produces altered release artifacts.

Several PyPI controls helped investigators narrow their investigation. Trusted Publishing, provenance attestations, and transparency logs provided evidence about how the affected packages had been published. Investigators were able to trace the activity to the project's legitimate GitHub Actions workflow, with the compromise ultimately attributed to the GitHub Actions cache.

This case demonstrates why supply-chain security needs to cover more than source repositories. Build systems, publishing credentials, package registries, release artifacts, and provenance records can all influence whether the software delivered to users matches the code developers intended to release.

For security teams, the lesson is to examine the complete route from development to deployment. Repository security remains important, but it should be supported by controls that establish how artifacts were built, where they came from, and whether their release history is trustworthy.

Open-Source Dependencies Create a Large Security Surface

Modern applications rarely rely on a single library or framework. They combine direct dependencies with additional components pulled in by those dependencies, creating chains that can extend far below the application layer.

Red Hat's Lightwell observations offer one view of this ecosystem. As of October 1, 2026, the company reported that Lightwell had delivered more than 30,000 validated open-source package versions across Java and Python.

The analyzed packages span application frameworks and supporting software for networking, serialization, authentication, cryptography, observability, cloud services, package management, build tooling, AI, and agent development.

AI applications add further layers to this structure. Model SDKs may sit alongside orchestration frameworks, agent-development tools, Model Context Protocol (MCP) components, cloud services, and telemetry libraries. Each layer can introduce additional dependencies that organizations must identify and maintain.

A component may therefore affect applications even when developers do not use it directly. A vulnerability in a transitive dependency can flow into an application through another library or framework.

That makes software composition analysis and dependency visibility important parts of vulnerability management. Teams need to know which components are present, which versions are deployed, and how those components connect to application functionality.

A Fix in One Project Can Affect Many Others

The interconnected nature of open-source software means that a vulnerability in a foundational project may require work across multiple downstream components.

Red Hat points to Netty's 4.1.133.Final security release in May, which addressed 12 CVEs affecting several areas of the project, including HTTP, HTTP/2, HTTP/3, MQTT, DNS, Redis, proxy, and compression functionality.

This example illustrates the breadth of functionality that can be connected to a shared software component. Organizations using Netty may need to determine whether their applications include affected functionality, identify the relevant dependency versions, and apply a suitable update.

The challenge is not limited to the upstream project. A fix must also reach the applications that depend on the affected component. Teams may need to update direct dependencies, resolve transitive dependency constraints, run regression tests, and deploy the changes through established release processes.

Open-source development can help distribute the benefits of remediation. A fix published by one maintainer can be reused by many downstream users instead of being independently recreated by each organization.

However, shared availability does not guarantee shared adoption. Each organization still needs to establish its exposure and integrate the fix safely.

Why Fixes Must Reach Older Software Too

Enterprise software does not always move at the same pace as upstream projects.

Maintainers may publish a new release quickly, while organizations continue running older versions because of application compatibility, operational constraints, change-management requirements, or upgrade costs. In these environments, a new upstream fix may not immediately resolve the risk.

Red Hat discusses a sequence involving the Spring project in which researchers disclosed an additional vulnerability less than two weeks after an earlier issue. The later vulnerability affected versions through 5.3.18, and the Spring team released version 5.3.19 with a fix.

The second issue was found during investigation of the first. The sequence illustrates how vulnerability research can uncover related weaknesses and lead to further disclosures and fixes.

It also raises a practical question: what happens to organizations still using affected older versions?

Backporting a patch to an earlier software branch is not guaranteed. Moving to a newer version may require compatibility testing or changes that are difficult to schedule in critical production systems.

This creates a gap between the availability of a fix and its actual deployment. Security teams may know that a vulnerability has been addressed upstream while their own applications remain exposed.

Red Hat identifies remediation velocity as a useful way to assess open-source security health. Relevant questions include how quickly a risk is understood, how soon a reliable fix becomes available, and how long downstream organizations take to deploy it.

These measures provide a broader picture than vulnerability counts alone because they focus on how quickly security improvements reach the systems that need them.

Red Hat Models the Potential Value of Reusable JAXB Remediation

To illustrate how shared fixes could reduce duplicated engineering work, Red Hat developed a model focused on JAXB, an open-source Java implementation of XML binding.

JAXB was included in the Java Development Kit through Java 8. Starting with Java 11, applications that need JAXB must obtain it separately, either as a direct dependency or through another component.

Red Hat's model estimates the potential reach of a JAXB vulnerability across two populations: applications using Java 8, where JAXB was included in the JDK, and newer Java applications that may include JAXB as a separate dependency.

The company begins with a modeled baseline of 3 million production Java applications worldwide. It explicitly describes this as an estimate rather than an observed count of all production Java applications.

Step 1: Estimate the Java 8 population

New Relic observed Java 8 declining from approximately 33% of monitored Java applications in 2023 to 28.8% in 2024. Extending that decline proportionally through 2026 gives an estimated share of about 22%.

Red Hat uses a more conservative 20% assumption for its model.

Applying that share to the 3 million application baseline gives an estimated 600,000 Java 8 applications.

The model then assumes that 90% use XML functionality that could rely on JAXB, resulting in an estimated 540,000 Java 8 applications potentially using JAXB.

These are modeled estimates, not a measured inventory of real deployments.

Step 2: Estimate JAXB usage in newer Java applications

The remaining 80% of the modeled population represents 2.4 million applications using newer Java environments.

Because JAXB is no longer included in the JDK from Java 11 onward, Red Hat models its presence in 25% of these applications. The model divides this into approximately 10% using JAXB through direct dependencies and 15% through transitive dependencies.

That produces an estimated 600,000 newer Java applications using JAXB.

Red Hat says these assumptions are informed by JAXB usage in Maven Central and CI/CD pipelines, Java modernization work involving tools such as Moderne and OpenRewrite, and research from Endor Labs and Black Duck on transitive dependencies.

Step 3: Estimate how many could retain vulnerable versions

A dependency being present does not mean an application is vulnerable. The version in use also matters.

Red Hat applies separate vulnerable-version persistence assumptions to the two modeled populations:

• Newer Java applications: A 20.5% persistence rate applied to 600,000 applications using JAXB.

• Java 8 applications: A 30% persistence rate applied to 540,000 applications using JAXB.

Using those stated assumptions, the model implies approximately 123,000 newer Java applications and 162,000 Java 8 applications could retain vulnerable versions. Together, that is a calculated estimate of 285,000 applications.

This combined figure is derived from the report's inputs. It is not a directly observed count of vulnerable production applications, and it does not establish that every application in the modeled population would be exploitable.

Step 4: Model the cost of separate remediation efforts

Red Hat estimates that remediating a vulnerability independently could require about 20 engineering hours per application. The work could include assessing exposure, developing or applying a fix, running XML schema regression tests, and moving the change through deployment.

Using an assumed fully loaded engineering cost of $125 per hour, the model assigns $2,500 in engineering effort per application.

Applied to the calculated population of 285,000 applications, those assumptions imply a potential gross engineering cost of $712.5 million if each application required that level of separate remediation work.

This is a derived scenario based on Red Hat's model inputs, not measured spending by enterprises. It also should not be read as guaranteed savings from a reusable fix. Organizations would still need to assess their own exposure, integrate the remediation, test compatibility, and deploy the change.

The value of reuse is that a validated fix can reduce the need to repeat some of the same engineering work across organizations facing the same underlying vulnerability.

Remediation Time Also Affects Exposure

Engineering cost is only one part of the model. The time between a fix becoming available and its deployment can also affect how long an application remains exposed.

Red Hat cites two external research findings:

• Edgescan's 2026 Vulnerability Statistics Report found an average remediation time of 54.81 days for high- and critical-severity application and API vulnerabilities.

• Veracode's 2026 State of Software Security research found a 358-day remediation half-life for third-party flaws identified through Software Composition Analysis.

These figures use different measures and should not be treated as directly interchangeable. Red Hat uses the 54.81-day average as the more conservative baseline for its model.

The report then considers an accelerated scenario in which a fix moves from availability through enterprise ingestion and deployment in 10 days. Red Hat explicitly describes this as a modeled scenario, not a measured Lightwell customer result.

Compared with the 54.81-day baseline, the 10-day scenario represents a calculated reduction of 44.81 days, or approximately 81.8% in elapsed time. That comparison illustrates the potential benefit of faster remediation, but it does not establish that every organization can achieve that timeline.

Actual deployment speed depends on application complexity, compatibility testing, change approvals, and release architecture.

Three Security Signals From Q3

Red Hat's report concludes with three connected observations about how open-source security works.

1. Risk depends on context

Severity is a useful starting point, but security teams also need to consider whether a vulnerability is reachable, how it relates to other dependencies, what privileges are available, and which controls constrain an attack.

Understanding the possible attack path helps organizations decide which issues deserve the most urgent attention.

2. Security is an ongoing process

Open-source projects continue to evolve as researchers find new vulnerabilities, maintainers investigate related weaknesses, and new fixes become available.

Because enterprise applications often combine old and new dependencies, a fix must reach every affected part of the software environment, not just the newest upstream release.

3. Reusable fixes can reduce duplicated effort

Open source allows security research and remediation to benefit many organizations. When a fix is validated and can be safely adopted downstream, organizations may avoid repeating parts of the same investigation and engineering process.

That does not remove the need for local testing or deployment. It creates an opportunity to reuse the work that has already been done.

What This Means for Enterprise Security Teams

Analysis: Red Hat's report reflects a wider shift from counting security findings toward managing the conditions that make vulnerabilities dangerous. As AI-assisted discovery expands, the number of findings alone may provide less value unless teams can determine which weaknesses are reachable, exploitable, and connected to other parts of their environment.

For enterprise teams, three practical priorities follow from the report.

First, combine vulnerability severity with asset and dependency context. Security teams should understand where affected packages are deployed, whether vulnerable code paths are reachable, and what controls limit an attack.

Second, treat build and publishing systems as part of the software supply chain. The Ultralytics incident demonstrates why repository inspection should be supported by artifact provenance, protected build infrastructure, and reliable release records.

Third, measure the path from disclosure to deployment. A patch that exists upstream provides limited protection to an application that cannot consume it. Remediation processes should account for testing, backporting, compatibility constraints, and deployment timelines.

The JAXB model also highlights the potential economic importance of common dependencies. However, its global application counts and financial implications are based on assumptions rather than a direct census of deployed applications. Organizations should use their own dependency inventories and remediation data when estimating local exposure and cost.

Conclusion

Red Hat's first Open Source Security Signals report argues that open-source security depends on more than discovering vulnerabilities and assigning severity ratings.

AI-assisted research increases the importance of understanding practical exploitability. Supply-chain incidents show that attackers can compromise trusted build infrastructure without changing the public source code. Deep dependency trees make it difficult to determine where a vulnerability is present, while older software can remain exposed after an upstream fix becomes available.

Red Hat's JAXB model illustrates how reusable remediation could reduce duplicated engineering effort across a large software ecosystem. Its results remain estimates based on stated assumptions, not observed global remediation costs or guaranteed savings.

The broader lesson is that effective open-source security requires a complete process: understand the risk, trace the affected dependencies, produce or adopt a reliable fix, and deliver that fix to the software that needs it. Measuring how well that process works can provide a more useful view of security health than vulnerability counts alone.