Re: [open-regulatory-compliance] Kicking off the CRA Attestations projec

[Elizabeth Mattijsen <eclipse@xxxxxx>]

Am also pretty new to this, so please correct me if I'm incorrect.  Also, I hope my Dutch directness isn't too offensive.

> On 27 Oct 2025, at 17:59, Alice Sowerby via open-regulatory-compliance <open-regulatory-compliance@xxxxxxxxxxx> wrote:
> Hi everyone. I'm super new to the CRA world, I was at the event in Brussels last week and I keep having the same idea pop into my mind about how to tackle this challenge. I will post it below as food for thought. Happy to have it severely critiqued!

In my understanding, an attestation is a contract between two entities: the manufacturer, and the attestation provider.

The contract provides three functions (simply put):
1. The attestation provider states that the software in question is free of known issues for a given version at a certain time.
2. It provides the manufacturer with a guarantee that if an issue is found, the attestation provider can be contacted within a certain timeframe (24h I believe), and that the attestation provider will provide an update within a certain period (1 week I believe).
3. If the manufacturer did not find the issue, then the attestation provider will inform the manufacturer of the issue (provided this is still in the "warranty period"

Your approach reduces attestations to commodities that can be traded.  Which I think is also a race to the bottom, which in end will kill Open Source as we know it.

> 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.

Having a functionality to make it easier for a manufacturer to obtain the necessary attestations for all of their Open Source software, would definitely be nice to have.  But I don't think adding a centralized hub to a world that already has too many SPFs, would make much sense.

On the subject of updates for software with vulnerabilities that need a timely dispersion, one could think of content distribution networks.


> Centralized Attestation Registry for Open Source 
> 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. 
> In summary:
> 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.

This feels very much like yet another organization in the making that will make lots of money, to be spent on non-related costs.  "A small portion could be kept to pay for the attestation registry costs" makes me shiver, as "small" has not been defined here.

"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."

Although the idea behind this is commendable, who's going to decide which OSS projects get what?


Elizabeth Mattijsen