05.md --> Proposal on key elements open source projects provide - #19
05.md --> Proposal on key elements open source projects provide#19jrico-eclipse wants to merge 3 commits into
Conversation
First approach connected to the contribution to the 03.md Signed-off-by: Juan <137221298+jrico-eclipse@users.noreply.github.com>
| # How open source projects and stewards can help manufacturers to achieve due diligence | ||
| While the Cyber Resilience Act places 100% of legal product liability on commercial manufacturers, it explicitly recognises the vital role of **Open Source Software Stewards**—legal entities that support open source projects intended for commercial activities. | ||
|
|
||
| # Open Source Information & Due Diligence: A Risk-Based Approach Under the CRA |
There was a problem hiding this comment.
#12 already addresses the properties to be evaluated, let's agree there on the properties and focus on how to support the attestation here.
|
|
||
| ## Voluntary Security Attestations & The ORCWG Framework | ||
|
|
||
| To standardise trust signals without overburdening maintainers, Article 25 empowers the use of **Voluntary Security Attestations**. As developed by the Open Regulatory Compliance Working Group ([orcwg/cra-attestations](https://github.com/orcwg/cra-attestations)), attestations operate along a spectrum rather than a single standard. |
There was a problem hiding this comment.
Article 25 does not empowers the use of Voluntary Security Attestations.
Article 25 empowers the commission to adopt delegated acts supplement CRA by establishing voluntary security attestation programmes.
At the moment there are no delegated acts supplementing CRA related to attestations, therefore I would not say that anything is empowering the use of attestations.
There was a problem hiding this comment.
I'll reframe it to better represent the current situation
| * **Light-Weight Attestations:** Low-friction, self-declared signals (e.g., published policies, OpenSSF scorecard results, automated pipeline checks). These satisfy due diligence for low-risk or sandboxed utilities. | ||
| * **Elaborated / Certification-Like Attestations:** Comprehensive, high-assurance attestations. These are consumed by manufacturers integrating critical components (e.g., cryptographic modules, kernels, network parsers). | ||
|
|
||
| Voluntary Security Attestations hold tangible operational and economic value for commercial manufacturers because they directly offload due diligence tasks that manufacturers would otherwise be legally obligated to perform. Under Article 13(5) of the CRA, commercial entities bear full responsibility for evaluating the security posture, supply chain integrity, and vulnerability management of their open source dependencies. When an open source project or steward produces an attestation, they execute the process checks, pipeline hardening, and metadata generation at the source. By ingesting these harmonised trust signals, manufacturers save significant engineering hours and audit resources that would otherwise be spent conducting redundant, independent security reviews. |
There was a problem hiding this comment.
pipeline hardening is not an attestation task. It is a what would a responsible steward do task what is not mandated by the CRA as a steward obligation.
There was a problem hiding this comment.
Remove pipeline hardening
| * **Light-Weight Attestations:** Low-friction, self-declared signals (e.g., published policies, OpenSSF scorecard results, automated pipeline checks). These satisfy due diligence for low-risk or sandboxed utilities. | ||
| * **Elaborated / Certification-Like Attestations:** Comprehensive, high-assurance attestations. These are consumed by manufacturers integrating critical components (e.g., cryptographic modules, kernels, network parsers). | ||
|
|
||
| Voluntary Security Attestations hold tangible operational and economic value for commercial manufacturers because they directly offload due diligence tasks that manufacturers would otherwise be legally obligated to perform. Under Article 13(5) of the CRA, commercial entities bear full responsibility for evaluating the security posture, supply chain integrity, and vulnerability management of their open source dependencies. When an open source project or steward produces an attestation, they execute the process checks, pipeline hardening, and metadata generation at the source. By ingesting these harmonised trust signals, manufacturers save significant engineering hours and audit resources that would otherwise be spent conducting redundant, independent security reviews. |
There was a problem hiding this comment.
Due diligence will not work in the right scale if it is not automated, therefore manufacturers gain CPU cycles and not man hours with pre-prepared attestations.
As attestation is voluntary manufacturers have to build all the frameworks for due diligence preparing for projects who do not attest.
There was a problem hiding this comment.
@CsatariGergely Could you elaborate further on which parts you think could not be automated?
Attestation should be in machine-readable standard formats that allow validation without a human in the process.
There was a problem hiding this comment.
My point is that due diligence will be automated and for this reason the attestation will not save engineering hours, but only CPU cycles.
Co-authored-by: Gergely Csatari <gergely.csatari@nokia.com> Signed-off-by: Juan <137221298+jrico-eclipse@users.noreply.github.com>
|
|
||
| # Open Source Information & Due Diligence: A Risk-Based Approach Under the CRA | ||
|
|
||
| Because the Cyber Resilience Act (CRA) mandates a **risk-based approach**, there is no "silver bullet" or one-size-fits-all solution for evaluating open source dependencies. What a manufacturer requires from an open source project depends entirely on the component’s criticality, privileges, and deployment context within the final commercial product. |
There was a problem hiding this comment.
Do we want to emphasize the integration role of the manufacturer here? This isn't about an open source product as much as an open source component being integrated into a manufacturer's product.
Specifically I would suggest using the term "integrator" or "integrating manufacturer" ... well something like that ... I fully recognize neither of these is a smooth descriptor.
| │ 1. Cybersecurity Policy │ Documented vulnerability handling & CVD │ | ||
| │ 2. Contribution Policy │ Pathways for contributing security patches │ | ||
| │ 3. Project & Community Health │ Long-term maintainer capacity & support │ | ||
| │ 4. Licensing & SBOM │ IP protection embedded in build metadata │ |
There was a problem hiding this comment.
What about the actual functionality/security of the component as integrated in the product. We see that the CRA specifically mentions testing as a potential due diligence method. Where does this fit in here?
What I mean is, does a steward or project help due integrators meet their requirements by offering test data or some other sort of integration instructions?
There was a problem hiding this comment.
@CsatariGergely to move this topic to an issue.
Discussed during the Due diligence meeting on Sep 10 Co-authored-by: Gergely Csatari <gergely.csatari@nokia.com> Signed-off-by: Juan <137221298+jrico-eclipse@users.noreply.github.com>
|
|
||
| # Open Source Information & Due Diligence: A Risk-Based Approach Under the CRA | ||
|
|
||
| Because the Cyber Resilience Act (CRA) mandates a **risk-based approach**, there is no "silver bullet" or one-size-fits-all solution for evaluating open source dependencies. What a manufacturer requires from an open source project depends entirely on the component’s criticality, privileges, and deployment context within the final commercial product. |
There was a problem hiding this comment.
| Because the Cyber Resilience Act (CRA) mandates a **risk-based approach**, there is no "silver bullet" or one-size-fits-all solution for evaluating open source dependencies. What a manufacturer requires from an open source project depends entirely on the component’s criticality, privileges, and deployment context within the final commercial product. | |
| Because the Cyber Resilience Act (CRA) mandates a **risk-based approach**, there is no "silver bullet" or one-size-fits-all solution for evaluating open source dependencies. What a manufacturer that integrates and open source component requires from the project depends entirely on the component’s criticality, privileges, and deployment context within the final commercial product. |
There was a problem hiding this comment.
@August-Bournique does it work better this way?
|
|
||
| ## Voluntary Security Attestations & The ORCWG Framework | ||
|
|
||
| To standardise trust signals without overburdening maintainers, Article 25 empowers the use of **Voluntary Security Attestations**. As developed by the Open Regulatory Compliance Working Group ([orcwg/cra-attestations](https://github.com/orcwg/cra-attestations)), attestations operate along a spectrum rather than a single standard. |
There was a problem hiding this comment.
| To standardise trust signals without overburdening maintainers, Article 25 empowers the use of **Voluntary Security Attestations**. As developed by the Open Regulatory Compliance Working Group ([orcwg/cra-attestations](https://github.com/orcwg/cra-attestations)), attestations operate along a spectrum rather than a single standard. | |
| To standardise trust signals without overburdening maintainers, Article 25 empowers the European Commission to establish **Voluntary security attestation** programmes, enabling developers, users, and third parties to assess compliance with essential cybersecurity requirements. As developed by the Open Regulatory Compliance Working Group ([orcwg/cra-attestations](https://github.com/orcwg/cra-attestations)), attestations operate along a spectrum rather than a single standard. |
There was a problem hiding this comment.
@CsatariGergely does it work better now?
| * **Light-Weight Attestations:** Low-friction, self-declared signals (e.g., published policies, OpenSSF scorecard results, automated pipeline checks). These satisfy due diligence for low-risk or sandboxed utilities. | ||
| * **Elaborated / Certification-Like Attestations:** Comprehensive, high-assurance attestations. These are consumed by manufacturers integrating critical components (e.g., cryptographic modules, kernels, network parsers). | ||
|
|
||
| Voluntary Security Attestations hold tangible operational and economic value for commercial manufacturers because they directly offload due diligence tasks that manufacturers would otherwise be legally obligated to perform. Under Article 13(5) of the CRA, commercial entities bear full responsibility for evaluating the security posture, supply chain integrity, and vulnerability management of their open source dependencies. When an open source project or steward produces an attestation, they execute the process checks, pipeline hardening, and metadata generation at the source. By ingesting these harmonised trust signals, manufacturers save significant engineering hours and audit resources that would otherwise be spent conducting redundant, independent security reviews. |
There was a problem hiding this comment.
| Voluntary Security Attestations hold tangible operational and economic value for commercial manufacturers because they directly offload due diligence tasks that manufacturers would otherwise be legally obligated to perform. Under Article 13(5) of the CRA, commercial entities bear full responsibility for evaluating the security posture, supply chain integrity, and vulnerability management of their open source dependencies. When an open source project or steward produces an attestation, they execute the process checks, pipeline hardening, and metadata generation at the source. By ingesting these harmonised trust signals, manufacturers save significant engineering hours and audit resources that would otherwise be spent conducting redundant, independent security reviews. | |
| Voluntary Security Attestations hold tangible operational and economic value for commercial manufacturers because they directly offload due diligence tasks that manufacturers would otherwise be legally obligated to perform. Under Article 13(5) of the CRA, commercial entities bear full responsibility for evaluating the security posture, supply chain integrity, and vulnerability management of their open source dependencies. When an open source project or steward produces an attestation, they execute the process checks, and metadata generation at the source. By ingesting these harmonised trust signals, manufacturers save significant audit resources that would otherwise be spent conducting redundant, independent security reviews. |
There was a problem hiding this comment.
@CsatariGergely removed both pipeline hardening and the reference to engineering hours
|
@August-Bournique a project cannot test the integration, because it does not have the product. What |
|
@astrogilda, I largely agree, but testing will still occur and the question as I see it is if the guide should discuss how the component manufacturer can approach that. While a component cannot test a specific integration, its manufacturer (be they FOSS or proprietary) can test the component for its own degree of CRA compliance. It can report the type and level of testing performed. It may even CE mark the component *if the component is commercial). Likewise one can supply integration guides noting the types of security functions the component requires from its operating environment or what it is and isn't compatible with. It usually remains the integrator's duty to conduct tests that show the integration within their product doesn't create security issues. I figure all manufacturers will do this to a certain degree, as part of any general product security testing. In some cases I suspect there may be a need for testing of the specific component, either to make sure it does what it says it does, respond to newly discovered vulnerabilities, or to determine if it's sufficiently secure for a specific use case or in a specific operational environment. The question I have is how to address what a component manufacturer can do to aid integration and hence manufacturer testing and assessment. Apologies if my prior note was confusing. |
|
"Because the Cyber Resilience Act (CRA) mandates a risk-based approach, there is no "silver bullet" or one-size-fits-all solution for evaluating open source dependencies. What a manufacturer that integrates and [sic] open source component requires from the project depends entirely on the component’s criticality, privileges, and deployment context within the final commercial product" I might correct some typos and remove cliches to get something like: "The Cyber Resilience Act mandates a risk-based approach and does not offer specific or universal methods methods for evaluating the security of open source dependencies. A manufacturer integrating open source components should be performing assessments on a product by product basis and such an assessment will include evaluation of open source components. The specifics of an open source component evaluation, and what it requires from the component and component developers depends entirely on the component’s criticality, privileges, and deployment context within the integrator's final commercial product." Either is fine though. |
4 participants
First approach connected to the contribution to the 03.md