Re-center this project on maintainers and open source projects, not stewards

[tobie]

TL;DR

This project currently assumes stewards as the default actor for CRA attestations. That framing is inconsistent with the CRA itself, misaligned with how the open source ecosystem actually works, and risks leading to regulation that excludes most projects, doesn't support maintainers, increases the burden on manufacturers, and undermines security outcomes.

Attestations are the key mechanism of the CRA to support and improve the security posture of the open source projects manufacturers rely on. To realize that potential, this work must center projects and maintainers, not stewards, and treat attestations as a business-model design problem, not an extension of existing stewardship structures.

---

Re-center this project on maintainers and open source projects, not stewards

The security attestation programs are intended to facilitate manufacturers’ due-diligence obligations by enabling them to financially support the open source projects they depend on so those projects can improve their cyber-resilience. If only stewarded projects can issue security attestations, then manufacturers and end-users will lose.

Yet the framing across this repository consistently treats stewards as the default (and often the only) actor for attestations, with a recent proposal even characterizing non-stewarded projects as transitional or undesirable states. This framing sidelines the community-driven structures that define most open source projects and were explicitly safeguarded during the CRA negotiations.

This steward-centric orientation needs to be thoroughly reconsidered.

1. Attestations are a unique economic and security opportunity; we should not squander it

Attestations offer a unique chance to design a system that aligns stakeholder interests:

• manufacturers gain lighter due-diligence paths,
• end-users gain better security outcomes,
• maintainers gain support to improve the projects everyone relies on.

A steward-centric approach will narrow this opportunity. It will inevitably lean on traditional membership-fee models that are under growing strain, do not scale beyond a handful of foundations, and have not solved sustainability challenges for the wider ecosystem nor for themselves.

Attestations could instead enable new business models and revenue streams that protect the non-manufacturer status of maintainers, build on the strengths of open source, and deliver the value the market absolutely needs for compliance. Realizing this requires treating attestations as a business-model design problem, not an extension of existing stewardship structures.

2. Steward-centric framing does not reflect the open source ecosystem

Most open source projects do not have stewards. Manufacturers rely heavily on these non-stewarded projects. Data from Black Duck’s audit of 965 commercial codebases across 16 industries in 2024 underscores this reality. The audit identified 282,521 unique JavaScript packages and 33,327 unique Rust packages used in real-world commercial software. Yet the foundations associated with these ecosystems (the OpenJS Foundation and the Rust Foundation) steward only 35 and 232 projects respectively. This illustrates at scale how the overwhelming majority of open source used by manufacturers is not and will never be stewarded.

Even if all of these projects wanted to move under a steward (most don’t), existing foundations could not meet that level of demand, nor should they be expected to. Any attestation model that treats stewardship as the default will not work for the overwhelming majority of the ecosystem.

The current framing across this repository reinforces this mismatch by implying that non-stewarded projects should ultimately “become stewarded.” This is neither scalable nor reflective of how open source communities organize themselves, and it overlooks the diverse governance models that make open source work.

3. The CRA is unambiguous: attestations are centered on projects and developers, not stewards

The only two places where the CRA addresses security attestations — Article 25 and Recital 21 — refer specifically to:

• “developers of [FOSS],” and
• “persons developing or contributing to [FOSS],”

and require that attestations reflect “the specificities of the free and open-source software development models.”

Stewards are not mentioned in either place.

A steward-centric design is therefore not aligned with the legal text. It marginalizes community-driven development models and leaves manufacturers to figure out due-diligence obligations for the many non-stewarded projects they depend on, while creating an uneven playing field and reshaping practices the CRA explicitly sought to protect.

4. This project will directly influence upcoming regulation; accuracy matters

The deliverables from this repository will be provided to the European Commission as input for a possible delegated act on security attestations. They will be interpreted as representing the open source ecosystem’s perspective.

A steward-first framing does not reflect that ecosystem and, if carried forward, will produce regulation that disadvantages independent open source projects and maintainers, burdens manufacturers, and leads to worse cybersecurity outcomes for EU citizens and businesses.

This repository must center FOSS projects and maintainers

The baseline assumptions of this project should be revisited, and the attestation work re-centered on open source projects and maintainers, consistent with:

• the reality of the open source ecosystem, where stewards are the exception, and
• the CRA’s explicit language.

This does not exclude stewards where they exist, but places them appropriately within the broader landscape of open source rather than at its center.

