What the CRA asks of open-source software stewards

The Cyber Resilience Act treats free and open-source software supplied outside a commercial activity differently from a product placed on the market for money. Between "not covered at all" and "manufacturer", it creates a third position: the open-source software steward — a legal person, other than a manufacturer, that provides sustained support for the development of open-source software intended for commercial use by others.

Foundations, and the organisations that fund and maintain widely-used projects, are the intended occupants. Article 24 is what applies to them, and it is short.

The cybersecurity policy

Article 24(1) requires a steward to "put in place and document in a verifiable manner a cybersecurity policy to foster the development of a secure product with digital elements as well as an effective handling of vulnerabilities by the developers of that product".

Three words in that sentence do the work:

• document — the policy exists as a document, not as a practice everyone knows;
• verifiable — someone outside the project can check that it is what you say it is;
• by the developers — the policy is aimed at contributors you do not employ and cannot instruct, which is exactly why the article says foster and encourage rather than ensure.

The article says the policy should encourage developers to report vulnerabilities voluntarily, and should address documenting, addressing and remediating vulnerabilities, while accounting for the particular nature of open-source arrangements and promoting information sharing within the community.

If your project already has a SECURITY.md, a disclosure process and a maintainer who owns it, the distance to a documented policy is editing, not building.

Cooperating with authorities

Article 24(2) requires stewards to cooperate with market surveillance authorities, at their request, to mitigate the cybersecurity risks of a product qualifying as free and open-source software — and, on a reasoned request, to provide documentation in an easily understood language, on paper or electronically.

The practical version: know who would answer, and be able to hand over the policy and the vulnerability-handling history without a discovery exercise.

Which parts of Article 14 reach a steward

This is the part most summaries get wrong in one direction or the other. Article 24(3) does not make the whole reporting regime apply, and it does not exempt a steward from all of it.

• The Article 14(1) duty — notifying an actively exploited vulnerability — applies to stewards to the extent they are involved in the development of the product.
• The Article 14(3) and Article 14(8) duties — severe incidents, and informing users — apply where the steward's own infrastructure supporting the development of the product suffers a severe incident affecting its network and information systems.

"To the extent of the involvement in the development" is a judgement, and it is yours to make and to record. A foundation that hosts a repository and funds two maintainers is in a different position from one that reviews and merges every release, and the article is written to let both answers be right.

What a steward does not have

No conformity assessment. No CE marking. No technical documentation under Annex VII. No declaration of conformity. Those belong to whoever places a product on the market in the course of a commercial activity — and that may well be a downstream company that ships your project inside its product. That company is the manufacturer of its product, not you of theirs.

A note on what our checker does today

Our scope checker currently reaches the steward role only through the answer "open source, supplied outside a commercial activity" — and that same answer produces a likely out of scope verdict, because the manufacturer obligations do not attach. The result is that a commercially-supported steward, who is the person Article 24 was written for, does not get a steward-specific verdict from us yet.

We would rather say that plainly than let the tool imply a precision it does not have. It is a known gap in our rule tables, recorded as such, and this guide is what we have in the meantime.

→ Run the scope check anyway — it will tell you whether the manufacturer obligations attach to anything you ship, which is the question underneath.