From e0d1508485316309e84a03623efcd73e0884f7d0 Mon Sep 17 00:00:00 2001 From: Tobie Langel Date: Mon, 5 May 2025 00:10:56 +0200 Subject: [PATCH 1/5] Prepare inventory for V1 release --- inventory.md | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/inventory.md b/inventory.md index 52ce152..9466837 100644 --- a/inventory.md +++ b/inventory.md @@ -1,9 +1,17 @@ +### Version 1 - May 12, 2025 + # Inventory of resources relevant to development and usage of open source under the Cyber Resilience Act The goal of this document is to provide a comprehensive list of resources that are relevant to the CRA obligations of open source software stewards and manufacturers when it comes to the development and usage of open source. The underlying purpose is to provide specification and standardization effort with easy access to documented industry and community best practices related to the development and integration of open source software and to the interactions between developers and consumers of open source. _Note: the description of each resource has been generated using a large language model and verified for accuracy. See [Annex I - LLM Usage][LLM usage] below for the prompts and tools used._ +## Status of this document + +This document is a [deliverable](https://github.com/orcwg/orcwg/blob/main/cyber-resilience-sig/deliverables.md#12-inventory) of the [Cyber Resilience SIG](https://github.com/orcwg/orcwg/tree/main/cyber-resilience-sig#readme) of the [Open Regulatory Compliance Working Group (ORC)](https://orcwg.org/) of the [Eclipse Foundation](https://www.eclipse.org/). It was approved to be released as version 1.0 by the Cyber Resilience SIG on May 12, 2025. It represents the consensus of ORC and its [members](https://orcwg.org/membership/). + +This document is released under the [CC-BY 4.0 License](https://github.com/orcwg/orcwg/blob/main/LICENSE.md). It is not governed by the Eclipse Foundation Specification Process (EFSP). To contribute to future revisions of this document or submit errata, please [open an issue](https://github.com/orcwg/cra-hub/issues/new) or [send a pull request on GitHub](https://github.com/orcwg/cra-hub/blob/main/inventory.md). + ## Table of Content * [1. Principles of security resilience][Section 1] From 83724cee61bddb039a9422068505ec32118bd1f8 Mon Sep 17 00:00:00 2001 From: Tobie Langel Date: Tue, 6 May 2025 09:36:55 +0200 Subject: [PATCH 2/5] Update Inventory title Update Inventory title to provide a short title "CRA Resource Inventory" while keeping the title descriptive. Update intro paragraph accordingly. Signed-off-by: Tobie Langel --- inventory.md | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/inventory.md b/inventory.md index 9466837..9981b42 100644 --- a/inventory.md +++ b/inventory.md @@ -1,8 +1,8 @@ ### Version 1 - May 12, 2025 -# Inventory of resources relevant to development and usage of open source under the Cyber Resilience Act +# CRA Resource Inventory: references relevant to the development and integration of open source under the Cyber Resilience Act -The goal of this document is to provide a comprehensive list of resources that are relevant to the CRA obligations of open source software stewards and manufacturers when it comes to the development and usage of open source. The underlying purpose is to provide specification and standardization effort with easy access to documented industry and community best practices related to the development and integration of open source software and to the interactions between developers and consumers of open source. +The goal of this document is to provide a comprehensive list of resources that are relevant to the obligations of open source software stewards and manufacturers when it comes to the development and integration of open source under the Cyber Resilience Act (CRA) and to the interactions between all of the different stakeholders. The underlying purpose is to provide specification and standardization efforts with easy access to documented industry and community best practices. _Note: the description of each resource has been generated using a large language model and verified for accuracy. See [Annex I - LLM Usage][LLM usage] below for the prompts and tools used._ @@ -10,7 +10,9 @@ _Note: the description of each resource has been generated using a large languag This document is a [deliverable](https://github.com/orcwg/orcwg/blob/main/cyber-resilience-sig/deliverables.md#12-inventory) of the [Cyber Resilience SIG](https://github.com/orcwg/orcwg/tree/main/cyber-resilience-sig#readme) of the [Open Regulatory Compliance Working Group (ORC)](https://orcwg.org/) of the [Eclipse Foundation](https://www.eclipse.org/). It was approved to be released as version 1.0 by the Cyber Resilience SIG on May 12, 2025. It represents the consensus of ORC and its [members](https://orcwg.org/membership/). -This document is released under the [CC-BY 4.0 License](https://github.com/orcwg/orcwg/blob/main/LICENSE.md). It is not governed by the Eclipse Foundation Specification Process (EFSP). To contribute to future revisions of this document or submit errata, please [open an issue](https://github.com/orcwg/cra-hub/issues/new) or [send a pull request on GitHub](https://github.com/orcwg/cra-hub/blob/main/inventory.md). +This document is released under the [CC-BY 4.0 License](https://github.com/orcwg/orcwg/blob/main/LICENSE.md). It is not governed by the Eclipse Foundation Specification Process (EFSP). + +This document is developed in the open, [on GitHub](https://github.com/orcwg/cra-hub/blob/main/inventory.md). To contribute to future revisions of this document or submit errata, please send a pull request or [open an issue](https://github.com/orcwg/cra-hub/issues/new). ## Table of Content From bc94f217de6f902a4ba92d7d114fa58e10780224 Mon Sep 17 00:00:00 2001 From: Tobie Langel Date: Sun, 11 May 2025 09:17:43 +0100 Subject: [PATCH 3/5] Add callout to section 5 of the inventory (#234) --- inventory.md | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/inventory.md b/inventory.md index 9981b42..358054e 100644 --- a/inventory.md +++ b/inventory.md @@ -741,6 +741,13 @@ This section contains references which are relevant to the requirement to "exerc > 5. For the purpose of complying with paragraph 1, 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] +> The due diligence obligation of manufacturers outlined in Article 13(5) of the CRA is the cornerstone of the relationship between manufacturers and the open source ecosystem. The CRA finally formalizes the long-held understanding that manufacturers are responsible for the security of the open source components that they integrate in their products. Yet the relationship between manufacturers and the open source projects they integrate remains underspecified. Most of the references we have collected assume the existence of a contractual relationship between a manufacturer and a supplier that addresses compliance obligations. +> +> This is of course different when integrating open source components, as no such agreement exists. Neither _open source software stewards_ nor the maintainers of open source projects are suppliers. Open source software is provided _as is_. Not only do manufacturers need to exercise due diligence when they decide to integrate open source projects in their products. They also need to support and contribute to these projects to ensure that they meet their own compliance requirements. +> +> ORC plans to examine this relationship in an upcoming [white paper on the due diligence obligations of manufacturers](https://github.com/orcwg/orcwg/blob/main/cyber-resilience-sig/deliverables.md#32-white-paper-on-due-diligence-obligation-of-manufacturers). + * [CISA Software Acquisition Guide](https://cisa.gov/sag) - The U.S. CISA Software Acquisition Guide provides practical guidance to government agencies (and large enterprises) on how to incorporate security considerations into the procurement of software. It outlines how buyers should define security requirements in RFPs/contracts – such as requiring vendors to follow secure development standards (like the NIST SSDF), provide artifacts like SBOMs and vulnerability disclosure policies, and agree to notify and patch if vulnerabilities are found. It also advises on evaluating supplier risk (e.g. checking if the vendor has had frequent security issues historically or if they have certified processes like ISO 27001). The guide suggests structuring the vendor selection process to include security questionnaires or assessments and to prefer vendors who can demonstrate secure-by-design approaches (perhaps via certifications or past performance). Additionally, it covers how to handle acquired software: establishing processes for incoming SBOM analysis, periodic re-scans for vulnerabilities in the product, and ensuring maintenance contracts cover security updates. By following this guide, procurement officers and risk managers can make more informed decisions, selecting products that not only meet functionality needs but also contribute positively to the organization’s security posture, thereby using market forces to encourage vendors to deliver safer software.
More info From cbdbe48c8bbf5a096b51a0f236676ed288889b9f Mon Sep 17 00:00:00 2001 From: Tobie Langel Date: Mon, 11 Aug 2025 16:30:52 +0200 Subject: [PATCH 4/5] Avoid linking to the deliverables Signed-off-by: Tobie Langel --- inventory.md | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/inventory.md b/inventory.md index 358054e..358c977 100644 --- a/inventory.md +++ b/inventory.md @@ -237,7 +237,7 @@ This section contains references which are relevant to the requirements expresse > (i) minimise the negative impact by the products themselves or connected devices on the availability of services provided by other devices or networks;\ > (j) be designed, developed and produced to limit attack surfaces, including external interfaces;\ > (k) be designed, developed and produced to reduce the impact of an incident using appropriate exploitation mitigation mechanisms and techniques;\ -> (l) provide security related information by recording and monitoring relevant internal activity, including the access to or modification of data, services or functions, with an opt-out mechanism for the user;\ +> (l) provide security related information by recording and monitoring relevant internal activity, including te access to or modification of data, services or functions, with an opt-out mechanism for the user;\ > (m) provide the possibility for users to securely and easily remove on a permanent basis all data and settings and, where such data can be transferred to other products or systems, ensure that this is done in a secure manner. These requirements do not apply open source software stewards. However, per [Article 25][] of the CRA, stewards (as well as developers and users of open source software and other third parties) may participate in voluntary security attestation programmes that assess the conformity of their software to some or all of these requirements. @@ -745,8 +745,6 @@ This section contains references which are relevant to the requirement to "exerc > The due diligence obligation of manufacturers outlined in Article 13(5) of the CRA is the cornerstone of the relationship between manufacturers and the open source ecosystem. The CRA finally formalizes the long-held understanding that manufacturers are responsible for the security of the open source components that they integrate in their products. Yet the relationship between manufacturers and the open source projects they integrate remains underspecified. Most of the references we have collected assume the existence of a contractual relationship between a manufacturer and a supplier that addresses compliance obligations. > > This is of course different when integrating open source components, as no such agreement exists. Neither _open source software stewards_ nor the maintainers of open source projects are suppliers. Open source software is provided _as is_. Not only do manufacturers need to exercise due diligence when they decide to integrate open source projects in their products. They also need to support and contribute to these projects to ensure that they meet their own compliance requirements. -> -> ORC plans to examine this relationship in an upcoming [white paper on the due diligence obligations of manufacturers](https://github.com/orcwg/orcwg/blob/main/cyber-resilience-sig/deliverables.md#32-white-paper-on-due-diligence-obligation-of-manufacturers). * [CISA Software Acquisition Guide](https://cisa.gov/sag) - The U.S. CISA Software Acquisition Guide provides practical guidance to government agencies (and large enterprises) on how to incorporate security considerations into the procurement of software. It outlines how buyers should define security requirements in RFPs/contracts – such as requiring vendors to follow secure development standards (like the NIST SSDF), provide artifacts like SBOMs and vulnerability disclosure policies, and agree to notify and patch if vulnerabilities are found. It also advises on evaluating supplier risk (e.g. checking if the vendor has had frequent security issues historically or if they have certified processes like ISO 27001). The guide suggests structuring the vendor selection process to include security questionnaires or assessments and to prefer vendors who can demonstrate secure-by-design approaches (perhaps via certifications or past performance). Additionally, it covers how to handle acquired software: establishing processes for incoming SBOM analysis, periodic re-scans for vulnerabilities in the product, and ensuring maintenance contracts cover security updates. By following this guide, procurement officers and risk managers can make more informed decisions, selecting products that not only meet functionality needs but also contribute positively to the organization’s security posture, thereby using market forces to encourage vendors to deliver safer software.
From 83b7d1e1441e7f970119da2e7cb1cf62e1098a08 Mon Sep 17 00:00:00 2001 From: Tobie Langel Date: Mon, 11 Aug 2025 16:32:00 +0200 Subject: [PATCH 5/5] Fix typo Signed-off-by: Tobie Langel --- inventory.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/inventory.md b/inventory.md index 358c977..98c9389 100644 --- a/inventory.md +++ b/inventory.md @@ -237,7 +237,7 @@ This section contains references which are relevant to the requirements expresse > (i) minimise the negative impact by the products themselves or connected devices on the availability of services provided by other devices or networks;\ > (j) be designed, developed and produced to limit attack surfaces, including external interfaces;\ > (k) be designed, developed and produced to reduce the impact of an incident using appropriate exploitation mitigation mechanisms and techniques;\ -> (l) provide security related information by recording and monitoring relevant internal activity, including te access to or modification of data, services or functions, with an opt-out mechanism for the user;\ +> (l) provide security related information by recording and monitoring relevant internal activity, including the access to or modification of data, services or functions, with an opt-out mechanism for the user;\ > (m) provide the possibility for users to securely and easily remove on a permanent basis all data and settings and, where such data can be transferred to other products or systems, ensure that this is done in a secure manner. These requirements do not apply open source software stewards. However, per [Article 25][] of the CRA, stewards (as well as developers and users of open source software and other third parties) may participate in voluntary security attestation programmes that assess the conformity of their software to some or all of these requirements.