Article 13(5) Due diligence in the scope of the CRA#

The European supranational or community law of product security does not offer a clear and simple definition of "due diligence", though the requirement is often found, and the concept is well defined in a general sense. Legal usage of the phrase dates back to at least the early modern period and has been part of the language of legal duty ever since. Perhaps it's this long and varied usage that means there's no easy definition of due diligence under the Cyber Resilience Act (CRA), as the term can have very different meanings in very different contexts. Additionally, legal due diligence is almost always fact and circumstance based, creating a duty of care for the party performing it.

For the purpose of CRA compliance due diligence can only be understood within the context and from the language of the Act itself. Due Diligence is first mentioned in Recital 21 of the CRA and codified as a duty of manufacturers in Article 13(5) as follows:

"For the purpose of complying with paragraph 1 [the duty of secure design and development], manufacturers shall exercise due diligence when integrating components sourced from third parties so that those components do not compromise the cybersecurity of the product with digital elements, including when integrating components of free and open-source software that have not been made available on the market in the course of a commercial activity"

Note: this current version of the whitepaper focuses on due diligence as it is required by article 13(5) of the CRA. The ORC WG is in the process of clarifying the continuity and scope of due diligence in issue #5 and #14.

Article 13(5) due diligence is the process by which manufacturers can demonstrate that the integration of a new component does not compromise the security posture of the final product, a demonstration that is becoming increasingly critical under the CRA. The details of exactly how to accomplish this are less clear, though ultimately they come down to the manufacturer knowing the details of the components their product contains, making sure they are fit for the product's security requirements, and allowing the manufacturer to take action to mitigate any known exploitable vulnerabilities.

The implementation of an article 13(5) due diligence process necessitates the consideration of three key elements, which align with the CRA's focus on security throughout the product lifecycle:

Visibility: The ability to analyse the component. The availability of a A Software Bill of Material (SBOM) of the product is typically instrumental in achieving this objective, as the CRA emphasises the need for transparency and documented evidence regarding the security properties of product components.
Vigilance: The CRA mandates continuous compliance, so a manufacturer must ensure they have the ability to monitor for existing vulnerabilities essential to understand the level of exposure they assume upon integration of a component. This ongoing vigilance is a core requirement for maintaining a secure product over its expected lifetime, so a manufacturer must ensure via article 13(5) due diligence that they can have sufficient vigilance.
Maintenance: The level of community activity is an important factor for determining the risk profile that a particular component introduces to a product. A poorly maintained component represents a higher risk of unpatched vulnerabilities, which directly conflicts with the CRA's requirement for manufacturers to ensure the timely and effective handling of security updates.

The CRA requires the article 13(5) due diligence to be done at the integration time of 3^rd party components, including open source components to the products, and throughout the product's lifecycle. Due diligence should be done for all releases of a product in the product lifecycle. The application of the principle of article 13(5) due diligence with respect to open source should be understood as an obligation to manage the risk of using any third-party component plus the responsibility to assess the open source component's risks yourself. Open source constitutes a vast and diverse ecosystem, ranging from massive, professionally supported projects to small, volunteer-maintained repositories. This inherent diversity, in terms of community activity, maintenance practices, and documentation quality, presents a fundamental challenge to consistently and accurately assessing the three key article 13(5) due diligence elements (Visibility, Vigilance, and Maintenance) required under the CRA.

Even if the specific requirements of article 13(5) due diligence under the CRA have yet to be offered by the European Commission or courts, it is possible to make several educated guesses about how it will work.

CRA article 13(5) due diligence applies to 3^rd party components of a product, including components that are also part of a Remote Data Processing Solution.
The primary purpose and test of successful due diligence is that the completed product meets Annex I's essential cybersecurity requirements and that the manufacturer performs elements of vulnerability handling impacted by components and the product supply chain, such as the creation of an SBOM.

Note: This 2^nd point depends on the interpretation of the scope of due diligence discussed in issue #14 and will be updated once the issue is resolved.

In the future, the European Commission may establish specific requirements on article 13(5) due diligence, including or as part of a voluntary security attestation program established via a delegated act as provided for in Article 25. Currently, however, specifics remain elusive.

Beyond these basic duties, the CRA and related Commission publications have offered additional clarifications regarding article 13(5) due diligence. The most significant of these is found in Recital 34 of the CRA where the Act notes several potential methods of performing the non-attestation parts of article 13(5) due diligence on 3^rd party components:

Verifying that the component demonstrates conformity with the CRA, such as by using CE marked components.
Verifying that the component regularly receives security updates.
Verifying that the component is free from vulnerabilities registered in the European shared vulnerability database created by the NIS2 Directive (EU Directive 2022/2555) or other publicly available vulnerability databases.
Performing security tests on the component.

Properties to check for Article 13(5) due diligence#

The purpose of article 13(5) due diligence is to ensure that the integrated open source components are in a state that they do not compromise the cybersecurity of the product. This can mean that the development practices ensuring good code quality, have a way to report vulnerabilities, react to the reported vulnerabilities and release fixes. This chapter collects a selection of example properties what can be checked as the article 13(5) due diligence. The CRA introduces the concept of a voluntary security attestation as a way for open source communities to support the manufacturer's due diligence obligations. Such a voluntary attestation could provide the necessary data and assurances about the project properties identified in this chapter to carry out article 13(5) due diligence. Currently, the concept is still under development, therefore requiring manufacturers to assess individual properties and characteristics of open source projects, as exemplified in the following sections.

Project identity and authenticity#

Open source projects are forked in many cases. One primary reason is the contribution workflow of major software development platforms where the open source projects are developed (e.g.: github.com and gitlab.com). Another reason can be that a developer or a set of developers would like to drive the project to a different direction, would like to experiment with the technology or do not agree with the governance or license changes of the project. When integrating open source components, the source of these components should almost always be the major upstream, and should never be an unmaintained fork. If a fork is used, it should be well-maintained (adopting security fixes from upstream, at a minimum) and adopted for a particular justified reason. If the project has an open source software steward the steward could be a good entity of clarify the identity of the project in case of a doubt.

Development practices#

Development practices of the integrated components are a critial part of article 13(5) due diligence. The correct development practices ensure that the code of the component is always peer reviewed and tested.

Number of approvals for reviews: The project should conduct peer reviews for every change. This means that all changes should have a review process (GitHub Pull Request, GitLab Merge Request, Gerrit Change Set or similar) and there should ideally be at least one approval from a person who is not the proposer of the change. Peer reviews allow to identify and prevent attempts to inject malicious code into a project.

Automatic software testing: The project should have automatic testing set up which runs for all change requests before the changes are merged. This aims to maintain software quality, voiding regressions, and lowering the risk of introducing vulnerabilities.

Regular releases: The project should have regular releases. In this way the vulnerability fixes of the project are consumable by the products integrating the project. In case of stable projects without vulnerabilities to be addressed regular releases might not be needed.

Governance#

Sustainable governance: The project is governed in a way that is sustainable for the foreseeable duration of the product life-cycle and minimum support period. Examples may include having a published project succession plan, an active core group of co-maintainers, or a registered non-profit legal entity governing the project.

Vulnerability handling#

Naturally it is a critical factor of article 13(5) due diligence how the projects handle vulnerabilities.

SECURITY.md: The project should have a SECURITY.md or similar file which describes the security and vulnerability handling policy of the project, including for instance how users can report vulnerabilities and which branches and releases are supported (i.e., receive fixes).

Vulnerability handling: On a long-term perspective, the project should not neglect vulnerabilities. The reported vulnerabilities should be addressed in a timely manner.