Open Source Security Signals | Q3 2026

Open Source Security Signals | Q3 2026

Open source has become the foundation of modern software because it works. Shared innovation, transparent development, global communities, and broad reuse let software advance at a scale no single organization could achieve alone. Security is part of that model. Open source development makes code available for inspection. Researchers can test it. Communities can improve it. Fixes can benefit everyone who depends on the software.

Open source has become the foundation of modern software because it works. Shared innovation, transparent development, global communities, and broad reuse let software advance at a scale no single organization could achieve alone.

Security is part of that model. Open source development makes code available for inspection. Researchers can test it. Communities can improve it. Fixes can benefit everyone who depends on the software.

The scale that makes open source powerful also makes security more complex. Modern applications can rely on hundreds or thousands of components linked through deep dependency trees. Understanding their security requires more than counting vulnerabilities.

How many vulnerabilities were disclosed? How many were Critical? How many packages were affected? Those measures matter, but they don't answer a larger question

An ostensibly critical vulnerability may pose little practical exposure in a specific environment. A lower-severity weakness may become far more serious when paired with another vulnerability. Compromised credentials or a permissive configuration can change the picture, too.

Finding a vulnerability is only the start. Security teams must understand the risk, determine whether action is needed, find a usable fix, then get that fix to the software that needs it.

In this inaugural edition of Open Source Security Signals, we look at three parts of that process:

Severity tells us something useful about a vulnerability. Practical risk, especially amid rising agentic AI threats, depends on much more. Critical and Important vulnerabilities should always be fixed as soon as possible, but lower-level vulnerabilities must now also face more scrutiny, especially as advanced agents can chain them together to create much more damaging attacks.

It's not a surprise that AI is raising the stakes for prioritization. An IBM X-Force analysis of 223 publicly reported vulnerabilities discovered using frontier AI models found that 55.2% were High or Critical severity, 91.0% were remotely accessible, and 25.6% supported code execution. As AI expands what's possible in vulnerability discovery, simply identifying and scoring more vulnerabilities won't be enough. Defenders need context to determine which findings create meaningful exposure, as well as the potential pathways a vulnerability can take.

Recent attacks show why the full path matters.

The December 2024 compromise of the popular Python project Ultralytics shows why the full path matters. Attackers compromised the project's GitHub Actions build environment and injected malicious code into packages published to PyPI. The injected code was not present in the project's public GitHub source. Four affected releases were ultimately removed from PyPI.

The incident also showed the value of controls elsewhere in the software supply chain. PyPI's Trusted Publishing, provenance attestations, and transparency logs helped investigators determine that the first malicious packages had been published through the project's legitimate GitHub Actions workflow, narrowing the investigation to the source repository or build process. The attack was eventually traced to the GitHub Actions cache.

The incident shows how trusted development infrastructure can become part of an attack path. It also shows why understanding the full path, and the controls operating along it, matters.

Answering those questions requires more context. Teams may need to consider exploitability, reachability, known exploitation, dependency position, configuration, privileges, surrounding controls (defense in depth), or other weaknesses in the path.

Security teams need to know which vulnerabilities require action, why they matter in a given environment, and how urgently they should respond.

One of open source's greatest strengths is composability. Developers can build on the work of thousands of projects instead of recreating the same capabilities themselves.

Observations from our work in Lightwell give us a view into the open source packages and versions used in enterprise applications. The packages analyzed from Q3 show that interconnected system in practice.

As of October 1, Lightwell has delivered more than 30,000 validated open source package versions across Java and Python. Across that population, we see application frameworks plus the software beneath them: networking, serialization, authentication, cryptography, observability, cloud services, package management, build tooling, AI, and agent development.

Many of these capabilities bring their own families of supporting dependencies. Cloud services rely on SDKs plus supporting libraries. Observability reaches across frameworks, databases, network services, and application infrastructure. AI development is also forming its own dependency stack. Model SDKs sit alongside orchestration frameworks, agent tooling, MCP components, cloud services, and telemetry.

