Spoiler: the good news is that you may well be neitherÂ
Mike Bursell, Co-chair, OpenSSF Cyber Policy WG
The European Union’s Cyber Resilience Act (CRA) is a piece of legislation that covers all countries within the EU and the EEA and entered into force on 10th December 2024. It covers many types of devices and applications that are either sold or otherwise made commercially available on the European market and the intention behind it is to improve the cybersecurity of products available to consumers and businesses across Europe.
One of the key innovations the CRA introduces is explicitly acknowledging the role of open source: a novelty in the legislation coming out of the European Union. After about two years of lobbying by the OSS community there was a realization that open source is special and occupies a unique position in the software ecosystem. It both exists on its own and is part of most enterprise software products, and when you’re writing legislation that will impose requirements on producers of software, pretending either that it doesn’t exist or is the same as proprietary software ceases to be an option.Â
The CRA applies to what are defined as Products with Digital Elements (PDEs). A PDE is defined as “a software or hardware product and its remote data processing solutions, including software or hardware components being placed on the market separately.” There are specific roles defined within the Act, and the first to understand is manufacturer. A manufacturer is basically a person or company who sells PDEs (the specific details can be a little more complex, but are outside the scope of this article). Manufacturers have significant obligations that they must fulfil in relation to the PDEs that they provide, many of which are centred around conformance and compliance – you can find out more about these in the article “What will my business need to do for the EU CRA?”.Â
One of the things that manufacturers do when they create these PDEs is consume open source software. And when they consume it, that means that they need to be concerned with its cybersecurity properties: particularly, in the context of the CRA, the risks that it can help address, any known vulnerabilities, and the processes in place for dealing with incidents or vulnerabilities. And, as much as manufacturers might like the world to be different, it is a fact that the contributors and maintainers of open source projects have no obligation – legal or moral – to help those manufacturers, however nicely they ask or how many legal letters they send. The realization of this state of affairs was arguably the most important one within the context of the drafting of the CRA, at least from the point of view of the OSS community.Â
The other important realisation was that there do exist entities – people and organizations – who are willing and able to take on some of these tasks and work with those consuming open source projects as manufacturers. Some of these entities make a business out of doing so, and in that case, they are likely to be manufacturers themselves, within the definition of the CRA, as they are making offerings which are commercially available. The vendors of commercial Linux distributions or Kubernetes implementations are good examples of this business model. But there’s another type of entity – often but not always existing as not-for-profit Foundations – that nurtures, supports and distributes open source projects, providing upgrades, releases, community development, vulnerability management and all the associated governance processes around these. And does so without making a profit or making the open source software projects available commercially. And, to its great credit, the EU recognized the important and special place that these entities occupy within the software ecosystem. It decided to define these entities (whether individuals or organizations – “legal persons…?”) as open source software stewards, often just referred to as stewards. An example might be that the OpenSSF (which is part of the Linux Foundation) might be the steward for the Sigstore project, providing or coordinating support for it.
There’s been some debate about how good a term this is, but it’s fairly descriptive, and it’s what we now have, so what does it mean? The definition is helpful, particularly as it draws a contrast with manufacturers: “a legal person, other than a manufacturer, that has the purpose or objective of systematically providing support on a sustained basis for the development of specific products with digital elements, qualifying as free and open-source software and intended for commercial activities, and that ensures the viability of those products.” The phrase “legal person” just means a person or a legal organization, and the important point here is that stewards provide support for the development of open source software, ensuring the viability of those products. Â
It’s important to understand that the CRA does place obligations on stewards, particularly around vulnerability and incident management and reporting, both to EU-appointed bodies and users of the software, which will generally be the manufacturers. There are many fewer obligations, however, on stewards than there are on manufacturers.
One useful distinction that is often raised when discussing open source software is that between products and projects. If we think of products as commercially consumable versions of projects made available for profit, then a good rule of thumb is that manufacturers are interested in products, whereas stewards, maintainers and contributors are interested in projects. Sadly, this isn’t the language that the CRA uses when discussing stewards, but it’s a distinction which is generally pretty clear within the world of open source.
There’s a final point to be aware of here, which is that in realising that stewards exist and that they’re distinct from the usual roles of contributors and manufacturers. Which means that the CRA is also clear that just because you’re involved with an open source project – even in a leadership role as chief maintainers or benevolent dictator for life, for instance – that doesn’t mean that you’re a steward for it. There may be no steward for your project, even if it’s mature and ready for use in PDEs: we should expect that only some open source projects have stewards, and that’s absolutely fine. Not every maintainer is ready to take on the obligations of an open source software steward, or to work with a steward who might be interested in supporting the project. You may decide that you want to take on that role, for various reasons, and you might even decide to set yourself up as a manufacturer of a product based on the project, but you’re certainly not a steward (or manufacturer) by default.Â
Finding out more
For more information, we encourage you to:Â
- Visit the WG Repository: Global Cyber Policy WG GitHub
- Join Our Slack Channel: #wg-globalcyberpolicy on Slack
- Subscribe to Mailing Lists: