What enterprises need to know about the software they depend on

Knowing an application contains open source components is not the same as understanding the software and communities behind them.

For many organizations, the software supply chain extends across thousands of dependencies, developed and maintained by communities, foundations, vendors, and individual contributors. Red Hat Chief Technology Officer Chris Wright described this as the enterprise software fabric: a shared network where developers from different companies, projects, and communities build and maintain code together.

That collaboration is one of open source's greatest strengths. It allows organizations to build on shared innovation, benefit from decades of engineering investment, and contribute improvements back to the communities on which they depend. But as organizations build more of their software on this shared foundation, they also need greater visibility into what they’re depending on, where it comes from, and how it’s sustained.

That question is becoming more important as governments and regulators place greater emphasis on software supply-chain security. Enterprises increasingly need to know whether they understand the open source software in their products and applications well enough to manage risk throughout its lifecycle.

With open source, a component may be actively maintained today and unsupported tomorrow. A vulnerability may be disclosed in a dependency that few people inside the organization even knew was present. And when an upstream project can no longer respond, the responsibility for addressing the problem can move downstream.

In the European Union, the Cyber Resilience Act (CRA) sets cybersecurity requirements for digital products. Vulnerability reporting began September 11, 2026, with the main requirements taking effect December 11, 2027. For enterprises that develop or sell products in scope of the CRA, this creates a practical challenge: understanding every component in your commercial software is no longer optional—it’s a legal requirement.

Software supply chain security and the invisible scaling crisis

The average commercial codebase now contains more than 84,000 files, roughly 4 times the number seen 5 years ago.

AI-assisted development adds to that complexity. Coding assistants can generate functions, suggest libraries, reuse implementation patterns, and produce working code in seconds. This helps developers move faster but can also make it harder to track where software comes from and what dependencies, licenses, or vulnerabilities come with it.

For example, a developer accepts an AI code suggestion and unknowingly pulls in a deeply nested software with a critical vulnerability. A new license obligation or vulnerability can enter the project without anyone intentionally adding a dependency. 

AI or open source are not inherently risky. Rather, the issue at hand is that software can now enter development workflows faster than teams can understand and govern it. Dependencies can come from package managers, vendors, copied code, binaries, generated code, or other components. Traditional inventories may not capture the full picture.

The blind spot isn't that enterprises have too many dependencies, it’s that they lack the context to understand what those dependencies mean for the products they build.

Open source is part of the supply chain

Open source software is one of the foundations of modern enterprise technologies. The average commercial codebase contains approximately 1,180 open source components, up 30% year over year. 

That scale creates a lifecycle challenge. Every dependency comes from a project with its own approach to maintenance and security. As the number of components grows, enterprises have more upstream projects to understand and manage.

Organizations aren’t simply consuming software from a single vendor. They rely on projects maintained by different people and communities. Knowing which components are in a product is only the starting point. Enterprises also need to know where those components come from, whether they are maintained, how they respond to security issues, and how important they are to the products they deliver.

The maintenance question

Software doesn’t retain its security posture, compatibility, or usefulness without ongoing maintenance. Vulnerabilities need to be investigated and remediated. Dependencies change. Platforms and operating systems evolve. New versions of languages and runtimes introduce compatibility requirements. Products also have support periods that may extend well beyond the point when a component was first incorporated.

But maintenance shouldn’t be reduced to a simple measure of commit frequency. A project with few recent changes may be mature and stable. A highly active project may still have weaknesses in security practices or vulnerability response. The question is whether there are credible signals that someone is actively sustaining a project. 

When evaluating an open source dependency, enterprises should look for clear signs of ongoing maintenance, including:

• Regular package version updates and security fixes
• Minor releases on a (roughly) 1-to 3years cadence
• Responses to issues or pull requests within a month
• Identifiable maintainer activity within the past year

Looking for maintainer activity within the past year is a useful starting point, but it’s only 1 signal. Enterprises should also consider how the project handles vulnerabilities, how it’s governed, and how critical it is to their product. An older or infrequently updated project is not necessarily risky. The key question is whether the project has enough ongoing maintenance and support for how the enterprise depends on it.

When upstream maintenance becomes an enterprise problem

Consider a critical application that depends on an open source component. A serious vulnerability is discovered, but the project has no active maintainer able to address it. 

The enterprise now has decisions to make:

Can we upgrade or swap to an alternative? Can we patch and maintain the code ourselves? Can we remove the dependency? How deeply is the component embedded in other software?

The technical problem may be upstream, but the business problem is now downstream. When upstream maintenance disappears, the responsibility for managing the risk can move to the organizations that depend on the software.

This is why dependency due diligence must go beyond vulnerability scanning. Teams need to understand the maintenance, security practices, support model, and remediation options for the projects they rely on.

Organizations are still determining how to integrate dependency security checks into daily software development–specifically, whether to treat them as a pre-release checkpoint or a continuous lifecycle requirement. Existing benchmarks like OpenSSF Open Source Project Security Baseline (OSPS) and work in initiatives such as the OpenSSF Launchpad SIG and the Eclipse ORC Due Diligence Task Force are creating greater clarity around these practices.

A healthy upstream community is a big step forward. When maintainers, contributors, vendors, and users are engaged, vulnerabilities can be identified, fixed, tested, and distributed through the ecosystem quickly and collaboratively. This is one of the fundamental benefits of open source: Improvements can flow back through the ecosystem and benefit everyone who depends on it.

This is the first part of a two-part series on understanding software dependencies and managing software supply-chain risk. In Part 1, we’ve looked at why visibility into open source dependencies, upstream maintenance, and community health matters for enterprises. In part 2, we’ll turn to the EU CRA and explore what its requirements mean for organizations that develop or sell products with digital elements in the EU market. 

Dive deeper

Ready to move from static software inventories to proactive dependency intelligence? 

• Explore Red Hat Trusted Software Supply Chain
• Red Hat’s guide to securing the enterprise software fabric
• Review our CRA Stewardship Guidelines to better understand open source steward responsibilities.