The OSS Ecosystem Steward

33 minute read Salve J. Nilsen

Warning

This document is a DRAFT, and still missing important details expected to be published by the EU Commission regarding the CRA Article 25 Attestation regime.

Please return later! Any comments and concerns about the text is also quite welcome in the meantime.

The concept, in three sentences

A maintainers’ co-op, owned by the people who serve and take care of a volunteer-based software ecosystem’s projects, services, and communities.
Companies pay it for proof that the code and ecosystem they rely on is looked after, and the money goes back to the people who look after it.
Maintainers receive support for the additional work needed, while retaining full control of their project, enjoying doing what they wish on a dugnad basis (the Danish and Norwegian tradition of neighbours pitching in on shared work).

Summary

The EU Cyber Resilience Act (CRA) makes manufacturers responsible for the security of every component in their products, including the Open Source ones. Many of these businesses will need help from the Open Source projects they depend on to become and remain compliant.

The CRA introduces a new kind of organisation to provide this help: the Open Source Software Steward. A Steward works well for a foundation supporting tens or hundreds of projects, but an ecosystem like CPAN has tens of thousands of projects, and no existing organisation able to take on the role.

This document proposes a variant of this organisation, designed for that scale: the OSS Ecosystem Steward.

Key features

Community-owned – owned by ecosystem participants: the project maintainers, service administrators and community organisers who choose to join.
Co-operative – democratically governed, with voluntary, opt-in membership that allows ecosystem participants to leave and rejoin.
Non-profit – any surplus goes back to the projects, services and communities in the co-op and the ecosystem.
Funded by manufacturers – mainly through enrolment fees and recurring Voluntary Security Attestations, which help manufacturers show their market surveillance authorities that the Open Source projects they rely on are both supported and viable for use in their products.
Dedicated to improving the long-term sustainability and security posture of its OSS communities – by donating enough of its surplus to fund a meaningful part of a working week per maintainer, administrator or organiser.

Background: The CRA and Open Source

When the (EU) Regulation 2024/2847 (Cyber Resilience Act) comes fully into effect on 11 December 2027, businesses that want to be compliant must perform a number of security-related tasks for each of their CE-marked products, and for the remote data processing solutions those products rely on.

What is in scope?

The details of what is in scope are beyond this document, but the CRA Guidance (e.g. CRA Guidance chapter 2) and the CRA FAQ (e.g. CRA FAQ 1.1.2) cover it in depth.

In short, the CRA applies to both digital and physical products placed on the EU market in the course of a commercial activity. This includes their remote data processing solutions – e.g. online services or APIs the product needs to function as expected.

Important

This includes phone apps, their server components, and any other solutions used to keep the product updated, secure and compliant.

The problem: Manufacturer obligations that reach upstream Open Source projects

The complete set of manufacturer obligations are also beyond the scope of this document, but the most important ones are laid out in Article 13, Article 14, Article 64, Article 69, Annex I, Part I, Annex I, Part II, Annex II, and Annex VII.

Many of the obligations falling on the manufacturer have implications for the Open Source communities in use. Some of the most relevant are:

