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

[Elizabeth Mattijsen <eclipse@xxxxxx>]

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