Elizabeth, greetings and comments inline.
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 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