Obligation on the manufacturer	Example implication for upstream Open Source
The product must have a support period that matches its expected use (e.g. 5 years). (Article 13(8))	Any Open Source component used in the product, or in its remote data processing solutions, should be supported for the same period.
Security updates must remain available for at least 10 years after issuing, or until the support period ends, whichever is longer. (Article 13(9))	Software update services that depend on Open Source need to stay secure and available for the same period.
The product must have no known exploitable vulnerabilities while it is on the EU market. (Annex I, Part I (2)(a))	The product must be updatable for its entire support period, including with relevant updates from its Open Source components.
Information about the product must be complete, correct and not misleading. (Article 64(4))	This includes any metadata provided in an SBOM, which also must be kept current with upstream projects (e.g. tracking changes in ownership, project name, version number schema, license, etc.)
Vulnerabilities and fixes found must be shared with the upstream maintainer. (Article 13(6))	Someone upstream needs to be available to receive, adopt and apply these fixes, ideally in a timely manner.
The manufacturer is responsible for the security of the entire product. (CRA FAQ 4.1.1, CRA FAQ 4.3.6)	There is no transfer of liability to Steward or Maintainer, so the liability remains with the Manufacturer, even for the Open Source components used in the product and in its remote data processing solutions, their transitive dependencies, and their metadata.
The manufacturer must perform a cybersecurity risk assessment, and exercise due diligence when integrating components. (Article 13, Article 14)	Depending on the number of products and their risk profiles, due diligence may cover hundreds or thousands of Open Source components. It also covers the long-term security posture, viability and concerns around the governance of those components – for the entire support period.
Market Surveillance Authorities may evaluate the product, and if corrective action is insufficient, require it to be withdrawn or recalled from the market, or issue fines. (Article 52, Article 54)	If a vulnerability in a product is discovered and exploited before the manufacturer has its ducks in a row, this can quickly become expensive.

The choice facing Open Source ecosystem participants

From the examples above, we should expect that many businesses using Open Source may be unwilling or unable – or simply lack the resources – to become and remain compliant without at least a minimum of involvement from the OSS ecosystems they rely on.

This forces the project maintainers, service administrators and community organisers in these ecosystems into a Hobson’s Choice:

Either they take steps to demonstrate that their project is intended for use in the course of a commercial activity,
or they do not – and risk that a (possibly significant) share of their users are forced to switch to alternatives that allow them to remain compliant.

Declining has security consequences for everyone using the project. Accepting brings a lot of boring and tedious compliance work. Neither option is attractive, and in the end, each maintainer has to decide for themselves.

From a security perspective, our common goal should be to make the choice realistic, and fair, so to increase the likelihood that more maintainers choose to accept it. Here is where the Open Source Software Steward has a critical role to play.

What is an Open Source Software Steward?

The CRA defines a new legal category – the Open Source Software Steward – in Article 3:

[…] a legal person, other than a manufacturer, that has the purpose […] of _systematically providing support on a sustained basis for the development of […] free and open-source software […] intended for commercial activities, and that ensures the viability of those products.

(For details, see Recital (19), Article 24, CRA Guidance chapter 3 and CRA Guidance section 3.3.)

In practice, the Steward’s main purpose is to help Open Source projects improve their long-term security posture, and their viability for use in CE-marked products.

Why this is hard for an entire ecosystem

For smaller, well-organised communities – e.g. those already supported by a foundation – the Steward’s tasks are quite manageable. Even the largest Open Source foundations support projects numbering in the tens or hundreds, and even then they have the benefit of being able to impose policies onto the projects in their care.

For an ecosystem like CPAN, the picture is very different. CPAN alone has tens of thousands of projects, and would struggle to meet even the basic expectations of the CRA described above. Even if we limit ourselves to the few hundred projects most likely to be used directly in Products with Digital Elements (PwDE – the CRA’s term for the products it regulates), there remains a long tail of smaller projects hidden among the transitive dependencies, also in use.

To make it worse, there are further complications for CPAN specifically:

No existing candidate – The greater CPAN ecosystem has no existing organisation that is willing, competent and able to take on the Steward role.
A laissez-faire tradition – The CPAN community has long operated in a laissez-faire way, letting each individual decide for themselves whether to act or not. Any Steward must respect this.
A fiercely independent culture – Many maintainers look with scepticism at any centralising “authority”, which has been acknowledged for decades with the Perl and Raku Foundation’s “hands-off” and “servant leadership” philosophy for supporting the community. Succeeding in imposing even basic requirements like security policies or viability requirements on projects, is therefore quite unrealistic, if this is to happen on a volunteer basis.

So instead of trying to fit the Steward’s tasks onto existing governance structures, we ask a different question:

How do we apply the Steward function to an entire ecosystem on the community’s terms?

Designing a Steward for an ecosystem on the community’s terms

