In 2021, the European Commission introduced the Cyber Resilience Act (CRA) as part of a broader push to strengthen cybersecurity in the European Union (EU). This came on the heels of the NIS2 Directive, which modernized the legal framework for managing cybersecurity across the EU. Each Member State has been required to draft and approve legislation to implement NIS2. While NIS2 focuses on critical infrastructure, the Commission saw the need to go further—addressing cybersecurity across the consumer technology market.

Enter the CRA. This act is an amendment to the existing Regulation (EU) 2019/1020 and aims to improve the security of hardware and software products sold within the EU. 

What is the Cyber Resilience Act (CRA)?

Originally announced in the 2020 EU Cybersecurity Strategy, the CRA aims to:

• Encourages manufacturers to build hardware and software products with fewer vulnerabilities, and maintain security throughout the product's life cycle.
• Gives users the information and tools they need to make more informed cybersecurity decisions.

To accomplish these outcomes, CRA has four main goals:

• Ensure that manufacturers incorporate security measures from the design and development phases.
• Create a unified cybersecurity framework that helps organizations comply with requirements more easily.
• Enhance transparency about a product's security features.
• Enable businesses and consumers to use products securely, making cybersecurity less of an afterthought.

Who needs to comply with the CRA?

CRA introduces security requirements for manufacturers selling products in the EU to ensure their products are built and maintained with cybersecurity in mind. This applies especially to products with digital elements, such as hardware and software, that are used across industries. To help determine which products need to meet specific security standards, the CRA uses Annex I, Annex II, and Annex III to classify and outline requirements.

Annex I: Outlines the general security requirements that all manufacturers need to follow. It focuses on ensuring that products are built with strong cybersecurity practices, such as minimizing known vulnerabilities and ensuring products can receive security updates.

Annex II: Categorizes different types of products based on their criticality. The more essential or high-risk a product is (like operating systems or network devices), the stricter the security requirements. Essentially, products are grouped based on how vital they are to infrastructure or cybersecurity.

Annex III: Defines two distinct classes of manufacturers based on the criticality of their products, each with different compliance obligations. This helps to determine how much oversight and regulation each type of product requires.

• Class I: Products with digital elements deemed critical (e.g., identity management software, VPNs, firewalls, and industrial automation systems). These manufacturers face stricter compliance standards.

• Class II: This class includes manufacturers of products like operating systems, firewalls for industrial use, and microprocessors used in industrial settings, which also have important compliance responsibilities, though to a lesser degree than Class I.

Why does the CRA matter for AppSec and Open Source Software (OSS) security?

Annex I of the CRA sets two key requirements that have a direct impact on AppSec and open source software (OSS) security:

• General Security Properties: Products must be built with an appropriate level of cybersecurity risk in mind and should not contain known exploitable vulnerabilities.
• Vulnerability Handling: Manufacturers must document and manage vulnerabilities, sharing this information responsibly to ensure swift resolution.

The CRA requires regular security testing and reviews to identify and document OSS components and their corresponding vulnerabilities. When issues are discovered, organizations must perform timely updates to fix or mitigate exploitable vulnerabilities, rapidly delivering security patches or updates at no charge to their customers. While the CRA does not explicitly call out that both direct and transitive OSS dependencies should be evaluated for risk, developers should consider these as part of their testing, remediation, and update activities as both are potential attack vectors.

Complying with CRA requirements for OSS dependencies

OSS is an integral part of most software applications today, but it comes with its own set of challenges. The industry standard for OSS dependency security is software composition analysis, or SCA, which identifies the third-party components (including open source software, or OSS) used in your application code and the corresponding risks those components might present to your organization. This is relevant and critical for the modern security tech stack because several studies indicate that modern code bases contain significant amounts of OSS and in fact, the majority of the code bases are OSS overall. 

To achieve compliance with CRA, and other standards like FedRAMP, your SCA tool should help you across all three dimensions of vulnerability management:

• Find potential risks
• Prioritize which risks to fix
• Fix risks

