What enterprises need to know about the Cyber Resilience Act and software supply chain risk

In part 1 of this series, we examined why enterprises need more than an inventory of the open source components in their software. Understanding where dependencies come from, whether they are maintained, how they handle vulnerabilities, and what options exist when problems emerge is increasingly important to managing software supply chain risk.

The European Union’s Cyber Resilience Act (CRA) brings this broader lifecycle perspective into sharper focus for organizations that manufacture or place products with digital elements on the EU market. The CRA requires manufacturers to address cybersecurity throughout the product lifecycle, including conducting cybersecurity risk assessments and handling vulnerabilities during the product's support period. Manufacturers must also specify a support period for their products.

This has an important implication for open source dependencies: An organization cannot effectively manage the security and support lifecycle of a product if it doesn’t understand the components that make up that product.

The CRA also recognizes that free and open source software has a different development and distribution model. It introduces a specific category of open source software stewards—legal persons that provide sustained support for the development of specific free and open source software intended for commercial activities and play a main role in ensuring its viability. These stewards have a more tailored set of obligations, including establishing a cybersecurity policy and supporting effective vulnerability handling.

That distinction matters. Not every open source contributor becomes an open source software steward, and not every use of open source falls into the same regulatory category. The CRA's application depends on factors like how the software is made available, and the role an organization plays. The European Commission's 2026 guidance provides additional clarification for organizations preparing for implementation.

For manufacturers incorporating open source into their products, the practical response is to make supply-chain due diligence part of the broader risk assessment process. That means gathering information about the components a product depends on, understanding their maintenance and vulnerability-handling practices, and identifying and addressing critical gaps. 

Red Hat approaches this responsibility as more than a compliance exercise, working to strengthen the upstream projects and communities on which the broader ecosystem depends. Our CRA Stewardship Guidelines provide an additional perspective on our approach to open source stewardship in the context of the CRA. 

What enterprises should know

Regulations aside, the core reality is simple: You can't secure software if you don't know what's inside it. A software bill of materials (SBOM) can help establish an inventory of components and their relationships. But an inventory is only the beginning.

For organizations using upstream open source components, these questions should form part of their due diligence and provide the technical context needed to assess risk:

1. What exactly are we using? Know the component, version, origin, and relationship to other dependencies.
2. Is it maintained? Understand whether the upstream project is active and whether there’s a credible mechanism for continued maintenance.
3. How does it handle vulnerabilities? Look beyond whether vulnerabilities have been reported. Understand how the project identifies, discloses, and remediates security issues.
4. How important is it to the organization? An inactive component buried deep in a dependency graph may present a different level of risk from one supporting a critical security function or core product capability.
5. Who can fix it? Know who’s responsible when a vulnerability or compatibility problem emerges. Is there an active upstream community, a commercial maintainer, or an internal team?
6. What is our exit strategy? If the project becomes unsustainable, can the organization upgrade, replace, migrate, patch, or otherwise mitigate the dependency?

The answers—and the technical details behind them—should inform the risk assessment conversation. They can also reveal gaps that need to be addressed, whether through additional controls, remediation, a different dependency, or greater engagement with the upstream community.

From software inventory to dependency intelligence

An SBOM can tell an organization what’s in its software. The next step is understanding what that information means.

For key dependencies, an inventory isn’t enough. Teams need context on maintenance, vulnerabilities, security response, governance, dependency relationships, product criticality, and available remediation or replacement options. 

That context turns a software inventory into dependency intelligence: a way to understand whether a component is actively maintained, how it responds to security issues, how important it is to the product, and what options exist if it becomes vulnerable or unsupported.

That intelligence can inform more than risk decisions. It can help organizations decide where to contribute, which communities to engage with, and where investing in upstream health can reduce downstream risk for everyone who depends on the software.

Building a more resilient open source supply chain

Enterprises are not merely consumers of the open source ecosystem. Where dependencies are strategically important, organizations can help address vulnerabilities, improve software quality, strengthen governance, and sustain the technologies they rely on.

Enterprises need both visibility into where risk exists and a practical path to address it. A dependency may be vulnerable but difficult to upgrade because of compatibility requirements, testing, certification, release schedules, or production constraints. In other cases, multiple organizations may discover the same vulnerability and need to coordinate with the upstream project to address it.

Coordinated vulnerability response: As vulnerability discovery accelerates, individual organizations can end up independently finding and reporting the same issues to the same maintainers. Akrites is designed to address this coordination problem by providing a shared security incident response team that can validate and deduplicate findings, coordinate remediation with maintainers, and manage disclosure through a consistent process. For enterprises, the value is not simply finding more vulnerabilities; it’s helping create a more coordinated path from discovery to upstream remediation.

Practical remediation: Even when a fix exists, upgrading a vulnerable dependency may not be straightforward. Compatibility requirements, regression testing, certification, release schedules, and production constraints can make an immediate upgrade difficult. Lightwell helps organizations address security issues in third-party open source software when upgrading isn't practical or could create operational risk.

These approaches address different points in the software supply chain lifecycle, but they share the same principle: Remediation should not end with a private downstream workaround. Where possible, fixes and security improvements should remain connected to the upstream projects. 

The CRA raises the stakes for organizations whose products fall within its scope, but the underlying lesson extends beyond compliance. Building a resilient software supply chain requires organizations to understand their dependencies, assess their health over time, and have a plan to act when risks emerge.

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.