Here, the answer is to create an entirely new organisation, designed from first principles for a global, laissez-faire, distributed and heterogeneous community of communities – like the Perl and CPAN ecosystem.

Guiding questions

With awareness of the existing traditions, values, habits and culture of the ecosystem: what type of organisation would align best with these?
What communities, organisations and governance structures exist already, and how can we include them as participants, regardless of their role in the ecosystem and their organisational maturity?
Which communities would also benefit from support, but are usually forgotten?
How can we make every part of the Steward function voluntary and opt-in, so that all parties are free to join, leave and rejoin as they wish?
Which demands on the communities are strictly necessary, and what structures must the Steward have in place to support those demands on a sustained basis?
How can we minimise the scope and demands placed on projects, as well as motivate them to take part in the requirements that remain?
How can we do all this, while each individual remains fully in control of the projects, services and communities in their care?

Design criteria

From these questions, we arrive at the following criteria.

Be a non-profit, dedicated to supporting its communities.
Be community owned, allowing individuals and communities affected by the CRA to have a say in how the Steward may support them.
Be governed fairly, through a transparent and democratic decision-making structure.
Be freely joinable and leavable at will by anyone in the community affected by the CRA.
Limit imposing obligations on members to the minimum required so they may continue managing their projects as they wish, but from now on, with project viability, security and compliance needs of their users sufficiently covered.
Make membership a marker of viability by ensuring the membership criteria themselves are the tasks that need to be done to demonstrate viability and compliance.
Operate as a business, generating a surplus by selling compliance-relevant security attestations, capable of sustaining its communities through donations.
Work well with outside parties to fulfil its obligations towards market surveillance authorities, manufacturers and others.
Operate without need for donations and instead aim to create an additional source of funding, suitable for OPEX budget line items of manufacturers wishing to remain compliant.
Be able to support others inside, upstream and downstream of the ecosystem – including projects, services and communities we rely on, but that are easily forgotten or “hidden” in the dependency graph.
Limit its scope so it only applies to projects, services and communities that are actually in use by manufacturers, or that otherwise offer a service benefiting the community.
Ensure member projects, services and communities remain fully self-owned and independent so that members remain in control of their project.

The proposal: A community-owned non-profit co-operative

An OSS Ecosystem Steward is a community-owned non-profit co-operative, set up to support the people in the ecosystem who are affected by the CRA, and who wish to help improve their users’ security posture.

Community owned

The project maintainers, service administrators and community organisers who voluntarily choose to opt in become the owners of their Ecosystem Steward. Here, it is important to acknowledge that Open Source projects are not alone in ensuring the overall health and security posture of their software and ecosystem. If you are an active participant in the ecosystem, and affected by the CRA, you may apply for membership.

Why these three groups?

Project maintainers – because the security posture of their projects (and the resulting component releases) is at the centre of the manufacturers’ concerns, and is where manufacturers are likely to find their largest compliance-related costs.
Service administrators – because manufacturers and maintainers alike rely on these to publish, identify, download, resolve, test, discuss and learn about the software they use. These services have to remain available and secured for everyone using them – for the community and users alike.
Community organisers – because there is no real Open Source without the meetings, conferences, workshops, summits, tutorials, booths and other venues where networks of trust and support are built, and where we can learn and teach the skills we need.

Non-profit

Open Source relies heavily on volunteer spirit, and on individual motivation to create something cool or make something cool happen. In Norway, we call this spirit “dugnad” or “dugnadsånd” – the willingness to help your neighbours improve something you share, or something found in the commons. Clean up the neighbourhood after a long winter. Renovate the local children’s playground. Or, for your digital neighbours: contribute a fix for a vulnerability, organise a conference, or run a service everyone relies on.

Many activities are central to our communities’ overall health, and are almost always done by volunteers. And some of this work is hard – even impossible – to find volunteers for, because it is “too boring”, “too tedious” or just unappealing. For that work, we need support mechanisms that motivate people to do it anyway – for example funding that makes it possible to spend one weekday (20% FTE) on Open Source.