Find potential risks

Your dependency inventory is the foundation of your compliance and AppSec programs. To secure OSS vulnerabilities, you need to discover all components and their dependencies. 

When looking for an SCA solution, you should have requirements specific to risk discovery, including:

• Uses source code as the ground truth
• Analyzes source code at the time of build
• Identifies direct and transitive dependencies
• Understands functions that the application calls 
• Uses industry data sources, like NVD, GHSA, and OSV 
• Maintains an annotated function-level database

Endor Labs creates an accurate inventory of your dependencies and associated risks. We analyze your source code at the time of build to uncover both direct and transitive dependencies, then correlate them with the Endor Labs Vulnerability Database, which is based on NVD, GHSA, and OSV data along with a manually-annotated database for vulnerabilities going back to 2018 for 11 languages (and growing).

Three barriers to accurate risk identification

Barrier 1: Static analysis based on manifest files

Relies on the package manifest as the source of truth, which declare the dependencies the app is using. Then, it compares those dependencies to a vulnerability database and surfaces all license and known vulnerability issues associated with those dependencies. Has a high false positive rate and is known to miss transitive dependencies. 

Barrier 2: Runtime analysis

Uses code instrumentation, eBPF, or other techniques to observe the application in a running state. This produces accurate results on executed calls, but risks false negatives, or requires 100% test coverage - meaning that every single path must be executed, which is hard to achieve. By the nature of how it works, runtime SCA surfaces risks after the code is executed, and months after it's developed, which is often too little too late.

Barrier 3: Incomplete vulnerability database

Most SCA vendors supplement vulnerability information with their own proprietary databases. It’s difficult to compare results across proprietary databases because they’re a company’s “secret sauce,” so it’s hard to figure out which is the “best”. However, we hear from our customers that these proprietary databases rarely meet their requirements because they have insufficient historical data, inadequate ecosystem coverage, or infrequent updates.

Prioritize which risks to fix

As mentioned above, the CRA requires that all exploitable vulnerabilities be addressed. And the key word here is exploitable, because the discovery of a vulnerability does not mean that attackers can exploit it. Most SCA tools favor prioritizing remediation based on Common Vulnerability Scoring System (CVSS), but that does not address the issue of false positives. Teams typically struggle to identify which vulnerabilities to remediate because they lack insight into:

• Attacker's ability to reach the vulnerability within the source code’s context
• Transitive dependencies embedded within the direct dependencies
• Individual functions that contain vulnerabilities 
• Whether the vulnerability is known to be exploited or likely to be exploited

Our research shows less than 9.5% of vulnerabilities are exploitable at the function level, meaning the remaining 90.5% is just noise. When our customers combine reachability analysis with EPSS, the impact is even greater: programs that combine reachability and EPSS see a noise reduction of 98%. 

For each vulnerability discovered, your SCA tool should help you prioritize the next steps based on the answers to the following questions:

• Is the function containing the vulnerability “reachable”?
• Is there a fix available?
• Is it in production code (not test code)?
• Is the vulnerability known to be exploited? (e.g. CISA KEV)
• Is there a high probability of exploitation (high EPSS)?
• Is the risk of performing the upgrade lower than the security risk it repairs?

Three reachability traps

When using reachability as a risk management strategy, especially for compliance, you’ll need to defend how it works to your developers and auditors. There are three reachability traps that will harm the credibility of your SCA tool.

Trap #1: It trusts the import statements

As we discussed above, one of the most important functions of an SCA tool is to generate an inventory of your third-party components. Many tools rely solely on the package manifest to determine what’s being used, and specifically the import statements, which essentially tell you “the developer said, in the code, that they intend to use package X.” This isn’t a guarantee that the package is actually in use, or that it contains all the packages, so you’re likely to run into false negatives and false positives.

Trap #2: The call graphs that stop at direct dependencies
While function level reachability is becoming the standard for reachability, not all tools will provide it for your transitive dependencies. The consequence in this scenario is you’ll have a high false negative rate.

Trap #3: Relies on fix commits for vulnerable functions
Some tools will look at fix commits and draw the conclusion that if there was a function change in the commit, then that must be where the vulnerability lies. But in reality, commits often make several changes to several functions (not just the one with the vulnerability in it). In this case, the tool incorrectly thinks a collection of functions are vulnerable, when it may only be one function, so you have a higher false positive rate.

Fix risks

Addressing a vulnerability is not always as simple… “upgrade to the newest version” of the component can be far from trivial. Nearly all upgrades have the potential for breaking changes (depending on how they interact with your application), so understandably developers are cautious — dare we say fearful — of performing upgrades. So you might wonder what’s the point of finding these risks if I can’t get them fixed? I’m just going to fall out of compliance with CRA!

Endor Labs operates on the philosophy that an SCA tool shouldn’t just find risks, it should help you fix them. Because we understand how your application functions, we can predict the remediation risk of each upgrade:

• High Risk = Upgrading is very likely to break your application at multiple points
• Medium Risk = Proceed with caution: upgrading has a moderate chance of breaking your application
• Low Risk = you're probably good: upgrading has a very low chance of breaking your application

With this information, you can understand the ROI for each upgrade: how much risk will be fixed compared to the effort required. This enables you to communicate with developers more effectively, prioritizing the quick wins (low risk fixes) while allowing extra time to research ones that might break your app (medium and high risk fixes).

But in reality, there will be upgrades that can’t be performed within a “timely manner” for CRA. Upgrades to foundational libraries are very complex, and often require more than a year to perform successfully. In these cases, we offer an Endor Patch to keep you safe now while your engineers work to upgrade. These are a “minimum viable security patch”, in which we test fixes created by OSS maintainers and apply them (backport) to unsupported vulnerable versions. Endor Patches contain minimal changes — often just a few lines of code — and are extensively tested to avoid regressions. And if you are also adhering to SLSA standards, they are completely reproducible and hermetic builds.

The problem with automated upgrade tools

Developers increasingly turn to automated upgrading tools as a potential solution to helping them get past sticky upgrades, in which the tool offers automatic dependency updates through pull requests. However, these tools heavily rely on project test suites to detect breaking changes in updates, which recent research has shown to be unreliable. 

• Test coverage of direct dependency calls is limited, with half of the projects covering less than 60% of these calls.
• For transitive dependencies, the coverage drops dramatically to just 21%.
• When injecting simple faults into dependencies, test suites could only detect 47% of faults in direct dependencies and 35% in transitive dependencies on average.

Use Endor Labs to help with CRA compliance

Endor Labs helps you manage OSS dependency requirements with ease:

• Find potential risks: With Endor Labs, you get an accurate inventory of your dependencies and associated risks. We analyze your source code at the time of build to uncover both direct and transitive dependencies, then correlate them with the Endor Labs Vulnerability Database, which is based on NVD, GHSA, and OSV data along with a manually-annotated database for vulnerabilities going back to 2018 for 11 languages (and growing).
• Prioritize which risks to fix: You don’t want to waste time fixing vulnerabilities that aren’t exploitable — after all the CRA focuses on exploitable vulnerabilities. We use function-level reachability to determine which vulnerabilities have an exploitable path from the code your developer’s wrote, down through each direct and transitive dependency, all the way to the vulnerable function. This ensures only relevant issues are flagged for action, saving time and reducing false positives.
• Fix risks: With upgrade impact analysis, we help you understand exactly how an upgrade could impact your application, so you can decide what to upgrade now and what requires more planning. And with Endor Patches, we eliminate the hassle of hard-to-perform upgrades with security patches to stay safe and compliant while working to upgrade properly or lower the risk enough that it’s acceptable as-is. 

Book a 20-minute demo to learn how Endor Labs can help you manage security risks more effectively, ensure CRA compliance, and focus on building better, more secure products. You can even start a free, full featured 30-day trial that includes test projects and the ability to scan your own projects.