Finally, this effort must prioritize economic models that make the software supply chain sustainable; there is no open source security without open source sustainability.

[rozhukov]

I'd like to support this position. When I talk about Attestations within my company and with other companies, they currently don't see it something as useful at I think it should be, from a Manufacturer perspective. I also was leading a CRA workshop in Ghent where I here the same concerns from other manufacturers, when we discussed Attestation. A few concrete points:

• As Tobie pointed out - Attestation seems to be positioned as Steward-centric, which basically means bringing a monetization opportunity for them. It's not a bad thing, of course, but we'd certainly make sure it's not exploited as a "simple, scalable" revenue chain, with a questionable added value for projects. Simply adding tax for manufacturers who "rudely consumed FOSS" would not work, at least not that easy. (wearing my open-source hat, I'm 100% supportive to fund projects, don't get me wrong)
• If Attestations will be not-for-free (as we discussed different payment models at CRA workshop in Brussels) Manufacturers would need a solid guarantee when they actually pay for something. And this guarantee should come from those who are most knowledgeable about projects - maintainers. So, having Attestations as an exclusive thing for/by Stewards wouldn't work.
• I think that default Attestation should be flexible enough to suit any project, with any governance models, and for sure for those without Steward. There should be right for maintainers to decide, if they'd like to process Attestation transaction via Steward, but not a Steward's exclusive thing.

I'm happy to discuss further with the more context, I night have missed something.

[sjn]

Lots of good points! Thank you for sharing your thoughts.

This project currently assumes stewards as the default actor for CRA attestations. That framing is inconsistent with the CRA itself, misaligned with how the open source ecosystem actually works, and risks leading to regulation that excludes most projects, doesn't support maintainers, increases the burden on manufacturers, and undermines security outcomes.

What do you mean with "how the open source ecosystem actually works"?

There are LOTS of ways OSS ecosystems work. I'd even say it's easy to argue that each ecosystem does things their own way! (If this wasn't the case, then we'd all be using one ecosystem!)

And each ecosystem has it's own constellation of supporting projects and organizations; Some of them are well-organized with funds and bylaws and corporate backing – and others are impossible to organize and just happen work due to a high-trust culture and a common wish to interoperate (plus some tape and chewing gum).

You are correct at some points, though. The attestations are worth nothing if the relevant Maintainers aren't involved. Yes it is them who have to attest to a number of things being in place, correct, and promised, but that doesn't mean it's the Maintainer that have to manage the attestation regime!

Let's keep in mind that the median project size is one (1). These projects are already overworked, understaffed, and require all kinds of support - in addition to the new requirements from the EU.

I'd say it's better to assume most Maintainers aren't interested in setting up a Steward. They still need to exist, though, and while some communities and ecosystems (communities of communities) may have a "close fit" in their existing foundations, we need to also take all the others into account.

Instead, let's see if we can design a "Steward" organization framework from a first-principles perspective, in such a way that all the different communities can make use of it. And yes – this means any open source project should STILL be able set up their own Steward organization to handle this work – possibly by following a template developed in this forum. It also means that existing Foundations (or other "main supporting organizations") should be able to adopt and adapt this framework.

If only stewarded projects can issue security attestations, then manufacturers and end-users will lose.

What's the problem here? They are already gaining almost all benefits from using open source projects! It costs them near-zero to use it, and they don't have to hire hundreds of developers, and they can choose to remain a bystander (or freeloader, if you will) without consequence!

So yes, they will "lose" a part of the MASSIVE GAINS they've had for DECADES now. This is not a problem. This is an over due, fair and required market readjustment.

It will inevitably lean on traditional membership-fee models that are under growing strain, do not scale beyond a handful of foundations, and have not solved sustainability challenges for the wider ecosystem nor for themselves.

Nothing is inevitable at this point.

I think you are correct to point out the risks, though.

For me, the sensible path forward is to look at the Steward role independently from existing organizations. Let's approach it from a first-principles perspective.

(This is by the way what I've been trying to do on behalf of the CPAN ecosystem - where we don't have any supporting organizations that fit well into any "Steward" concept we can imagine.)

Even if all of these projects wanted to move under a steward (most don’t), existing foundations could not meet that level of demand, nor should they be expected to. Any attestation model that treats stewardship as the default will not work for the overwhelming majority of the ecosystem.

Yes, the scaling issue is real, though this is a task that lends itself to automation, don't you think?