Many of us contribute to Open Source as a break from corporate and for-profit life. So the Steward must not support these communities the way a for-profit business would. Ecosystem participants are not hired, and don’t receive a wage.

They are independent co-owners who receive donations, with no strings attached beyond what is expected as a member. And the Steward must never become another way to extract value from the communities it supports.

Conveniently, the CRA also encourages Open Source Software Stewards to operate as non-profits.

As a non-profit, the Steward must use any surplus on:

Member support donations, according to a disbursement formula decided by the General Assembly.
Non-member support donations, according to a disbursement formula decided by the General Assembly.
Re-investment into the Steward itself, according to a disbursement formula decided by the General Assembly.

Co-operative

A co-operative is a member-owned legal entity, where any surplus from its operation is used for the benefit of its members. Co-operatives follow the seven Rochdale Principles, as formulated by the International Co-operative Alliance:

Voluntary and open membership – Co-operatives are voluntary organisations, open to all persons able to use their services and willing to accept the responsibilities of membership, without gender, social, racial, political or religious discrimination.
Democratic member control – Co-operatives are democratic organisations controlled by their members, who actively participate in setting their policies and making decisions. Men and women serving as elected representatives are accountable to the membership. In primary co-operatives members have equal voting rights (one member, one vote) and co-operatives at other levels are also organised in a democratic manner.
Member economic participation – Members contribute equitably to, and democratically control, the capital of their co-operative. At least part of that capital is usually the common property of the co-operative. Members usually receive limited compensation, if any, on capital subscribed as a condition of membership. Members allocate surpluses for any or all of the following purposes: developing their co-operative, possibly by setting up reserves, part of which at least would be indivisible; benefiting members in proportion to their transactions with the co-operative; and supporting other activities approved by the membership.
Autonomy and independence – Co-operatives are autonomous, self-help organisations controlled by their members. If they enter into agreements with other organisations, including governments, or raise capital from external sources, they do so on terms that ensure democratic control by their members and maintain their co-operative autonomy.
Education, training, and information – Co-operatives provide education and training for their members, elected representatives, managers and employees so they can contribute effectively to the development of their co-operatives. They inform the general public – particularly young people and opinion leaders – about the nature and benefits of co-operation.
Cooperation among cooperatives – Co-operatives serve their members most effectively and strengthen the co-operative movement by working together through local, national, regional and international structures.
Concern for community – Co-operatives work for the sustainable development of their communities through policies approved by their members.

These principles map directly onto the design criteria above: voluntary membership, fair and democratic governance, and a surplus used for the benefit of the community.

A note on the co-op legal form

The Ecosystem Steward would additionally do well to be set up as a European Cooperative Society (Societas cooperativa Europaea (SCE)).

This lets it operate under a single EEA-wide set of rules, and allows it to move its headquarters to the member state where it is most likely to succeed in its non-profit mission.

Note

Details on articles of association, bylaws and such, will be published later.

Value proposition for manufacturers

The key value proposition comes from the manufacturer’s compliance needs that are uncovered during their product risk assessment and subsequent due diligence work. As part of this due diligence, the manufacturer should consider the following:

Intended for use in the course of a commercial activity: Are the OSS projects used in the PwDE meeting the same “light-touch” compliance obligations Stewards have in the CRA?
1. Vulnerability and incident handling is documented and compliant
2. Maintainers and administrators are committed to be available to respond to emergencies in a timely manner
3. Security-critical metadata about the components are kept current, complete and correct
Viable and sustained for this use: Are these same projects likely to remain sustained for the duration of the product’s support period?
1. Necessary policy, governance and support structures in place and adhered to
2. Suitable long-term commitments are on offer
3. Options for sustained funding from manufacturers are on offer, and the manufacturer is making use of these

The Steward facilitates the needs uncovered during this due diligence by encouraging affected maintainers to opt in and take steps to meet these needs where required. The Steward then confirms when the projects meet the compliance expectations, and attests to this together with the maintainer.

