| 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, Felix Am 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, --
Jordan Maris
EU Policy Analyst, The Open Source Initiative
tel: +33613141427Hi 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
|
