| Re: [open-regulatory-compliance] Kicking off the CRA Attestations project |
Hi All,
I'm a bit concerned that one angle seems to be missing from the attestations discussion, so I'll share it here. Generally, I wouldn't like us to propose mechanisms—even when they are opt-in—that create unnecessary expectations and burdens for projects or manufacturers.
The discussion seems to be heading in the direction of what we should improve in how open-source collaboration works today. This is a good goal, but we should keep in mind where we are today. Not all is bad; in fact, much of it is quite good.
Those who wrote the attestation-related provisions in the CRA likely used existing non-open-source collaboration models when writing the requirements. They likely didn't do so out of malice, but rather because they didn't know better. A good-faith assumption leads me to think that many others in the process have similar gaps in understanding open source.
We seem to be assuming that attestations require something more than what is already done today. Maybe. But we should initially focus on all the great practices that already exist and do provide assurances to manufacturers that things are quite good—not bad, and in fact, often great.
I'm referring to practices like the following, which de facto improve the security posture of open source and likely have not gained the attention of those who wrote, e.g., the attestation-related articles, recitals, etc.:
Using (e.g.) git provides a state-of-the-art audit trail of blame and version control.
Development in public provides transparency.
Established code review practices.
Accepting contributions from industry participants allows manufacturers to participate in development/fixing.
Public issue tracking enables further transparency.
Public communication channels (email lists, Slack, etc.) enable direct communication.
Using LICENSE files and other similar files (like README, CONTRIBUTING, AUTHORS, even SECURITY) to document existing practices.
Usage of an open-source license and sharing of the source code enables digital sovereignty for manufacturers at a level not available in any other collaboration model. This may be something that even the writers of the CRA were aware of. This is a core strength of open source and should not be dismissed.
We can think of a longer list of current, popular practices that de facto improve the security posture of open-source projects.
My point is, the extreme low-end position is that it will be far simpler for a project to provide an attestation that they use git and have plans to continue using git than to attest to something more complicated. It is far simpler for manufacturers to do their due diligence on thousands of FOSS dependencies when the threshold is set correctly, even if the threshold in the previous sentence is, alone, too low.
So, let's not inadvertently raise the bar to something more from OUR viewpoint. Let's raise the bar from the standpoint of those who wrote the CRA in good faith but are not very well versed in open source. This will mean raising the bar—when attestations are considered—for low-attention, yet important open-source projects. But medium, good, and excellent projects should be our benchmark. For them, attestations would be a documentation exercise or a funding opportunity based on incremental improvements. For manufacturers, the correct level of the bar allows them to focus on the real problems—the low-attention, yet important projects—while recognizing that the open-source landscape as a whole is already quite strong.
Best, Martin
On 10/28/2025 11:07 PM, Tobie Langel via open-regulatory-compliance wrote:
Alistair,
I don't know what, if anything, the Commission has in mind for the delegated act on security attestations. What I have seen however, is that substantial parts of the CRA are lifted nearly word for word from the Blue Guide, and so I expect similar things to happen here.
Recital 21 specifically mentions Enisa's Certification Scheme, which implements EUCC through a delegated act: https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ:L_202400482. So I wouldn't be surprised if that document ends-up as a source of inspiration for security attestations.
So rather than spending too much time thinking about the words used in the CRA (or their meaning in the US context per Victoria's follow-up email), I suggest going through the EUCC delegated act to get a grasp of the mechanics and intent and consider what it would look like if, quoting Recital 21, it "[took] into account the specificities of the free and open-source software development models."
When it comes to scale (and implementation), I think the main thing to compare it to is CE-marking. While CE-marking itself doesn't entirely resolve your due diligence requirements, it greatly simplifies them. Unsurprisingly, checking for CE-marking is the first thing that the horizontal standards tell you to do. In the words of the Commission, security attestations are to be thought of as a near equivalent to the CE-mark, bringing similar benefits to the due diligence obligations of manufacturers as the CE-mark does. They should therefore be relatively similar in terms of implementation.
Much like third regular products self-assess to apply the CE mark, so should most FOSS components. The requirements of self-assessment for security attestations should be lower but not too far away from what is required of manufacturers to self-assess. And the schedule of self-assessment should also be similar (on major version changes or when features are added that change the risk profile). So I'm definitely not expecting a centralized entity handling this, nor is the Commission.
Once we've made progress on the attestations, I believe we'll still need to create standards for open source components similar to what ETSI has just published for important and critical product categories in order to harmonize our practices, see proposals here:
We'll then have all of the pieces of the puzzle to help manufacturers meet their due diligence obligations, attest that they do so, and support their FOSS dependencies implement more secure practices and deliver more secure code.
--tobie
On Tue, Oct 28, 2025 at 9:12 PM Alistair Woodman <awoodman@xxxxxxxxx> wrote:Tobie,
very useful set of pointers and thoughts. I will pick up on the first point in the first 2 paragraphs.
[From Tobie]FWIW, the German text uses the word Bescheinigung, not Beglaubigung. My understanding is that Bescheinigung confirms that something is true or has occured (e.g. passing an exam), while Beglaubigung confirms the authenticity of something (e.g a certified copy).
The closest examples to security attestations are ENISA's certification schemes mentioned in Recital 21, the only concrete example of which is… the EUCC (see related delegated act which is well worth a cursory read).
This I think is a very useful point of semantics that I think we need to get our heads around. Imo (as a relatively competent German speaker), There is some overlap in common usage, such that we ought to focus attention on the differences.
1) Bescheinigung (Certificate) is something that I expect to come from a Regulated Authority / Entity and be given to (less entrusted) people / entities. Thinking of Driving Licenses, Marriage Certificate, etc
2) Beglaubigung (Certification, Affidavit, Notarization) is something that I expect when some (less trusted) person or entity wants to formally declare something or some item to be original or an accurate copy or a sworn statement that binds the thing to the person / entity attesting to it. Such statements are made to a (more trusted or entrusted) Notary.
Since I expect ‘CRA Attestations’ to happen very offen, maybe > 100K a day at OS repo scale, I cannot see one central entity doing this ‘at quality’. My assumption (present mental model) is that a highly decentralized model is more appropriate, where individual maintainers and small projects can make statements (such as: pull request X fixes issue Y and W says so at time Z) about what they have done and maybe that the Stewards act as Notaries to such statements. While Stewards might make more complex statements after full CI/CD testing etc, that might start to ‘smell’ like Certificates, I still think Affidavit is the best model, from Wikipedia: (https://en.wikipedia.org/wiki/Affidavit)
An affidavit is typically defined as a written declaration or statement that is sworn or affirmed before a person who has authority to administer an oath. There is no general defined form for an affidavit, although for some proceedings an affidavit must satisfy legal or statutory requirements in order to be considered.[1] An affidavit may include,
- a commencement which identifies the affiant;
- an attestation clause, usually a jurat, at the end certifying that the affiant made the statement under oath on the specified date;
- signatures of the affiant and person who administered the oath.
In some cases, an introductory clause, called a preamble, is added attesting that the affiant personally appeared before the authenticating authority. An affidavit may also recite that the statement it records was made under penalty of perjury.
Thoughts ?
/a
On Oct 28, 2025, at 16:40, Tobie Langel <tobie@xxxxxxxxxxxxxx> wrote:
On Tue, Oct 28, 2025 at 2:03 PM Alistair Woodman via open-regulatory-compliance <open-regulatory-compliance@xxxxxxxxxxx> wrote:Elizabeth, greetings and comments inline.On Oct 28, 2025, at 11:22, Elizabeth Mattijsen via open-regulatory-compliance <open-regulatory-compliance@xxxxxxxxxxx> wrote:In my understanding, an attestation is a contract between two entities: the manufacturer, and the attestation provider.The general sense of the word ‘Attestation’ in english (and ‘Beglaubigung’ in German) is *not* of a contract, but of a ‘statement under oath’. I.e. the Attestor makes an Affidavit (Statement under oath, with a jeopardy of either perjury or negligence) to an entity with civil or legal authority (Notary, Judge, Police, Priest etc). WRT the CRA, the details of process are still TBD, but my assumption is that the actual Attestation is *not* a contract, but that could be used as part of a contract or process or supply-chain verification thingy to.
FWIW, the German text uses the word Bescheinigung, not Beglaubigung. My understanding is that Bescheinigung confirms that something is true or has occured (e.g. passing an exam), while Beglaubigung confirms the authenticity of something (e.g a certified copy).
The closest examples to security attestations are ENISA's certification schemes mentioned in Recital 21, the only concrete example of which is… the EUCC (see related delegated act which is well worth a cursory read).
The challenge is to adapt such a model (which works by giving manufacturers the ability to demand higher prices by demonstrating that they meet certain specific security requirements) to a completely different economic model, while making sure not to turn maintainers or stewards into manufacturers in the process (which would entirely defeat the purpose).
For example, consider Article 33(1) of the EUCC Certification Scheme delegated act which states that "[t]he holder of an EUCC certificate shall establish and maintain all necessary vulnerability management procedures in accordance with […]". There are similar requirements in Annex I of the CRA, so that's an interesting example to consider.
Imagine adapting something like this to the economic model of open source with the hope of getting similar security outcomes for the end-product.
We can't place that requirement on the project. That wouldn't make sense, as the CRA clearly puts the obligations on the manufacturer. So what could we do instead?
Perhaps an attestation could state that an open source project and its dependencies are sufficiently supported by manufacturers so that the project is able to set up a security team that "establish[es] and maintain[s] all necessary vulnerability management procedures in accordance with [the CRA]"?
Perhaps the attestations could even focus on the support provided by a specific manufacturer to a project to enable this? i.e. tying the attestation to a combination of a project and a manufacturer and attesting that the manufacturer support enables the level of support required to meet the manufacturer's compliance obligations?
In this example, just like in the related certification schemes, the attestations just attest facts about the project (or possibly about the support provided by a specific manufacturer to a project). They're not contracts. They can however be used as bargaining chips to fund a stronger security posture and/or meeting more essential requirements, facilitating due diligence and sustaining open source in the process.
I'm not suggesting the above example is the right solution, but I believe it illustrates an actionable way to think about this problem.
--tobie
_______________________________________________ open-regulatory-compliance mailing list open-regulatory-compliance@xxxxxxxxxxx To unsubscribe from this list, visit https://accounts.eclipse.org-- Martin von Willebrand, CEO Double Open Oy Email: martin.vonwillebrand@xxxxxxxxxxxxxx www.doubleopen.io