This initial work is funded through a manufacturer enrolment fee, and sustained through the sale of the same attestations.

To make this also an attractive path for maintainers to opt in, the Steward organisation’s ownership model and decision making processes are key, as is preserving the maintainers’ continued independence.

Value proposition for the OSS community

By qualifying, and then opting in to become a member of the Steward, the community member becomes eligible to receive a portion of the Steward’s surplus in the form of recurring donations
- …where the donation amount is according to the Steward’s disbursement formula,
- …up to a level that can cover their expenses, including a meaningful part of their living costs.
Additionally, those who qualify as a member in good standing – who take additional steps to ensure their long-term viability, are eligible to receive additional donations, also in accordance with the disbursement formula.
As a member, they also get an invitation to the Steward organisation’s General Assembly, where they can…
- …propose surplus disbursement formulas,
- …vote on which surplus disbursement formula on offer is to be used until the next General Assembly, and
- …elect candidates to the board.

To qualify for Steward membership, the applicant has to:

Be an individual owner or primary maintainer of a project, a service administrator or a community organiser, or represent a legally registered entity dedicated to the same.
Operate on a non-profit or volunteer basis.
Maintain a project that is reported as used by a manufacturer, or maintain a required upstream project or service, or organise or administer a community or service that supports the ecosystem participants in general.
Demonstrate that they have fulfilled the minimum required to show their project or service is intended for use in commercial activities, including any relevant “light-touch” compliance obligations that apply to the Steward.
Willingly state they are committed to the long-term care of their project, as long as this care is sufficiently supported by the Steward’s sustaining activities.
Commit to improve their project long-term viability and governance, including publishing succession and sunset plans and policies.
As long as they are a member, take part in issuing voluntary security attestations confirming the claims above, and allow the Steward to use these attestations to generate the surplus needed for this venture to fulfil its purpose.

If a project fails to meet any of the criteria above, the projects get an opportunity to rectify this in a timely manner – or failing that – risk losing their membership. Manufacturers will be notified by the Steward of any relevant, substantial or long-term changes like these, so they may conduct a risk assessment and act accordingly. If a project’s membership criteria are fulfilled at some point later, they may of course freely apply for membership again.

If a project wishes to leave the Steward, they only have to declare that the project’s Steward organisation is a different one (or none). When the most recent attestation expires, no new attestations are issued or signed by the Steward, and their membership commitments end.

Value proposition for Market Surveillance Authorities

TBD

Funding model

Addressing the CRA’s implications should not be expected to happen on a volunteer basis.

The Steward must therefore operate in a way so its revenue sources generate a surplus large enough to offer the necessary support to its members and related communities, in a long-term sustainable way, that helps achieve and maintain the security posture manufacturers require for their products to remain compliant.

Revenue sources

Public funding – until the Steward operation is established and proven sustainable.
Enrolment fees – paid by manufacturers when enrolling, and when re-enrolling.
Voluntary Security Attestations – issued on a recurring (subscription) basis. (See below)

The Steward should eventually not require donations or public funding once its regular revenue sources are capable of producing a surplus suitable for its purpose.

Voluntary Security Attestations

Warning

As of 2026-11-08, the EU Commission hasn’t published any guidance or delegated act on the Article 25 Attestation regime. Until anything is published, the following is a speculation on how this regime may work.

With this said, there aren’t really that many ways of using an attestation regime in service of the requirements in the CRA. An attestation regime that doesn’t allow for any avenues to sustain the open source projects relevant for PwDE, would be useless at providing any motivation for OSS maintainers to voluntarily play along.

Until the EU Commission publishes any details on the Article 25 attestations, we assume the following:

A Voluntary Security Attestation (VSA) is a claim issued by a maintainer, signed by the Steward, attesting to the viability and intention of their Open Source project, for use in PwDE. The CRA explicitly opens for such attestation programmes in Recital (21), Recital (117), and Article 25.

