CRA Open Source Steward 2027 – politique de cybersécurité, procédures de gestion des vulnérabilités et attestation d’autorité | Word/PDF/Excel

Votre fondation, association ou organisation contribue-t-elle au développement et à la gestion à long terme de projets open source utilisés à des fins commerciales ? Dans ce cas, elle peut avoir le rôle d’open-source software steward conformément à la Cyber Resilience Act de l’UE – règlement (UE) 2024/2847. L’article 24 exige notamment une politique de cybersécurité vérifiable et documentée qui favorise un développement sécurisé, une documentation appropriée et la correction des vulnérabilités, ainsi qu’un signalement volontaire et un partage coordonné d’informations avec la communauté open source.

Différence importante par rapport aux modèles CRA classiques : Un steward est une personne morale autre que le fabricant qui soutient de manière systématique et durable le développement de certains produits open source destinés à des activités commerciales et joue un rôle essentiel à leur pérennité. Le fait d’être mainteneur, de contribuer au code pendant son temps libre ou de diriger une association ne suffit pas à déterminer automatiquement que l’organisation est concernée. Une organisation peut être steward d’un projet et fabricant d’un autre. Ce rôle doit être vérifié pour chaque produit ou version.

Dates : Les obligations de déclaration des fabricants au titre de l’article 14 sont entrées en vigueur le 11 septembre 2026. Les obligations particulières de déclaration des stewards au titre de l’article 24.3 débuteront le 11 décembre 2027. L’ENISA a confirmé cette distinction. Ce pack est donc spécialement conçu pour une préparation adéquate – et non pour prétendre que tous les stewards doivent signaler des incidents dès 2026.

Quelles activités peuvent réellement tirer profit du produit ?

Le public cible comprend les fondations open source, les associations professionnelles, les personnes morales à but non lucratif ou commerciales qui gèrent des infrastructures de dépôts ou de développement, fournissent une assistance organisationnelle ou technique à long terme et assurent la pérennité d’un produit FOSS pertinent. Par exemple, une fondation qui gère plusieurs bibliothèques et maintient un processus documenté de sécurité et de divulgation.

**Ce produit se distingue de nos modèles existants :** CRA Compliance pour les fabricants, évaluation des risques et SBOM se concentre sur les obligations générales des produits, tandis que CRA PSIRT – 24/72h et signalement des vulnérabilités soutient la gestion effective des incidents par le fabricant. Ce produit est spécialement destiné à la politique de l’article 24 du steward, à son rôle de gouvernance et à ses obligations limitées de déclaration et de réponse aux autorités.

Quelles exigences l’article 24.1 impose-t-il à un steward de logiciel open source ?

L’article 24.1 exige une politique de cybersécurité documentée et vérifiable qui favorise un développement sécurisé et permet aux développeurs de gérer efficacement les vulnérabilités. La politique doit notamment couvrir la détection, la documentation, l’évaluation, la gestion et la correction, tout en favorisant le signalement volontaire conformément à l’article 15 et l’échange d’informations au sein de la communauté open source. Elle doit être adaptée à la structure juridique et organisationnelle réelle de l’organisation. Il ne suffit pas d’écrire « nous respectons le CRA » – il faut indiquer les responsabilités, un contact de sécurité fiable, le processus, le numéro de version et des éléments probants réels.

Que prévoit la loi en cas de demande d’une autorité ?

Conformément à l’article 24.2, un steward doit coopérer avec les autorités de contrôle du marché afin de réduire les risques pour la sécurité. En cas de demande motivée, le steward doit être en mesure de fournir la politique documentée mentionnée au point 1, sur papier ou par voie électronique, dans une langue facilement compréhensible par l’autorité. Le pack contient les éléments nécessaires pour vérifier l’identité de l’expéditeur, rassembler les documents appropriés, protéger les données sensibles et conserver une véritable preuve de réponse.

Déclaration au titre de l’article 24.3 – deux situations distinctes

Vulnérabilité activement exploitée : La référence à l’article 14.1 s’applique à un steward dans la mesure où l’organisation participe effectivement au développement du produit numérique concerné. Incident grave : Les références aux articles 14.3 et 14.8 s’appliquent uniquement lorsque l’incident affecte les réseaux et les systèmes d’information que le steward fournit lui-même pour le développement des produits. Par conséquent, tous les bugs éventuels, les attaques contre un tiers ou les perturbations informatiques internes ne donnent pas automatiquement lieu à une obligation de déclaration au titre de l’article 24.3.

Le responsable doit documenter la date de prise de connaissance, le rôle exact, l’événement, l’évaluation juridique et le canal de déclaration effectif. La Single Reporting Platform (SRP) de l’ENISA constitue le point d’entrée officiel pour les déclarations applicables. Les modèles ne peuvent envoyer aucun message au nom du client et ne génèrent pas de véritables reçus SRP. Prévoyez les délais applicables et vérifiez l’interprétation juridique en vigueur auprès de l’ENISA avant d’effectuer la déclaration.

Quelles exigences ne s’appliquent pas automatiquement à un steward ?

La catégorie des stewards constitue un cadre réglementaire distinct et proportionné. L’organisation ne doit pas, au seul motif qu’elle est steward, délivrer la déclaration de conformité CE du fabricant, créer un SBOM de fabricant ou se soumettre à toutes les obligations techniques relatives aux produits prévues à l’annexe I du CRA. Les lignes directrices de la Commission européenne distinguent clairement les obligations du steward de celles du fabricant. Toutefois, l’exercice d’une fonction distincte de fabricant dans un autre projet modifie la situation.

