Adding changes to Late June revision - #13
Conversation
Chapter 2 in the Google Docs https://docs.google.com/document/d/1_IpLqgWogDNGzN4J51L1pXQv0GsCYR4xPdn-BwXVBrk/edit?pli=1&tab=t.em8fjxfncrmt Signed-off-by: Gergely Csatari <gergely.csatari@nokia.com> Co-authored-by: Juan Rico <juan.rico@eclipse-foundation.org>
Signed-off-by: Gergely Csatari <gergely.csatari@nokia.com>
Provide introduction noting the primary sources of due diligence language in the CRA and its overall purpose, Signed-off-by: August-Bournique <august@bourniquelaw.com>
Signed-off-by: Gergely Csatari <gergely.csatari@nokia.com>
Co-authored-by: Æva Black <806320+AevaOnline@users.noreply.github.com> Signed-off-by: Gergely Csatari <gergely.csatari@nokia.com>
Signed-off-by: Gergely Csatari <gergely.csatari@nokia.com>
Signed-off-by: Gergely Csatari <gergely.csatari@nokia.com>
Made several revisions to introductory paragraphs, mostly cosmetic and typo correcting. 1. Noted the other duties related to component integration. My opinion is that it is dangerous to support any claims that due diligence under the CRA is limited to initial assessment. While I agree that this is the limit of 13(5), due diligence is not a specific term of art in the context of the CRA. I has no distinct definition and a duty of care related to component integration clearly extends beyond initial assessment per 13(6) and Annex I, Part II. Ignoring or discounting these related requirements may cause a great deal of risk for manufacturers, including commercial FOSS. 2. Added some additional potential Due Diligence methods that appear in the Guidance docs. Signed-off-by: August-Bournique <august@bourniquelaw.com>
jrico-eclipse
left a comment
jrico-eclipse
left a comment
There was a problem hiding this comment.
My only comment is that the section assumes due diligence as a continuous process and based on the last discussions we could eventually need to change this.
Overall is pretty good and complete.
| * **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. CRA requires the due diligence to be done at the integation time of 3rd party components, including open source components to the products, and throughout the product's lifecycle. Due diligence should be performed for all releases of a product in the product lifecycle. | ||
|
|
||
| Performing due diligence is an obligation to manage the risks of integrating a third-party component, and for free and open source software (FOSS) this will more frequently include manufacturer responsibility to assess the open source component's risks directly. FOSS is 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 due | ||
| diligence elements (Visibility, Vigilance, and Maintenance) required under the CRA. |
There was a problem hiding this comment.
This may need to be revisited if we decide to consider only due diligence during the integration phase.
There was a problem hiding this comment.
Makes sense! Thanks for the review. In response I'd say these specific sections are taken almost directly without change from the prior version.
However, to lay out a position on the issue... I find that "due diligence" being a general concept of what a manufacturer owes in various contexts, such as the use of non-RDPS third party services (per the guidance) cannot be seen as entirely limited to 13(5). Yes, 13(5) clearly describes a type of due diligence owed when integrating 3rd party components ... but there are other duties as well, including those logically following in 13 (6). It is fairly immaterial to me if these are labelled due diligence or not in this p[aper. Other diligence requirements due to the product are certainly not 13(5) due diligence, but they are a manufacturer duty involved in integrating components similar to the duties described in other parts of the CRA or in the Guidance, where they are sometimes labelled "due diligence". Presumably these might be more correctly described as "upstreaming requirements", "non-RDPS service due diligence", "operating environment due diligence", and "component vulnerability handling duties" or collectively perhaps as "supply chain due diligence".
To me at least they still seem to fit firmly into the category of component integration, which I'd argue is the real subject of 13(5) as well. I think it's important not to dismiss or ignore them in this document as they a serious duties that both integrators and the projects they integrate will need to be aware of. Obviously we can (and likely should) put them in their own sections as they constitute different sorts of requirement, but I think it's a disservice to argue that manufacturer diligence is no longer due towards integrated components post integration, even though its specifics or methods may change.
Of course we'll need to discuss this issue and reach some kind of consensus.
bgro
left a comment
bgro
left a comment
There was a problem hiding this comment.
I am sorry if my comments touch upon something that has already been discussed: I am not a participant of the work group, but eager to find out what peer organizations think about due diligence requirements. Via a colleague, I got in touch with @CsatariGergely and he was so kind to point me to this repository.
As I said, if I touch on something that has already been discussed, feel free to disregard what follows. If it is a severe case of misunderstanding what i written: at least you know that some readers might misunderstand the text ...
|
|
||
| * **Visibility**: The manufacturer's ability to analyse components and make a valid assessment of thier risks and security features. The availability of a Software Bill of Materials (SBOM) 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. However, since the CRA does not require public disclosure of SBOMs (see [Recital 77](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ:L_202402847#rct_77)) it may be difficult for integrators to obtain SBOMs for components, and other activities including testing, attestations, or contractual requirements may be needed. | ||
| * **Vigilance**: The CRA mandates continuous compliance, making the ability to monitor for existing vulnerabilities essential for understanding the level of exposure a manufacturer assumes upon integration of a component. This ongoing vigilance is a core requirement for maintaining a secure product over its expected lifetime. | ||
| * **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. CRA requires the due diligence to be done at the integation time of 3rd party components, including open source components to the products, and throughout the product's lifecycle. Due diligence should be performed for all releases of a product in the product lifecycle. |
There was a problem hiding this comment.
I am wondering about the trifecta "visibility", "vigilance" and "maintenance" you are centering this section on. My first observation is that the first two "visibility" and "vigilance" are about something internal to the organization exercising due diligence: they need to know the components they use and be able to assess them, and they need a continuous process. The third, "maintenance" is a property of the component that is subject to the due diligence process, and thus something very different.
If that was the only thing of interest about a component, that might be ok, but I am not sure that "maintenance" is in all cases the only aspect of a component I should look at: I can have very unsecure components with a lot of community activity around them.
It may be, however, that checking for evidence of "Maintenance" in combination with absence of vulnerabilities in the component is the absolute minimum that is expected, but since the whole process is risk based, this will not be enough for all components (?)
My current way of thinking about due diligence is the following:
CRA Due Diligence asks for a proportionate,
risk-based component-intake decision. Strategically, the important
capability is to make component use explainable: the manufacturer should be
able to show why a component was acceptable for the product context,
what level of checking was performed, and why that level was
sufficient. This turns OSS intake into a tiered governance task:
lightweight default checks for ordinary components, deeper review for
critical components, and active management of component risk
surfaced through these checks and reviews.
What I am trying to work towards is an understanding of how to sensibly define "criticality" tiers for components and what the minimum requirements for due diligence checks for the lowest tier would be.
As I said above: if I am rehashing stuff here the WG already has considered and dismissed, please disregard my comments. Otherwise, maybe I could provide some food for thought.
There was a problem hiding this comment.
Welcome to the ORC WG discussions @bgro
One of the key discussion points in #9 are
- Is the due diligence continuous or it happens only at given times in the product development cycle. I'm on the opinion that the CRA requires a due diligence to happen when the component is integrated to the product, at the given time during the development process. We decided to factor this discussion out to Explain if due diligence is a continous activity or happens only at specific times #5
- Is the scope of due diligence only to make a proportionate, risk-based component-intake decision or it contains all manufacturer obligations related to open source consumption. This discussion we factored out to Does due diligence cover all manufacturer 3rd party integration obligations? #14
This PR is an addition PR on top of #9 and I really would like to merge #9 and then address the issues in this pr.
Your comments are valid and some of them we did not discuss yet. We have an open ticket about the discussion related to the risk levels in due diligence #14
| * **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. CRA requires the due diligence to be done at the integation time of 3rd party components, including open source components to the products, and throughout the product's lifecycle. Due diligence should be performed for all releases of a product in the product lifecycle. | ||
|
|
||
| Performing due diligence is an obligation to manage the risks of integrating a third-party component, and for free and open source software (FOSS) this will more frequently include manufacturer responsibility to assess the open source component's risks directly. FOSS is 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 due | ||
| diligence elements (Visibility, Vigilance, and Maintenance) required under the CRA. |
There was a problem hiding this comment.
This passage makes me wonder whether I completely misunderstand something (if that is the case, what I wrote above may be moot, but at least you know that a misunderstanding can arise): the text moves in one sentence from the difficulty that FOSS presents to /assessing visibility, vigilance, and maintenance/, but only the third of the three is an attribute of the FOSS component: the other two might be assessed by an auditor when checking CRA compliance of a manufacturer, but that is a completely different assessment (?)
|
@August-Bournique this would need conflict resolution. I can help in the practicalities if needed. |
4 participants
Cosmetic changes and minor additions to recent revision.