Acknowledging the Steward (once) – The Steward notifies a market surveillance authority of its existence and intended scope. The authority verifies and acknowledges it, and issues a certificate the Steward can use to sign Voluntary Security Attestations with.
A manufacturer starts using a project (as needed) – The manufacturer performs a risk assessment, and with due diligence reports its use of a project to the Steward. The Steward reports to the manufacturer the project’s current status, and tells the project maintainer it is in use.
The project joins the Steward (once) – If the maintainer wishes – they apply for their project to become a member of the Steward, by demonstrating the project is viable, compliant and intended for use in PwDE. The Steward affirms this, updates the project’s status towards relevant manufacturers, and confirms membership is accepted.
The project maintainer attests to their project’s compliance and viability (as needed) – This attestation includes relevant viability and compliance markers, suitable for demonstrating the project is intended for use in commercial activities.
The Steward signs the project’s attestation (on a recurring schedule) – The manufacturer requests a VSA for the project. The Steward reaffirms with the project that it is still compliant, signs the VSA, and sells it to the manufacturer. Part of the surplus is donated to projects, communities and services in the ecosystem, according to the Steward’s disbursement formula.
Audit (eventually) – When a market surveillance authority audits the manufacturer’s product, the manufacturer presents the signed VSA, which the authority can verify.

---
title: Sequence diagram for issuing of Voluntary Security Attestations
config:
    theme: redux-color
    layout: elk
    look: classic
---
sequenceDiagram
    autonumber
    participant MA as Market Surveillance Authority
    participant MFG as Manufacturer
    participant ES as OSS Ecosystem Steward
    participant OSS as OSS Project / Maintainer
    note over MA,ES: Once: Establish Steward
    ES->>MA: Notify of existence
    MA-->>ES: Verify & acknowledge
    MA-->>ES: Issue certificate for signing attestations
    note over MFG,OSS: As needed: Using an OSS project
    MFG->>OSS: Depends on project
    MFG-->>MFG: Perform risk assessment
    MFG-->>ES: Report project usage of OSS
    ES-->>MFG: Inform about current project status
    ES-->>OSS: Inform about project use
    note over ES,OSS: Once: OSS Project becomes Steward member
    OSS->>ES: Request to become Steward member
    OSS-->>ES: Demonstrate OSS is suitable for PwDE
    ES-->>OSS: Affirm suitability for PwDE and willingness to issue VSA statements<br>Update project status
    ES-->>OSS: Confirm membership
    note over MFG,OSS: On a Sustaining schedule: Attest OSS Project is intended for use in PwDE
    OSS->>ES: Attest to suitability and<br>viability by issuing VSA statements
    MFG->>ES: Request VSA for OSS
    ES-->>OSS: Reaffirm statements in VSA
    ES-->>ES: Confirm VSA by signing it with<br>certificate from Market Surveillance Authority
    ES->>MFG: Sell signed VSA
    ES-->>OSS: Donate surplus to projects, communities and services<br>Update project status
    note over MA,MFG: Eventually: PwDE audit
    MA->>MFG: Audits product compliance
    MFG-->>MA: Presents signed VSA
    MA-->>MFG: Verifies signed VSA
    note over MFG: Product is compliant

The next steps (TODO)

As of this writing, there are several outstanding tasks before this concept can be put into effect. Each of these can and will be addressed in the coming months.

Acknowledgements

The OSS Ecosystem Steward concept is the product of many conversations with many people. Some are mentioned here, and the ones that are not still have my gratitude.

Alistair Woodman
Arne Sommer
Greg Wallace
Laurent Hosen
Stig Palmquist
Æva Black

References

(EU) Regulation 2024/2847 (Cyber Resilience Act)
CRA FAQ (original source)
CRA FAQ - linkable copy (by the Open Regulatory Compliance Working Group, ORCWG)
CRA Guidance
ORCWG
Hobson’s Choice
Rochdale Principles
Societas cooperativa Europaea (SCE)