Much of this software sits below the application layer, including artifacts, packages, and dependencies. Developers may rarely interact with these components directly, yet applications rely on them every day. Open source lets innovation flow through those connections. Security work can travel through them, too.

When researchers discover a vulnerability in a foundational project, teams may need to assess several related components. The issue may also reach software farther down the dependency tree. Public open source releases show what this can look like.

Netty's 4.1.133.Final security release in May addressed 12 CVEs across several parts of the project, including HTTP, HTTP/2, HTTP/3, MQTT, DNS, Redis, proxy, and compression functionality.

Producing a fix is only part of the job. The fix also has to reach the software that needs it.

Open source provides leverage here. Research can be shared. Fixes can be reused. Improvements made in one project can strengthen software throughout the downstream ecosystem.

The same interconnectedness that distributes open source innovation can also distribute the benefits of open source security. Remediation also has to reach backward

That's normal in enterprise software. Upstream communities keep moving forward. Organizations adopt newer software on schedules shaped by their applications, infrastructure, and lifecycle requirements.

Less than two weeks later, the Spring team disclosed another vulnerability that affected versions through 5.3.18. The team released 5.3.19 with the fix. Spring researchers found the second vulnerability while investigating the earlier issue.

That sequence shows open source security in action. Investigation led to new knowledge. The team disclosed what it found. Another fix followed. But in a case like this, what about systems still running the earlier affected versions? Backporting patches to earlier versions is not a given. Upgrading to a newer, fixed build is not always feasible from a risk or operational standpoint, especially for critical production environments.

For enterprises, fixes may need to move across related dependencies. They may also need to reach older software still in use. Lessons from those discoveries can also improve newer software.

This makes remediation velocity a useful measure of open source security health.

How quickly can teams understand a meaningful risk? How quickly can they produce a sound fix? How long does it take for organizations that rely on the software to put that fix to work?

Those questions may tell us far more about how open source security works than vulnerability counts alone.

Open source creates leverage because many organizations rely on the same software. When a vulnerability appears in a widely used component, those organizations often face similar work: determine whether they are affected, obtain or develop a safe fix, test it, and move it into production.

A reusable remediation can reduce how often that work has to be repeated.

JAXB¹ shows the potential scale.

JAXB is a foundational open source implementation of XML binding in the Java ecosystem. It was included in the JDK through Java 8. Beginning with Java 11, applications that require JAXB need to obtain it separately, either directly or through another dependency.

We modeled both populations to estimate the potential reach of a JAXB vulnerability and the economic value of reusable remediation.

Combining industry research from New Relic and other ecosystem leaders, our model starts with an estimated 3 million production Java applications worldwide².

Estimating JAXB's footprint

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 produces an estimated share of about 22%. To remain conservative, our model uses 20%.

Because JAXB was built into Java 8, we apply a second assumption: 90% of the modeled Java 8 population uses XML functionality that could rely on JAXB.

The remaining 80%, or 2.4 million applications, represents newer Java environments.

Beginning with Java 11, JAXB was no longer included in the JDK. For this population, we model JAXB as present in 25% of applications: approximately 10% through direct dependencies and 15% through transitive dependencies.

Those assumptions are informed by continued JAXB consumption through Maven Central and automated CI/CD pipelines, Java modernization activity in tools such as Moderne and OpenRewrite, and research from Endor Labs and Black Duck showing how much of the modern application dependency graph can be transitive.

How many could be using a vulnerable version?

Knowing that a component is present does not mean that the application is vulnerable. The version in use matters.

We therefore apply different vulnerable-version persistence rates to the two JAXB populations.

For the 600,000 newer Java applications using JAXB, we apply a 20.5% vulnerable-version persistence rate, based on Sonatype research into modern builds consuming known-vulnerable minor or patch versions of active dependencies.

For the 540,000 Java 8 applications using JAXB, we apply a 30% vulnerable-version persistence rate, informed by OpenLogic research into older open source systems remaining unpatched because of operational and upgrade friction.