Liste complète des fichiers

Fichier Excel avec neuf onglets et huit indicateurs administratifs testés

Les onglets s’intitulent Aperçu, Projet et rôles, Politiques, Vulnérabilités, Incidents, Déclarations, Affaires avec les autorités, Actions et Sources et guide. L’aperçu comptabilise les projets enregistrés, les évaluations de rôle non claires, les politiques manquantes, les vulnérabilités ouvertes, les incidents nécessitant une enquête, les déclarations non claires, les affaires avec les autorités sans réponse et les actions en attente.

Les huit valeurs sont toutes à 0 dans le fichier original. Des éléments de test synthétiques séparés ont donné la valeur attendue 1 pour les huit indicateurs. Les tâches de test ne figurent pas dans la version client. Aucune classification juridique, vérification externe, déclaration ou approbation par une autorité n’est effectuée automatiquement.

Comment utiliser les documents

1. Recensez chaque projet FOSS, éditeur, organisation de soutien, contexte de licence et d’activité commerciale.
2. Déterminez si chaque relation effective correspond à un steward, un fabricant ou n’est pas concernée. Conservez les fondements et la source.
3. Adaptez, adoptez et versionnez la politique de cybersécurité avec un canal de sécurité concret et des preuves de code ou de version.
4. Mettez en place une réception privée des vulnérabilités, un tri, des corrections, des tests de non-régression et une divulgation sécurisée auprès de la communauté.
5. Préparez l’évaluation de la déclaration pour le 11 décembre 2027. Distinguez les exploitations actives des incidents graves survenant dans l’infrastructure de développement du steward.
6. Établissez un processus pour les demandes motivées des autorités et rassemblez des éléments probants vérifiables et protégés par les règles de protection des données.
7. Mettez à jour le fichier Excel, suivez les actions et laissez la personne appropriée donner manuellement son approbation pour chaque affaire.

Questions fréquentes sur le CRA et les stewards open source

Une association à but non lucratif est-elle automatiquement exemptée du CRA ?

Non. Le rôle juridique et l’activité déterminent l’application. Une personne morale qui soutient systématiquement des projets OSS pertinents peut être un steward même sans but lucratif propre, mais une évaluation individuelle par projet est nécessaire.

Les mêmes exigences CE s’appliquent-elles aux stewards et aux fabricants de produits ?

Non. L’article 24 comprend des obligations distinctes. Un steward n’est pas automatiquement tenu de satisfaire à toutes les exigences CE, SBOM et relatives aux produits du fabricant. Si l’organisation est également fabricant d’un autre produit, d’autres exigences peuvent s’appliquer à ce dernier.

Quand commence l’obligation du steward de déclarer à l’ENISA ?

L’article 24.3 commencera à s’appliquer le 11 décembre 2027. Les obligations des fabricants au titre de l’article 14 sont entrées en vigueur dès le 11 septembre 2026. Il ne faut pas confondre ces deux groupes de dates.

Toutes les failles de sécurité doivent-elles être transmises à l’ENISA ?

Non. Une évaluation juridique est nécessaire, notamment pour déterminer s’il existe une exploitation effective, une participation du steward ou un incident grave particulier survenant dans l’infrastructure de développement du steward.

Une politique de sécurité générique suffit-elle ?

Non, si elle ne documente pas les processus réels de sécurité et de gestion des vulnérabilités exigés par l’article 24.1, et si elle ne peut être attestée par des responsabilités, des versions et des preuves de travail réels. Le modèle doit être adapté à l’organisation.

Le pack génère-t-il une déclaration effective à l’ENISA ?

Non. Le document 04 permet de préparer en interne la conformité juridique et technique. La déclaration effective doit être effectuée par une personne habilitée dans le canal officiel approprié, et seules de véritables preuves de réception doivent être saisies.

Que se passe-t-il si l’autorité exige notre politique ?

Vérifiez l’identité de l’autorité et la demande juridique formulée. Utilisez le document 05 pour rassembler la politique adoptée, la chaîne de preuves effective, la décision de réponse et la preuve de réception conformément à l’article 24.2.

Les cinq modèles de travail sont-ils tous disponibles en anglais ?

Non. Les cinq modèles de travail et le fichier Excel sont en suédois. Un guide d’utilisation en suédois et un English User Guide séparé sont inclus, mais pas une traduction intégrale de tous les documents de travail.

Sources juridiques, transparence et contrôle juridique

Règlement (UE) 2024/2847 – texte original, articles 3.14/24/71 · Commission européenne : CRA et open source · Commission européenne : déclarations au titre du CRA · ENISA SRP – dates et déclaration · Linux Foundation/OpenSSF – travail pratique du steward (non contraignant).

Version 1.0, vérification juridique des sources assistée par l’IA le 11 novembre 2026. Aucune révision juridique externe, classification effective d’une organisation, test d’intrusion, audit de cybersécurité, certificat CE ou déclaration effective auprès d’une autorité n’a été effectuée. Consultez les sources à l’occasion de futures lignes directrices et modifications juridiques. Livraison au format ZIP uniquement après publication éventuelle de la version préliminaire et liaison séparée des fichiers Shopify Digital Products.