(I have more comments, but those will have to wait. Sorry! – I think we're 80% in agreement, including some points around the suitability of existing foundations fitness to the work Steward needs to facilitate)

[tobie]

Thanks for your comments, @sjn. Just briefly addressing two key points.

What do you mean with "how the open source ecosystem actually works"?

What I mean is precisely what you’re saying: that it is diverse and can’t be reduced to one system. Also, that it is mostly un-stewarded, and will stay this way.

Yes, the scaling issue is real, though this is a task that lends itself to automation, don't you think?

This is one of the key aspects imho: no one will pay for the bits that are easy to automate. They’ll be provided for free by platforms, package managers, etc. So there’s limited value in focusing on them. The value lies in enabling the necessary but hard to scale aspects where maintainers have an edge.

[oej]

Seems like we should dedicate a meeting to discuss this in order to have an agreement on how we proceed.

[maximbaele]

I'd love to join the discussion if you're going to have one.

I agree with your original statements Tobie. The focus should be on projects and maintainers first, with the nuance that I believe the role of stewards could be important in this context. As enablers, not as gatekeepers.

[AevaOnline]

Thanks, all, for the discussion, and especially to Tobie for the continual feedback to refine this work. I'm reworking the PR to try to find a balance between the "recentering on projects" and "designing a steward framework" that you have both suggested.

I wanted to just respond to a few comments inline...

@tobie wrote:

[the open source ecosystem] is diverse and can’t be reduced to one system. Also, that it is mostly un-stewarded, and will stay this way.

100% agree. I hope my PR did not seem to imply anything else -- it was intended to only "solve part of the equation", with subsequent PRs adding more to it.

@rozhukov wrote:

Simply adding tax for manufacturers who "rudely consumed FOSS" would not work

The CRA will, in effect, increase the cost of consuming FOSS for most companies by creating compliance requirements for including 3rd party FOSS, even if it is only measured as risk of fines when misuse is discovered.

My understanding of the goal of Article 25 is precisely to lower this cost: not by adding an undesired tax, but by giving the markets (and each manufacturer) a lower-total-cost choice between (1) doing nothing and ignoring their due diligence obligations, (2) paying for assessors who would perform duplicative work across the markets' reuse of FOSS, or (3) hiring staff to address the compliance requirements of 3rd party components.

@sjn wrote:

Instead, let's see if we can design a "Steward" organization framework from a first-principles perspective, in such a way that all the different communities can make use of it. And yes – this means any open source project should STILL be able set up their own Steward organization to handle this work – possibly by following a template developed in this forum. It also means that existing Foundations (or other "main supporting organizations") should be able to adopt and adapt this framework.

Well said. I do not think we should assume that all "Steward" organizations of the future will look like the foundations of today.

For what it's worth, I would like to see a stewardship model emerge from our communities' work which makes becoming a Steward an appealing and easy option for those maintainers who wish to be compensated by the society which depends on their labour.

[tobie]

100% agree. I hope my PR did not seem to imply anything else -- it was intended to only "solve part of the equation", with subsequent PRs adding more to it.

Great. The whole repository, however, is framed around the idea that these attestations are issued by stewards. That needs to be fixed.

As you suggest in your reply to @sjn above, there's probably a need for additional legal structures in the future to help with foss maintenance. What’s important to note, however, is that these structures might not necessarily match the steward role as defined in the CRA. For example, you can imagine a steward offering to issue attestation for the dependencies of the projects it is stewarding without necessarily stewarding them too. For those dependencies, that steward would be a third party.

It is therefore essential that we don’t accidentally corner ourselves by focusing on stewards here, and instead make sure that we enable a plethora of options that meet the varying needs of our communities.

[rozhukov]

The CRA will, in effect, increase the cost of consuming FOSS for most companies by creating compliance requirements for including 3rd party FOSS, even if it is only measured as risk of fines when misuse is discovered.

My understanding of the goal of Article 25 is precisely to lower this cost: not by adding an undesired tax, but by giving the markets (and each manufacturer) a lower-total-cost choice between (1) doing nothing and ignoring their due diligence obligations, (2) paying for assessors who would perform duplicative work across the markets' reuse of FOSS, or (3) hiring staff to address the compliance requirements of 3rd party components.

I don't disagree with this. I'm trying to make sure we create the right message for manufacturers (which is to make "support FOSS" as the best option out of others) and deliver it in the rightly wrapped way. And I think I'm representing concerns from the manufacturer who is extremely biased towards doing it right way. Unfortunately, the most of other manufacturers and their decision makers will not care about this option just because FOSS ecosystem needs support. Out of your options, I'm mostly concerned about the another one (4) Fork and improve/fix silently internally (which is a subset of (3) hiring staff), but would be simply the more predictable for manufacturers.

That's being said, in my opinion, leverage Attestations as only "finally good vehicle to get money from ugly consumers who otherwise did not want to pay" is a dangerous idea.

To Tobie's point - I'm 100% supportive of making sure a valid (and the most credible) option to produce Attestation should be by maintainers themselves, as all communities are diverse, and work differently with their "stewards", even if they have them.

[maertsen]

This project currently assumes stewards as the default actor for CRA attestations. That framing is inconsistent with the CRA itself, misaligned with how the open source ecosystem actually works, [..]

This seems accurate.

and risks leading to regulation that excludes most projects, doesn't support maintainers, increases the burden on manufacturers, and undermines security outcomes.

This seems inflated. (This list is worst-case conjecturing without supporting facts, though I certainly understand a need to encourage readers to read on.)

Great. The whole repository, however, is framed around the idea that these attestations are issued by stewards. That needs to be fixed.

I look forward to seeing proposals discussed that explore how to expand the utility of VSAs beyond issuance by Stewards for the benefit of projects and their maintainers.

[sjn]

FWIW; I think we're quite capable of putting together a sensible idea of what should be expected from a Steward, at the same time as we take into account the constraints stemming from the Maintainers' realities.

So I'd like to propose we NOT re-center this project, but instead make it clear up-front what we expect the typical and/or worst-case situation Maintainers operate under, and use this as one of the leading lights a Steward needs to follow.

Furthermore, I think we should NOT think of a Steward as "whatever the EU Commission thinks it is", and ask them a bunch of questions. They have put some expectations forward for us, and it is up to "the communities" to come up with some interpretations on how these expectations may be met.

1. For a handful well-organized communities, the answer is easy - they have already a supporting organization, and they only have to a bunch of security-related activities to their mandate.
2. For the commercial entities out there who publish open source code, the situation is also easier - they have an existing organization in place, and a way to fund the work. Whether or not they get to operate as a Steward or a Manufacturer is up to each and every one of the to figure out by themselves.
3. For the independent open source projects out there who DON'T have a supporting organization, their questions are mostly the same as the two above, but they have a couple additional ones:
   1. Do I have to have a Steward at all?
   2. …And if I do, can I associate myself (select/come to an agreement with) with an existing one?
   3. …And if I this is not an option, what is expected of me if I decide to set up my own Steward organization?

It is the Steward which is the "new" entity in this landscape, so what we need to provide are ideas, guidelines, expectations and an overview of relevant requirements, taking into account ALL relevant factors – Both the Maintainers' constraints and realities, the Manufacture's requirements, what the Stewards is expected to do to bridge these two worlds and facilitate both security-related needs and how to execute on this in ways that are aligned with each project's needs for sustainability support and actual remuneration for any work that won't be done by volunteers.

With that in mind @rozhukov:

That's being said, in my opinion, leverage Attestations as only "finally good vehicle to get money from ugly consumers who otherwise did not want to pay" is a dangerous idea.

Why is this "dangerous"? We already know that the vast majority of users out there behave like bystanders or freeloaders, and that a subset of these are quite deserving of being called names. To these, we can and should say "you have now had your dinner, and now it's time to pay the bill" – especially if they wish to continue to confidently sell their projects in the European Union.

Furthermore, we should keep in mind that there are LOTS of FOSS projects out there who may have hundreds of Manufacturers among their users, and who aren't really interested in struggling with the administrativia around this. Yes when an assurance has to be made (e.g. "I, the Maintainer, have published a Security Policy, and promise to abide by it until the next release with significant changes"), a bunch of these MUST be made by the Maintainer, but some may also be done in cooperation with the Steward (e.g. "We, the Steward, attest to the presence of a Security Policy, and that it contains the expected information, as listed in ").

What I'm saying is that there are plenty of reasons to NOT "re-center" this work, but that we should definitely take all the relevant constraints and requirements into account when we continue our work.

Some of the constraints come from the CRA itself, some come from the realities of the different open source projects and communities (and meta-communities, when they are present), some come from the presence and organizational resources of supporting organizations (like the language/ecosystem foundations), and some come from the individual human needs found among the the stakeholders themselves, and how the gap between their needs and the manufacturers' requirements can be bridged without any of the negative behavior we should expect from Manufacturers.

Oh – And just to remind ourselves – Some projects out there need constructive attention and support MUCH more than others. It's not the big and well-known successful ones!
The ones we have to include early and support well, are the projects that are tiny and under-resourced, but still popular enough to be in wide use! Let's call them the "Second quintile projects in the OSS long tail" – Useful enough to be widely used, but so small they don't have the resources to get on anyone's radar until a crisis hits.

[tobie]

3. For the independent open source projects out there who DON'T have a supporting organization, their questions are mostly the same as the two above, but they have a couple additional ones:
   1. Do I have to have a Steward at all?
   2. …And if I do, can I associate myself (select/come to an agreement with) with an existing one?
   3. …And if I this is not an option, what is expected of me if I decide to set up my own Steward organization?

Just to be clear @sjn, and with all due respect, there's NO WAY this framing will work for the JS ecosystem (nor do I suspect it'll work for many others).

