How The Cyber Resilience Act Shifts Open-Source Responsibility To Vendors

The EU Cyber Resilience Act (CRA), adopted last year, aims to strengthen product security in several ways. One of its most ambitious goals is the elimination of exploitable vulnerabilities from digital products. Vendors are now obligated to identify vulnerabilities, resolve them before delivery, and continue addressing them throughout the product’s lifecycle.

The scale of the challenge

The scope of this obligation is vast. The number of reported vulnerabilities grows each year and is projected to exceed 40,000 this year.

Once reported, vulnerabilities take time to fix and to patch in deployed products. Studies of open-source ecosystems such as Maven reveal median patch times of 151 days for low-severity issues, and 78 days for critical ones. Similarly, in npm dependencies, fixes are delayed across client libraries by 4 to 11 months on average. These gaps between disclosure and patch deployment mean it is entirely plausible that tens of thousands of vulnerabilities remain exploitable in the wild at any moment.

This is a goldmine for malicious actors, fueling ransomware and other cybercrime. Google’s Threat Horizons research found that the average time-to-exploit has shrunk to just 5 days from disclosure to active exploitation. This mismatch between patching timelines and attacker speed leaves organizations exposed for weeks or months at a time. The ambition to close this gap is both justified and long overdue.

The role of SBOMs

The CRA outlines a clear method for vulnerability identification. Vendors must generate a Software Bill of Materials (SBOM)—a list of all software components within a product. They must then cross-check this list against public vulnerability databases. The process can be automated, with many tools already available to build SBOMs, connect them to vulnerability databases, and flag issues. In practice, one SBOM can reveal hundreds of vulnerabilities.

The open-source dilemma

Resolving these vulnerabilities is far from straightforward. Many developers lack the security expertise to remediate complex issues. The challenge grows when vulnerabilities are tied to third-party or open-source components. Most commercial products rely on open-source software, which offers developers efficient, reusable solutions for common tasks. But when vulnerabilities arise, vendors must often begin by understanding how the open-source component functions before determining how the flaw affects their product.

While open-source maintainers and communities will contribute to resolving issues, the CRA places ultimate responsibility on vendors. They must decide whether to support and contribute to the open-source ecosystem or to replace vulnerable components with proprietary alternatives—both requiring additional effort and resources.

Meeting requirements

Keysight offers solutions to help organizations identify and address software vulnerabilities efficiently and effectively. With our expertise and tools, we enable customers to meet CRA requirements and close the vulnerability gap in a timely manner.