Status of this document
This is a draft document and may be updated, replaced or obsoleted at any time. It is inappropriate to cite this document as other than a work in progress. Publication of this document as a draft does not imply endorsement by the Eclipse Foundation, Open Regulatory Working Group Members, or contributors.
| Revision | Date | Summary of Changes |
|---|---|---|
| 0.2 | 19.12.2025 | Integrated feedback from ORC WG and GH discussions |
| 0.1 | 18.11.2025 | Initial proposal by Æva Black to the ORC WG |
- TODO: complete various TODO's throughout this draft.
- TODO: add citations to explanatory and supportive information (guides, FAQs, etc) in an appendix, and link throughout this proposal.
- voluntary security attestation primarily benefit Manufacturers by reducing the compliance burden when integrating third-party FOSS projects into commercial products, aligning with CRA Article 13 and Annex I requirements for due diligence in third-party component integration.
- voluntary security attestation may benefit open source maintainers IF they incentivize sustained and ongoing support (financial or otherwise) for FOSS projects from manufacturers who depend on them, without jeopardizing the non-profit nature of open source foundations or stewards or requiring individual open source maintainers to form new or burdensome legal entities or commercial endeavours.
- Enabling this exchange of value will support market dynamics that promote both regulatory compliance and long-term sustainability of open source ecosystems, addressing the CRA's need for secure and resilient products while acknowledging the critical role of open source in modern software supply chains.
- Open source ecosystems and projects vary widely in every way. Our analysis of this diversity, based on feedback gathered before and during the October 2025 Code & Compliance event, suggests that there is a natural grouping into two tiers: projects that have significant institutional support, and projects that do not. Therefore, we propose a two-tier approach to voluntary security attestations to meet the needs of all projects that might wish to issue voluntary security attestations.
- Light-weight voluntary security attestations will be designed based on the reasonably foreseeable capabilities of the maintainers of open source projects that do not have significant commercial support, or those projects which are unlikely to require extensive conformity assessments or cryptographic analysis for downstream integration.
- Heavy-weight voluntary security attestations will be designed based on the reasonably foreseeable capabilities of the maintainers of open source projects that benefit from significant commercial support, or those projects which are likely to require extensive conformity assessments (e.g. due to their functional equivalence to commercial products).
- This two-tier structure supports both the needs of manufacturers and the capabilities of maintainers of open source projects by aligning attestation effort with project complexity and available support.
- We hope that these tiers may also create an incentive for manufacturers to increase support to project maintainers when there is mutual interest in a greater security assurance.
- Neither the CRA nor any open source license requires or obliges a maintainer of a non-stewarded project to make available a VSA nor to surface the data needed for someone else to create one.
- Some FOSS projects have no commercial use.
- Some FOSS projects' maintainers have no intention for their code to be used commercially, regardless of downstream actions.
- Some FOSS projects will not produce their own VSA, even if the project has commercial applications.
- Some commercially-popular FOSS projects do not have a steward and their maintainers may have no intention of becoming associated with, or supported by, a steward.
- Some FOSS projects, which have a steward and are intended for commercial use, are similar in scope and complexity to commercial products placed on the market. Such FOSS projects may fall under specific categories of Important Class I or II products, or they may be generic products. In such a case, applying a full conformity assessment may be feasible and desirable to those manufacturers who rely upon the FOSS project.
- Some FOSS projects, which have a steward and are intended for commercial use, would be unduly burdened by the application of a full conformity assessment.
- Some FOSS projects could have a steward who would not issue voluntary security attestations now or in the future for that project. Therefore, any proposal must account for voluntary security attestations issued by projects who are in this situation.
- Considering the authoritative nature of a maintainer's role in the secure development of an open source projects, maintainers are the most reliable parties capable of issuing voluntary security attestations.
- Considering that a steward who both fulfills the Article 24 obligations and issues voluntary security attestations will provide market actors -- CSIRTs, MSAs, and Manufacturers, and cybersecurity researchers -- with a trustworthy coordination point for a scoped set of open source projects;
- Considering that many open source projects do not currently have this support from a legal entity that could be deemed either its manufacturer or steward;
- Considering that such projects none the less provide significant economic and societal value;
- Considering that voluntary security attestations could enable new business models and revenue streams while protecting the non-manufacturer status of non-stewarded projects, building on the strengths of open source, and providing market actors -- CSIRTs, MSAs, and Manufacturers, and cybersecurity researchers -- with a known coordination point for open source projects.
Therefore, we recommend defining new mechanisms that:
- Enable currently-non-stewarded projects to become stewarded in a reasonable time frame, without undue burdens, and without causing disruption to the community responsible for their development and maintenance; and
- Create an attestation mechanism and business model that adequately address manufacturers' needs with respect to their compliance obligations for non-stewarded projects and adequately enable project maintainers to be compensated fairly and adequately, if desired.
For example, fiscal hosts endowed with sufficient capabilities and expertise may act as intermediaries to collect and distribute VSA fees from manufacturers to non-stewarded projects and to provide a trustworthy coordination point between these non-stewarded projects and CSIRTs, MSAs, manufacturers, and cybersecurity researchers.
Other models may emerge to facilitate equitable and efficient transactions between Non-stewarded projects and Manufacturers
All such models should support maintainers' essential role in sustaining their respective projects and recognize that they are uniquely empowered to decide how, and under what terms, any attestation, or artifacts needed for an attestation, will be produced.
- Considering that the community of developers who actively maintain an open source project constitutes the most knowledgeable experts with respect to addressing either the obligations of a steward or the contents of a VSA;
- Considering that some maintainers may not desire to become stewards;
- Considering that non-stewarded projects may be used in commercial products and their maintainers may desire this;
- And considering that Manufacturers may wish to continue using these projects;
- Therefore one or more third parties may wish to produce a VSA for these projects.
In these cases, it is beneficial for the necessary project information to be made publicly available such that third parties can generate voluntary security attestations through machine automatable means, thereby minimizing any burden on the open source maintainers.
- Given that it is common for projects to incorporate dependencies into distributed binaries, it may be valuable to include voluntary security attestations for those dependencies. Alternatively, a comprehensive SBOM may enable manufacturers to acquire the relevant voluntary security attestations for dependencies.
- If a Steward is issuing voluntary security attestations, it should only do so for dependencies that fall within their scope of support and for which they have obtained the necessary cooperation and commitment from the respective maintainers.
- Project maintainers must be willing and capable of adhering to documented security policies, as the attestation of a project's security practices is only meaningful if the individuals with commit access are committed to following those practices.
- When a Steward attests to a project's security policy, it is the responsibility of the maintainers to ensure that the policy is implemented and followed, as they possess the actual control and ability to effect changes.
- Attestations for dependencies should be limited to those associated with the steward, as it is unreasonable to expect a steward to attest to the security practices of dependencies that are not supported or maintained by the same steward.
- If a project is not associated with a steward, the responsibility for attesting to its dependencies lies with the project maintainers themselves, who must ensure that the necessary documentation is made available to enable a third party to produce an attestation.
- Stewards may include a statement in their VSA indicating which dependencies are covered by their attestation and which are not, in order to avoid confusion and to clearly delineate the scope of their support and responsibility.
[ FIXME: there are more edge cases that need to be covered here ]
[ FIXME: integrate more recommendations from other sections into this one ]
- Maintainers may wish to produce voluntary security attestations for projects they are responsible for.
- Maintainers may wish to explore options to associate with a steward or a fiscal host that can act as an intermediary.
- Maintainers may wish to make publicly available the necessary artifacts to enable the automated creation of third-party attestations for their projects.
- Due to the obligations of stewards described in CRA Article 24, and their relationship to specific open source projects, stewards should produce voluntary security attestations for projects to which they offer "sustained and ongoing support."
- Stewards should support tasks associated with producing voluntary security attestations that maintainers do not wish to perform.
- Stewards who produce voluntary security attestations for second-party projects (i.e., those their projects depend on) should indicate the nature of the relaionship.
- Maintainers and Stewards may produce voluntary security attestations for their project's dependencies; if done, they should clearly document the relationship between the issuer of the VSA and the subject of the VSA.
- Maintainers and Stewards should not produce voluntary security attestations for projects that are not associated with their activities.
- Maintainers and Stewards may publish voluntary security attestations in
multiple ways, including but not limited to:
- By placing a
COMPLIANCE.MDfile in the project's root directory (i.e., alongside theLICENSE.MDfile) - By providing a digitally-signed file publicly, to limited groups (e.g., based on membership), or uniquely to individual entities.
- By uploading an appropriate file to a public or private attestation repository of appropriate scope, if such exists.
- By writing a relevant entry in non-repudiable public digital records, such as in a Rekor or SCITT log entry.
- By placing a
- Manufacturers should include in their due diligence an assessment of the maintenance activities (e.g., active development, presence of vulnerability handling procedures, etc) of open source projects they rely on.
- When possible, select open source projects that have already have a conformity self-assessment or third-party assessment in the form of a VSA.
- Alternatively, support the maintainers of open source projects in creating such documentation, either directly or through a stewarding organization (if present).
[ FIXME: reformat the Summary section ]
- A minimalist voluntary security attestation should clearly convey the following information:
- The legal entity authoring the attestation, and that entity's relationship to the project.
- The date the attestation was issued.
- The open source project(s) to which the attestation pertains, identified by
name, version, and URL.
- If the attestation pertains to a specific source code version, then it should include the relevant version control identifier, such as a Git Commit ID.
- If the attestation pertains to a specific binary release, then it should include the cryptographic fingerprint, such as a SHA256 checksum, of that release.
- Where to find documentation regarding the project's cybersecurity policy, inculding how to report vulnerabilities to the project (e.g., CONTRIBUTING.md or SECURITY.md).
- Where to find documentation regarding the expected use and secure configuration of the project (e.g., README.md or INSTALLATION.md).
- How to subscribe to receive the project's public security notifications (e.g., an RSS feed or mailing list).
- To simplify downstream compliance activities without disrupting current
development practices, we recommend that projects adopt a new document, such as
by placing the template below in a
COMPLIANCE.MDfile and filling out the relevant portions.
By providing a light-weight VSA, an open source project supports manufacturers fulfilling the following specific obligations:
- 13.1: It is not expected that a light-weight VSA will address Annex I Part I.
- 13.2: Manufacturers must select open source projects appropriate for their product context and foreseeable use. To support this, open source projects should clearly document their projects usage and intended functionality (GV.03). Projects which remediate vulnerabilities in a timely manner (VM.02), maintain repeatable test procedures (QA.04), mitigate memory-safety vulnerabilities (QA.06), require code review (QA.07), and distribute updates in a cryptograhically-verifiable way (BR.03) support the manufacturer's requirement to minimize cybersecurity risks and prevent incidents.
- 13.3: To fulfil their update obligations, Manufacturers should select open source projects that are actively maintained (EL.01) and which are supported by coordinated vulnerability disclosure efforts (QA.03, VM.01, VM.02). If using open source projects which do not fulfil those requirements, the Manufacturer must take on these responsibilities.
- 13.4: Manufacturers who do not wish to disclose the open source projects used in their products must still consider open source when developing their risk assessment. By providing documentation (GV.03), license transparency (LE.01), and SBOMs (LE.02), open source projects help manufacturers fulfill this requirement.
- 13.5: Manufacturers must exercise due diligence when integrating third party open source components. All activities contemplated herein support this.
- 13.6: By providing a reliable point of contact for vulnerability disclosures (VM.01, VM.02), open source projects can support manufacturer's obligation to report identified vulnerabilities and share relevant fixes.
- 13.7: By providing a cybersecurity risk assessment, open source projects can support manufacturers obligation to document the relevant cybersecurity aspects and update the cybersecurity risk assessment of their products. Not addressed.
- 13.8: By disclosing information regarding vulnerabilities and their remediation (VM.02), and providing notice when ending support for the project or versions thereof (EL.01), open source projects support manufactuers obligation to effectively handle vulnerabilities in the product throughout its support period.
- 13.12: By providing documentation regarding usage (GV.03), testing (QA.04), and build (BR.01) procedures, open source projects support manufacturers requirement to draw up technical documentation.
- 14.1: By publishing information about discovered vulnerabilities in a timely fashion (VM.02), open source projects support manufacturers obligation to detect exploitable vulnerabilities and report on them.
Mapping table between CRA Requirements and the attached "Light Weight Template".
| CRA Requirement | Template Section | Author's Notes |
|---|---|---|
| Annex I Part I.1 | not addressed | risk assessment |
| Annex I Part I.2(a) | not addressed | no known exploitable vulns |
| Annex I Part I.2(b) | not addressed | secure by default configs |
| Annex I Part I.2(c) | not addressed | automatic updates |
| Annex I Part I.2(d) | not addressed | enforce IAM and SIEM controls |
| Annex I Part I.2(e) | not addressed | protect data confidentiality |
| Annex I Part I.2(f) | not addressed | protect program and data integrity |
| Annex I Part I.2(g) | not addressed | data minimisation |
| Annex I Part I.2(h) | not addressed | protect availability |
| Annex I Part I.2(i) | not addressed | minimize impact on other products |
| Annex I Part I.2(j) | not addressed | limit attack surfaces |
| Annex I Part I.2(k) | not addressed | include exploit mitigation techniques |
| Annex I Part I.2(l) | not addressed | monitor security-relevant activity |
| Annex I Part I.2(m) | not addressed | secure delete functionality |
| Annex I Part II.1 | LE.02, QA.01 | SBOM |
| Annex I Part II.2 | VM.02, BR.04 | vuln remediation & security patches |
| Annex I Part II.3 | QA.04, QA.05 | testing procedures |
| Annex I Part II.4 | QA.04, BR.04 | vuln disclosure |
| Annex I Part II.5 | VM.02 | CVD policy |
| Annex I Part II.6 | QA.03, VM.01 | vuln information sharing |
| Annex I Part II.7 | BR.03 | secure distribution of updates |
| Annex I Part II.8 | BR.04 | timely and free security updates |
| Annex II.1 | AU.01, AU.02 | registered entity information |
| Annex II.2 | VM.01, QA.03 | vulnerability reporting contact point |
| Annex II.3 | AU.03, QA.02, BR.02 | project identification |
| Annex II.4 | GV.03 | intended purpose and essential functions |
| Annex II.5 | not addressed | foreseeable cybersecurity risks |
| Annex II.6 | not applicable | EU declaration of conformity |
| Annex II.7 | not applicable | technical support docs |
| Annex II.8 (a) - (e) | not adressed | product lifecycle docs |
| Annex II.8(f) | not addressed | integration docs |
| Annex II.9 | QA.01 | public SBOM URL |
| Annex VII.1(a) & (d) | GV.03 | intended purpose and user docs |
| Annex VII.1(b) | BR.04, VM.02, EL.01 | version history |
| Annex VII.1(c) | not applicable | hardware architecture |
| Annex VII.2(a) | GV.01, GV.02, LE.01, LE.02, QA.02, QA.04, QA.05, BR.01 | internal design documentation |
| Annex VII.2(b) | QA.03, LE.01, LE.02, BR.03, VM.01, VM.02 | vulnerability handling documentation |
| Annex VII.2(c) | GV.01, GV.02, QA.04, QA.06, QA.07, BR.01 | development process documentation |
| Annex VII.3 | not addressed | cybersecurity risk assessment |
| Annex VII.4 | EL.01 | support period |
| Annex VII.5 | not applicable | list of applied harmonized standards |
| Annex VII.6 | not addressed | conformity assessment & test reports |
| Annex VII.7 | not applicable | copy of EU declaration of conformity |
| Annex VII.8 | LE.02, QA.01 | SBOM available upon request |
[ FIXME: reformat the Summary section ]
Whereas larger and more "product-like" open source projects are likely to require a substantially greater relative effort, compared to individual open source components, when a manufacturer seeks to demonstrate conformity to Annex I Part I and thereby fulfill obligations under Article 13.1;
Whereas the performance of, and authoring documentation regarding, a cybersecurity risk assessment is most appropriately done by the community of maintainers and developers of an open source project;
It is therefore recommended that heavy-weight voluntary security attestations demonstrate conformity to the essential requirements of Annex I Part I, and where applicable, document conformity to one or more relevant Annex III Class I or Class II products and the relevant harmonized standards.
Until there is clear and public guidance available regarding the CRA harmonized standards which could be applied to provide a presumption of conformity, this section is likely to be limited to providing only limited guidance based on publicly available drafts of the in-development standards.
[ FIXME: draft guidance for heavy-weight attestations ]