| Re: [open-regulatory-compliance] Kicking off the CRA Attestations project |
This document outlines a possible strategic solution to challenges that Open Source Software (OSS) projects face under the Cyber Resilience Act (CRA) while capturing the revenue opportunity to benefit the open source ecosystem.
It suggests the creation of a centralized attestation registry - a single, non-profit hub where OSS stewards can easily post CRA attestations and manufacturers can buy and manage them.
This hub would fundamentally streamline compliance for manufacturers by allowing them to upload a product's Software Bill of Materials (SBOM) to automatically select and pay for all necessary attestations in one transaction.
The idea is to establish a Centralized Attestation Registry. A single, authoritative, and easily accessible digital platform or "hub."
Easier for Open Source projects:
Open source project stewards would manually or programmatically post their CRA attestations to this registry. This means they could use an automated process, like an API, to upload the documents, making it easier to upload new versions.
Interactions and payments would be handled by the platform, reducing the time burden on the maintainer or stewards.
Persistent, centralized records for stewards of who has bought attestations.
Set your own price (?) for your attestation.
No attestation? Ask for donations when your component shows up in the SBOM of a manufacturer.
Simpler for manufacturers:
This registry would serve as the definitive source for attestation data, holding the compliance paperwork for a vast number of open source components in one place.
Manufacturers could upload a Software Bill of Materials (SBOM) to the registry (or query via API). The system would then automatically identify and select all the required CRA attestations for those open source components in a single action, allowing the manufacturer to select them "en masse."
Once the required attestations are identified, the manufacturer would be presented with a total calculated cost (the "basket total") to cover the expenses associated with generating all those attestations. A single payment could be made, and perhaps it could even be a subscription?
Manufacturers would be able to get fine-grained management of attestation versions, because the whole process of gathering all the attestations at a date and time for an SBOM would be tracked and held in the manufacturer’s account.
Maybe attestations are not easily downloadable, making it harder to share grey-market PDFs under the table. Access to attestations for Market Surveillance Authorities could be provided through a manufacturer report or special audit mode.
Financial Mechanism and Governance
The money must be handled in a way to ensure fairness, impartiality, and sustainability.
The funds collected from the manufacturers would be managed in two ways:
Direct Return:
Where possible, the money can be passed directly back to the specific Steward organization that generated the attestation, funding their work.
Pooled Fund:
A small portion could be kept to pay for the attestation registry costs.
Another small amount could be put into a centralized pot. This fund could be used to proactively cover the up-front cost for smaller, less-resourced OSS projects that need financial assistance to generate their initial attestations.
Perhaps if there is no attestation available for a component the system would ask for a nominal donation to go towards funding an attestation.
Governance as a Charity:
The entire registry operation, including the financial mechanism, is proposed to be run as a non-profit or charitable organization. The goal of this structure is to eliminate any concerns about lack of impartiality or self-interest, ensuring the registry's primary focus is on compliance, sustainability, and supporting the open source ecosystem.
This proposed system acts as a compliance-as-a-service hub for the open source world. It makes it easier for OSS projects to submit their attestations and makes it easier (and more financially responsible) for manufacturers to obtain and pay for those attestations under the neutral umbrella of a non-profit entity.
Hey all,Just banging rocks together with this, I figure it's the kind of thing we have to brute-force with ideas until we find something that can work for everyone, although this is still very early days.I think one of the biggest problems we have is that companies will simply wait to avoid paying. Hence, I believe whatever system we use, it needs to have some way of dissuading that, or rewarding people who contribute early.I also think we need to ensure the bulk of the money goes to the developers themselves. Concerning urgency of getting attestations, perhaps those who contribute gain immediate access to the attestation?Happy to hear your thoughts,--_______________________________________________On Mon, Oct 27, 2025 at 4:03 PM Felix Reda via open-regulatory-compliance <open-regulatory-compliance@xxxxxxxxxxx> wrote:Hi Jordan,_______________________________________________In your idea outlined below, do you imagine that an attestation that initially did not receive its funding goal, but subsequently did reach it through additional manufacturers signing up, would subsequently become publicly available?I think an ideal system would ensure two goals:- That the financing of the security attestation described in recital 21 of the CRA is designed in a way that can cover the cost of actually making security improvements to that FOSS that make it suitable for inclusion in a product with digital elements of a given risk level, not simply the cost of verifying whether an open source project already meets those standards,- That duplication of effort to undertake the same security assessments over and over again is avoided, given that recital 21 states that attestations are supposed to support and facilitate the due diligence of manufacturers.Best,FelixAm 27.10.2025 um 13:31 schrieb Jordan Maris via open-regulatory-compliance <open-regulatory-compliance@xxxxxxxxxxx>:Hey Elizabeth!One of the concepts that gave me the shivers at the conference, was the concept of "downstream attestations". This can only happen if attestations would *not* be recipient bound. Which would completely invalidate any "business plan" for Open Source Stewards, especially for the smaller Open Source communities. Or am I missing something here?I tend to agree with this statement, but I do think that making attestations recipient bound does risk creating some barriers, but theoretically, it could be possible to do both: for example:
- A steward announces "we need 1000€ monthly to provide an attestation to the public for this component".
- Manufacturers commit to supporting the project for a fixed number of months at a fixed rate (IE:€50/month)
- If the steward’s goal is met, then the attestation becomes publicly available to everyone, with a nice Thanks.md file with the names of the companies who are supporting security of the project.
- If the steward’s goal is not met, then the attestation becomes recipient bound.
- Manufacturers who committed to supporting get the attestation at the price they committed to (IE: €50/month), for the number of months that they committed to, followed by the standard rate. (This both incentivises supporting projects, and supporting them for longer periods)
- Manufacturers who did not commit to pay a standard rate, which is set at double the median committed support (IE: €100/month)
It's not perfect, but perhaps it could be an approach.Best regards,--_______________________________________________On Mon, Oct 27, 2025 at 1:14 PM Elizabeth Mattijsen via open-regulatory-compliance <open-regulatory-compliance@xxxxxxxxxxx> wrote:Hi All,
pretty new to all this, but did attend the workshop / conference last week and am still digesting the experience.
> On 27 Oct 2025, at 12:44, Jordan Maris via open-regulatory-compliance <open-regulatory-compliance@xxxxxxxxxxx> wrote:
> The CRA is as much an Open Source Sustainability law as it is a Cyber Resilience one, but Open Source Sustainability is vital to Cyber resilience. If we do not limit who can issue attestations, we will find ourself in a situation where dozens of companies pop up whose entire mission is to harass Open Source developers into providing them enough information to create an attestation, and then pocket the cash.That is an unacceptable but extremely likely outcome if we don't create some restrictions.
This is *exactly* one of the vibes I gathered from the meeting last week. And not only would these be companies that pop up, I also got the feeling that larger Open Source institutions would not be against pocketing such cash in such a situation either. I hope I'm wrong.
> I also believe that allowing organisations with no affiliation or link with the developers to provide attestations would not result in those attestations being reliable or valuable.
Indeed. 100% agree.
On a possibly related note: Mature ecosystems have a lot of modules that are effectively without maintainer, but are in fact in the custody of the community (e.g. https://raku.land/zef:raku-community-modules). Many of these have no real commercial value. Others more up-river obviously do (e.g. https://raku.land/zef:raku-community-modules/OpenSSL).
Suppose a manufacturer would like to get an attestation for such a module, how would that work without any active maintainers? Would custodians be able to provide attestations under the umbrella of a Open Source Steward? Or would this just be an issue for the Open Source Steward in providing the requirements of the CRA?
> You are right that companies can conduct internal assessments or commission private assessments from a third-party, however that, in my view, would likely involve in-depth auditing of code (to meet the requirements of insurance companies), which will be extremely costly, and again, those third parties do not necessarily have the information required to attest to the security of the supply chain.
Quite!
> This makes attestations the better choice for manufacturers.
> 3. Is an attestation issued as a voluntary security attestation under an article 25 system bound to the software alone or *also* to the recipient? For instance, if Manufacturer A gets an attestation for libfoo 0.9.6c, can Manufacturer B, who uses the exact same component, also use that attestation for their own due diligence (assuming for the purpose of this question that B learned of the existence of this attestation)? If the answer is 'no, it's recipient-bound,' could you help me understand what law or rule creates that restriction?
>
> It could be either. Attestations in their own right could just be a contractual relationship between the attestor and the manufacturer, not a document or object. It's also worth noting that the EU can write implementing regulations and delegated acts which set out such a system for the purposes of the CRA.
One of the concepts that gave me the shivers at the conference, was the concept of "downstream attestations". This can only happen if attestations would *not* be recipient bound. Which would completely invalidate any "business plan" for Open Source Stewards, especially for the smaller Open Source communities. Or am I missing something here?
> I hope these responses are useful!
Very much so!
Elizabeth Mattijsen
_______________________________________________
open-regulatory-compliance mailing list
open-regulatory-compliance@xxxxxxxxxxx
To unsubscribe from this list, visit https://accounts.eclipse.org
open-regulatory-compliance mailing list
open-regulatory-compliance@xxxxxxxxxxx
To unsubscribe from this list, visit https://accounts.eclipse.org
open-regulatory-compliance mailing list
open-regulatory-compliance@xxxxxxxxxxx
To unsubscribe from this list, visit https://accounts.eclipse.org
open-regulatory-compliance mailing list
open-regulatory-compliance@xxxxxxxxxxx
To unsubscribe from this list, visit https://accounts.eclipse.org