OpenSSF définit trois rôles pour aider les projets open‑source à se conformer à la CRA de l’UE

Le Cyber Resilience Act (CRA) de l’Union européenne impose de nouvelles obligations de sécurité aux produits contenant des composants numériques, avec des répercussions majeures sur la chaîne d’approvisionnement open‑source. Pour lever le voile sur ces exigences, l’Open Source Security Foundation (OpenSSF) a publié en septembre 2026 une feuille de route qui identifie trois rôles distincts au sein de la communauté open‑source et décrit les devoirs associés à chacun.

Trois rôles, trois jeux de responsabilités

Le guide segmente l’écosystème en (1) mainteneurs ou contributeurs, (2) gestionnaires open‑source et (3) fabricants de produits intégrant du code open‑source. Cette taxonomie suit le vocabulaire juridique du CRA, qui fait la distinction entre les parties qui ne font que contribuer du code et celles qui commercialisent des produits finis.

La plupart des contributeurs non commerciaux échappent à la définition de « fabricant » du CRA, ce qui signifie qu’ils ne sont pas automatiquement soumis aux lourdes obligations de déclaration et de remédiation du texte. Leur responsabilité première reste d’assurer la qualité et la sécurité du code qu’ils produisent, sans la charge de conformité imposée aux acteurs commerciaux.

Le rôle du gestionnaire

Un gestionnaire open‑source est une entité juridique qui assure le soutien à long terme des projets utilisés dans des activités commerciales. Les gestionnaires assurent la coordination, la gouvernance et la sécurité, par exemple en maintenant une politique de sécurité, en gérant les divulgations de vulnérabilités et en facilitant la coopération entre les utilisateurs en aval.

Bien que le CRA ne prévoie pas d’obligations spécifiques pour les gestionnaires avant le 11 décembre 2027, l’OpenSSF recommande d’adopter dès à présent des contacts de sécurité, des voies d’escalade et des processus collaboratifs conformes aux meilleures pratiques. Cette approche proactive aide les fabricants en aval à respecter leurs propres échéances CRA.

Les fabricants face aux délais les plus stricts

Un fabricant qui commercialise un produit sous sa propre marque est le sujet soumis au plus large éventail d’obligations. Depuis le 11 septembre 2026, les fabricants doivent signaler toute vulnérabilité activement exploitée ou tout incident grave dans les 24 heures et notifier formellement leurs clients dans les 72 heures. Le non‑respect de ces délais expose à des amendes et à des restrictions de marché prévues par le CRA.

• Maintenir un fichier SECURITY.md à jour dans chaque dépôt
• Fournir une adresse de contact sécurité surveillée en continu
• Adopter des outils d’attestation de chaîne d’approvisionnement comme SLSA, Sigstore, GUAC et OSPS Baseline
• Documenter les procédures d’escalade et les partager avec les partenaires en aval

Le guide insiste également sur l’intégration de ces outils dans les pipelines CI/CD automatisés. En générant des preuves cryptographiques d’origine (SLSA) et en signant les artefacts (Sigstore), les projets peuvent prouver l’intégrité de leurs builds, une exigence que les fabricants devront démontrer lors d’audits par les autorités européennes.

Comme une même organisation peut occuper plusieurs rôles, le guide conseille de cartographier clairement en interne les responsabilités. Par exemple, une société qui contribue à une bibliothèque open‑source tout en commercialisant un dispositif matériel l’intégrant doit traiter la contribution comme une activité de mainteneur et le dispositif comme une activité de fabrication, chacune disposant de sa propre checklist de conformité.

Les recommandations de l’OpenSSF ne constituent pas un avis juridique mais visent à aider la communauté à s’aligner sur l’esprit du CRA. La fondation encourage les parties prenantes à consulter un conseil juridique pour obtenir des interprétations définitives, notamment à mesure que les mécanismes d’application du CRA évoluent.

Pour les organisations francophones, l’impact pratique est clair : il faut identifier le ou les rôles occupés parmi les trois définis, adopter la documentation et les outils de sécurité préconisés par l’OpenSSF, et mettre en place des processus de signalement rapide des vulnérabilités. Ainsi, elles limitent le risque de sanctions pour non‑conformité et renforcent la résilience de la chaîne d’approvisionnement open‑source sur le marché européen.