EU Cyber Resilience Act — Guide for Open-Source Project Maintainer

The CRA's applicability to open-source software depends on whether the development activity constitutes 'commercial activity.' Article 2 and Recital 18 clarify that software developed entirely outside of commercial activity — by volunteer maintainers who receive no monetary benefit linked to the software — is exempt from CRA obligations. However, the commercial activity threshold is broad. If the project is developed by employees of a company as part of their work duties, if the project generates revenue through paid support or SaaS delivery, if the developer receives sponsorship payments, or if the company relies on the project commercially, the exemption is unlikely to apply. The European Commission has stated that a company releasing open-source code to fulfil its CRA obligations does not itself make that code in scope, but a company that builds a commercial product on open-source foundations remains responsible for the CRA conformity of the finished product.

Recital 18 and Article 2 create a specific exemption for what the CRA terms 'open-source software stewards' — natural or legal persons who provide ongoing support for open-source components that are intended for commercial use, without themselves commercialising those components. Stewards are subject to a lighter regime: they are expected to have a CVD policy, but are not required to complete a conformity assessment or produce a technical file. The Commission intends to publish guidance on what constitutes an open-source software steward, but the key distinguishing criterion is the absence of commercial activity relating to the software itself. Foundations such as the Linux Foundation or Apache Software Foundation are likely to qualify as stewards for the projects they govern. Individual maintainers who accept GitHub Sponsors payments may be in a more uncertain position and should seek legal advice.

Even if an open-source project is entirely exempt from CRA obligations, operating a credible CVD policy is a best practice that protects users and the broader ecosystem. A CVD policy for an open-source project should document: how to report a vulnerability (preferably through a private channel such as a GitHub private security advisory or a dedicated disclosure email); the maintainers' commitment to acknowledge receipt within a defined period (48-72 hours is standard); the expected timeline from report to patch (90 days for non-critical, 7-14 days for critical is typical); and conditions under which earlier disclosure might occur. A security.txt file at the project's primary domain or GitHub profile provides a machine-readable reference to the CVD policy. Projects hosted on GitHub can enable the built-in security advisory mechanism, which provides a private channel and automates CVE ID requests through GitHub's CNA partnership.

For open-source software stewards subject to the CRA's lighter regime, there is no explicit requirement to produce an SBOM. However, producing and publishing an SBOM with each release provides significant value to downstream manufacturers who integrate the project and must themselves maintain SBOMs for their CRA-compliant products. The downstream manufacturer's SBOM accuracy depends on the accuracy of SBOM data provided by the components they integrate. Open-source projects that generate SBOMs automatically from their package manifests — using tools that produce CycloneDX or SPDX output — make compliance easier for their users and reduce the likelihood that known vulnerabilities in project dependencies are missed in downstream assessments. Projects that do not publish SBOMs may find themselves deprioritised by procurement teams who need accurate component data.

Assess whether the project constitutes commercial activity by reviewing who contributes, whether any commercial benefit flows to contributors or maintainers, and whether any company relies on the project as part of a commercial product. If uncertain, seek legal advice or consult the CRA guidance being developed by the Open Source Initiative and ENISA. Regardless of CRA applicability, publish a security.txt file and a CVD policy document. Enable private security advisories on the project's repository if hosted on a platform that supports this. Generate and publish an SBOM as part of the release process. Set up monitoring for CVEs in the project's own dependencies, and establish a process to publish a new release or security advisory when a critical dependency vulnerability is discovered. Communicate clearly in the project README and release notes when a version will no longer receive security fixes.