OpenSSF Defines Three Roles to Help Open‑Source Projects Meet EU Cyber Resilience Act

The European Union’s Cyber Resilience Act (CRA) introduces a set of security obligations for products that contain digital components, and the law has far‑reaching implications for the open‑source supply chain. To demystify these obligations, the Open Source Security Foundation (OpenSSF) published a preparation pathway in September 2026 that identifies three distinct roles within the open‑source community and outlines the duties each role must fulfil.

Three roles, three sets of responsibilities

The guide separates the ecosystem into (1) maintainers or contributors, (2) open‑source stewards and (3) manufacturers of products that embed open‑source code. This taxonomy is designed to match the legal language of the CRA, which distinguishes between parties that merely contribute code and those that market finished products.

Most non‑commercial contributors fall outside the definition of “manufacturer” under the CRA, meaning they are not automatically subject to the Act’s broad reporting and remediation duties. Their primary responsibility remains ensuring the quality and security of the code they produce, without the heavy compliance burden placed on commercial actors.

What a steward does

An open‑source steward is defined as a legal entity that provides long‑term support for projects that are used in commercial activities. Stewards take on coordination, governance and security functions, such as maintaining a security policy, handling vulnerability disclosures and facilitating cooperation among downstream users.

While the CRA does not impose specific obligations on stewards until 11 December 2027, OpenSSF recommends that they already implement best‑practice security contacts, escalation paths and collaborative processes. This proactive stance helps downstream manufacturers meet their own CRA deadlines.

Manufacturers face the strictest timeline

A manufacturer that sells a product under its own brand is the party with the widest set of obligations. Since 11 September 2026, manufacturers must report any actively exploited vulnerability or serious incident within 24 hours and issue a formal notification to customers within 72 hours. Failure to meet these deadlines can result in fines and market restrictions under the CRA.

• Maintain an up‑to‑date SECURITY.md file in every repository
• Provide a dedicated security contact address that is monitored continuously
• Adopt supply‑chain attestation tools such as SLSA, Sigstore, GUAC and OSPS Baseline
• Document escalation procedures and share them with downstream partners

The guide also stresses the importance of integrating these tools into automated CI/CD pipelines. By generating cryptographic provenance records (SLSA) and signing artifacts (Sigstore), projects can prove the integrity of their builds, a requirement that manufacturers will need to demonstrate when audited by EU authorities.

Because a single organization can occupy more than one role, the guide advises a clear internal mapping of responsibilities. For example, a company that both contributes to an open‑source library and sells a hardware device containing that library must treat the contribution side as a maintainer activity and the device side as a manufacturing activity, each with its own compliance checklist.

OpenSSF’s recommendations are not legal advice but are intended to help the community align with the CRA’s spirit. The foundation encourages stakeholders to consult legal counsel for definitive interpretations, especially as the CRA’s enforcement mechanisms evolve.

Practical steps for English‑speaking organisations

For English‑speaking organisations, the practical impact is clear: they must identify which of the three roles they occupy, adopt the security documentation and tooling suggested by OpenSSF, and establish rapid reporting processes for vulnerabilities.

By doing so, they reduce the risk of non‑compliance penalties and contribute to a more resilient open‑source supply chain across the EU market.

The pathway also highlights the need for continuous monitoring of upstream dependencies. Organizations are urged to subscribe to vulnerability feeds, perform regular dependency audits, and update affected components promptly to stay within the CRA’s remediation windows.

Training and awareness programs are recommended for all three roles. Maintainers should receive guidance on secure coding practices, stewards on governance frameworks, and manufacturers on incident‑response protocols to ensure a unified security posture.

Finally, the OpenSSF guide calls for community feedback. It invites projects, companies, and regulators to share experiences, report ambiguities, and propose refinements, aiming to evolve the guidance as the CRA matures and as new threats emerge.

Cette version française du texte a été adaptée pour les lecteurs francophones, tout en conservant l’exactitude des faits, chiffres et dates présentés dans l’article original.