[sjn]

there's NO WAY this framing will work for the JS ecosystem (nor do I suspect it'll work for many others).

Why not?

Happy to have some weaknesses pointed out, and to spend some extra time on honing these arguments so they properly map on to the landscape! 😸

I'm also speaking from my own experiences, and wouldn't be surprised at all that other FOSS communities operate in radically different ways than the ones I know.

What questions do you think are likely to be posed in the JS ecosystem, that we could add to the list above?

[jmaris]

This is a great conversation, my two cents:

Re-center this project on maintainers and open source projects, not stewards

I agree, although I don't believe it should be focussed on any particular entity type first. I do believe that stewards should be one of the entities that can issue attestations. Again, to go back to the Commission's original model for this: Stewards should redistribute money received from attestations to project developers for their work. I believe they are the best-suited body to do so.

• If Attestations will be not-for-free (as we discussed different payment models at CRA workshop in Brussels) Manufacturers would need a solid guarantee when they actually pay for something. And this guarantee should come from those who are most knowledgeable about projects - maintainers. So, having Attestations as an exclusive thing for/by Stewards wouldn't work.

Agreed, but I believe that a good steward should act as an intermediary between maintainers and 3rd parties. In particular, paying devs for their expertise both in the development of the project, and in the knowledge needed to create attestations.

