| Re: [open-regulatory-compliance] Kicking off the CRA Attestations project |
_______________________________________________I started writing this yesterday and it picks up on something Scott wrote today that I agree with completely and feel is important. (Apologies in advance for the length - I tried to pare it down as much as I could)
Scott worte:think of open source communities as limited natural resources more than as traditional economic actorsFor me, this gets to the heart of the question - how does one value a piece of open source software?A pricing mechanism (or mechanisms) that people trust and see as fair seems necessary for there to be a scalable solution (or solutions) for the need for OSS Security Attestations.
Otherwise every Steward and Maintainer will be either winging it, reinventing the wheel, or, I worry, defaulting to the prevailing method I've heard in these conversations - namely Attestation-specific cost-recovery pricing.I suspect the "OSS is a public good" analogy, which first came on the scene with the Ford Foundation Roads and Bridges report, and that has been used a lot lately, may be why a public infrastructure pricing model is dominating the conversation.But the "OSS is a public good" analogy - at least insofar as it equates OSS to infrastructure - never really sat well with me.
- Public infrastructure is typically initiated and paid for by a central authority, usually a government.
But this is almost never true with open source. Almost all OSS emerges organically from private individuals or groups.
For this reason, I agree with Scott and others who say a better "real world" analogy for open source is natural resources. We even have the same concept of Sustainability in both the OSS and Natural Resource fields.
I think this is more than splitting hairs.- If we think of OSS, and by extension Attestations, as akin to public infrastructure, then it makes sense to also model OSS Attestation pricing on public goods/services.
But the cost-recovery pricing model has a huge flaw - it leaves money on the table for OSS Maintainers and perpetuates the gap Harvard researchers found between the cost to produce OSS ($4.15 billion by the author's calculation) and its demand-side replacement value ($8.8 trillion) - https://www.hbs.edu/ris/Publication%20Files/24-038_51f8444f-502c-4139-8bf2-56eb4b65c58a.pdf
If, on the other hand, we think of OSS as akin to a natural resource, like a fishery, then the OSS Attestation for a Manufacturer is more like an access fee, which is designed to promote responsible use and sustainability. To me, this is a much more useful model for our purposes.
Looking at how this could work in practice:
- x-vessel is a type of fishery fee used by NOAA Fisheries for some programs. The fee is calculated as a percentage of the total value of the fish landed per vessel. The language used to describe how the funds are invested is remarkably in line with conversations on OSS sustainability.
- An OSS Steward could similarly price access to the Attestation based on Manufacturer annual turnover. This seems like a better value capture model for OSS projects than cost-recovery and also seems like an equitable approach for Manufacturers
- Similar approaches are common today in Open Source Foundations with their Membership (usually 501c6) or Partnership (usually c3) program fees, which are often tiered by headcount (I do wonder tho if pricing as a % of turnover is better)
- One thing this group could consider is developing guidelines for Stewards and Maintainers on how to price and package their Attestation access. Pricing guidance could be based in part on the risk class the OSS is in, the SW's complexity, and its relative "doneness", while packaging guidance could depend on whether the org already has a Partner/Member program with graduated tiers based on company size and other factors.
- As for what happens if the Steward generates "excessive" income through the Attestation, I think there are a few important points to consider:
- Every OSS project I've been involved with has a substantial backlog of engineering and infrastructure projects. If part of the goal of the OSS aspects of the CRA is to promote overall OSS sustainability, then we should not limit Attestation fees to the cost to create / maintain the Attestation
- Cybersecurity costs are increasing, so if €X is required today 1.05 or 1.1€X will be required next year
- Though not the norm, there are precedents for OSS non profit compensation levels in line with the tech industry. I, for one, would like to see all the people we rightly recognize as open source heroes be compensated in line with the importance of their work. This could easily increase an average Foundation's budget by 50% and still be very much in line with salaries of other similarly experienced professionals.
- When one considers the EU's interest in increasing sovereignty for critical digital infrastructure and decreasing reliance on non-EU suppliers (e.g. saw this yesterday: https://digital-strategy.ec.europa.eu/en/news/commission-launch-digital-commons-edic-support-sovereign-european-digital-infrastructure-and), if this extends to OSS, it could imply new costs for projects.
- Many, perhaps most, OSS projects rely at least in part on donations for infrastructure. There is a risk associated with this, as many who use Equinix Metal are finding out. De-risking this has a cost.
- If after all this is factored in and the Attestation-derived income exceeds what is required for the engineering / infra backlog, to accomplish any digital sovereignty goals, de-risk infra donations, and to fairly compensate maintainers, then the org can lower fees the following year
- Or, perhaps the surplus could be pooled in a general OSS fund under the auspices of some trusted entity (or entities) to support rapid response to OSS-related incidents, raise awareness about the goodness of Open Source (as Martin articulated), and other goals common to all OSS.
- Bottom line, let's not sell ourselves short by defaulting to cost recovery Attestation pricing. Back of the envelope, Harvard found the demand side replacement value of OSS is $8.8 trillion. And another report from GitHub, LF, and Harvard found that $7.7 billion is invested annually in OSS. You could triple the amount invested in OSS to $21B (not that I'm recommending this or think this level of increase is "necessary") and even if the Harvard demand side number is high by $3.8 trillion, you'd still be left with an industry replacement cost for OSS that's 238 times more than the total annual investment.
Hope some of this is additive to the discussion and very interested in others' thoughts.Thank you,Greg Wallace
Mobile: +1 919.247.3165On Wed, Oct 29, 2025 at 5:59 PM Scott Lewis via open-regulatory-compliance <open-regulatory-compliance@xxxxxxxxxxx> wrote:_______________________________________________On 10/29/2025 3:18 AM, Tobie Langel via open-regulatory-compliance wrote:
Martin,
As the attestations purpose is to facilitate manufacturer due-diligence, it all boils down to how due diligence for open source ends-up being defined and how that definition evolves over time, Overall though, I can't imagine the mid-term expectations for open source differing widely from what's expected of closed source code.I disagree Tobie. I believe the fundamental policy (and legal) problem here is that...as Martin articulates very nicely, is that open source 'ways' of building secure/private systems (his list), are very different from those of closed source code. In many cases resulting in better/more secure systems.
And so we should plan ahead for when that time comes, even if we continue to advocate in parallel for reasonable due diligence requirements that are aligned with current industry best-practices.IMO, 'industry best-practices'...wrt security, liability, etc are still based upon having these systems/software being 'owned' by someone...for accountability. This just doesn't fit the notion of open source as a diverse and always changing community/group of people. Yes, there are lots of things learned over the last ~25 years about doing open source 'well', and those should certainly be included I believe, but also remember...open source is often just different from industry best practices of old...e.g. 'many eyes (transparency) make shallow bugs...aka more secure systems'.
Regardless, there's one thing that's always been true and that will remain so: open source projects won't find it easy to receive money for things they willingly do for free. It falls from that that attestations making claims about things that are quite clearly visible or already being done will have very limited value, imhoI agree that this is a hard problem. My answer would be to try to think of open source communities as limited natural resources more than as traditional economic actors, as markets generally do not place value on anything with price of $0. That does not, however, mean that something that costs you $0 (currently) has no value (e.g. air to breath, or infrastructure built over many years by people with diverse non-monetary incentives).
Scott
--tobie
On Wed, Oct 29, 2025 at 10:38 AM Martin von Willebrand <martin.vonwillebrand@xxxxxxxxxxxxxx> wrote:
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
_______________________________________________ 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
open-regulatory-compliance mailing list
open-regulatory-compliance@xxxxxxxxxxx
To unsubscribe from this list, visit https://accounts.eclipse.org