What would it cost to remediate them independently?

The value of a reusable fix becomes much clearer at that scale.

Drawing on software-security remediation research, our model estimates that an enterprise team could spend about 20 engineering hours per application to assess a vulnerability, develop or apply a fix, run XML schema regression tests, then move the change through its deployment process.

Using a fully loaded engineering cost of $125 per hour, informed by software developer compensation data from the U.S. Bureau of Labor Statistics software developer compensation data:

A reusable fix would not eliminate all downstream work. Organizations would still need to determine whether they are affected, consume the remediation, validate their applications, and deploy the change.

But a validated, backward-compatible remediation can reduce work that would otherwise be repeated across many organizations facing the same underlying vulnerability.

The value of time

Engineering effort is only part of the cost. The other factor is how long an affected application remains exposed while remediation takes place.

Edgescan's 2026 Vulnerability Statistics Report found that high- and critical-severity application and API vulnerabilities took an average of 54.81 days to remediate. For a third-party open source dependency such as JAXB, 54.81 days may be a conservative baseline. Veracode's 2026 State of Software Security research found that third-party flaws identified through Software Composition Analysis had a 358-day remediation half-life. While we use the more conservative 54.81 figure for our modeling, these numbers together illustrate the persistent remediation challenge around application vulnerabilities and third-party dependencies.

For this model, we assume an accelerated remediation scenario of 10 days from fix availability through enterprise ingestion and deployment. This is a modeled scenario, not an observed Lightwell customer benchmark. Actual deployment times will vary based on application complexity, testing requirements, change-management processes, and deployment architecture.

Compared with the 54.81-day industry baseline, that modeling suggests significant potential:

The leverage of one fix

These figures are modeled estimates. They show the potential value created when a fix for a common open source dependency can be reused across many applications.

Three signals from Q3

1. Risk depends on context

Severity matters. So do exploitability, reachability, dependency relationships, environment, controls, and the other weaknesses an attacker might use.

Understanding where an attacker can go next helps teams decide where to act first.

1. Security keeps moving

Open source makes software visible to researchers, maintainers, vendors, and users. That scrutiny produces new knowledge over time.

Modern applications span deep dependency trees plus several generations of software. Effective security requires fixes to reach the software that needs them.

1. Reusable remediation compounds

Open source lets security work benefit far more than one organization.

Research can be shared. Fixes can be reused. A solution developed for a common dependency can save downstream users from repeating the same work themselves.

About Open Source Security Signals

Open Source Security Signals examines how security works across the open source ecosystem, from identifying meaningful risk to assessing attack paths, producing fixes, and getting those fixes to the software that depends on them.

Future editions will track how that system changes over time: the vulnerabilities affecting open source, which risks require action, how quickly meaningful issues are assessed and remediated, where important dependencies may need greater resilience, and how much repeated work and exposure reusable fixes can reduce.

Our analysis draws on Red Hat security research and vulnerability-response data, analysis of open source packages and dependencies, additional industry security research and threat intelligence, and public ecosystem data. When a finding comes from a specific dataset or population, we'll identify what we studied, how we defined the measure, the period covered, and the limits of the data.

Open source has transformed how the world builds software. Its security comes from more than finding vulnerabilities. It also depends on how people assess what matters, stop viable attacks, fix problems, and share those improvements.

¹ Red Hat has approval of The Eclipse Foundation to reference JAXB in this report for illustrative purposes.
² Estimate of global production Java applications: We use 3 million applications as a modeled estimate for the enterprise Java production base. More than 418,000 enterprise-scale companies globally use Java. Java remains deeply embedded in large enterprises, supporting more than 90% of backend infrastructure in the Fortune 500, while Azul's 2025 State of Java Survey found that 70% of respondents reported more than half of their applications or infrastructure run on a JVM. Given the size of enterprise application portfolios, we use 3 million production applications as a conservative modeling baseline rather than an observed count of the global Java application population.

Subscribe to email