This is one of the key aspects imho: no one will pay for the bits that are easy to automate. They’ll be provided for free by platforms, package managers, etc. So there’s limited value in focusing on them. The value lies in enabling the necessary but hard to scale aspects where maintainers have an edge.

Strong agree. It is the social, technical and organisational aspects that cannot be automated that will have value, although an attestation should contain many of the things that can be automated, of course!

For what it's worth, I would like to see a stewardship model emerge from our communities' work which makes becoming a Steward an appealing and easy option for those maintainers who wish to be compensated by the society which depends on their labour.

I could also imagine a world, for example, where a steward more closley resembles a fiscal host.

A steward-centric approach will narrow this opportunity. It will inevitably lean on traditional membership-fee models that are under growing strain, do not scale beyond a handful of foundations, and have not solved sustainability challenges for the wider ecosystem nor for themselves.

for me, a membership-fee model is one of many models that could be used for the issuing of attestations.

[tobie]

I agree, although I don't believe it should be focussed on any particular entity type first.

To be clear, this was in reaction to this whole repo being completely centered on stewards despite the Article 25 specifically calling out FOSS developers but not even mentioning stewards. Case in point, the title of the overview still exclusively focuses this work on stewards.

Again, to go back to the Commission's original model for this: Stewards should redistribute money received from attestations to project developers for their work. I believe they are the best-suited body to do so.

That is no longer in the text. The reality of the ecosystem doesn't align with your belief that foundations are best suites to re-distribute money. In fact, the presence of fiscal hosts proves otherwise.

[…]

I could also imagine a world, for example, where a steward more closley resembles a fiscal host.

Except that's not aligned with the legal text. Fiscal hosts don't meet the definition of a steward outside of possible rare corners cases.

[…]

for me, a membership-fee model is one of many models that could be used for the issuing of attestations.

Of course. I'm not arguing it shouldn't be. I'm just stating that we shouldn't limit ourselves to this.

[tieguy]

there's NO WAY this framing will work for the JS ecosystem (nor do I suspect it'll work for many others).

Why not?

Because it assumes the only three outcomes are being a steward, joining a steward, or creating a steward? And most maintainers are self-evidently not particularly interested in any of those three things?