Le Cyber Resilience Act pour les auteurs d'extensions VS Code, sur le Marketplace et Open VSX

Vous publiez une extension Visual Studio Code, sur le Marketplace de Microsoft, sur Open VSX, ou sur les deux. Depuis le 11 septembre 2026, le règlement européen sur la cyber-résilience (CRA) demande à certains d'entre vous de signaler les vulnérabilités activement exploitées dans les 24 heures. Voici comment savoir si vous êtes concerné, ce que les deux registres attendent déjà, et ce qu'il faut mettre en place cette semaine.

Êtes-vous un « fabricant » ?

Le règlement s'applique à tout produit comportant des éléments numériques mis à disposition sur le marché de l'UE dans le cadre d'une activité commerciale (règlement (UE) 2024/2847, article 2, paragraphe 1, et article 3, paragraphe 1). Une extension est un logiciel. La seule vraie question porte sur l'activité commerciale.

Les considérants posent le test. Un logiciel libre et open source qui n'est pas monétisé par son fabricant reste hors du champ du règlement (considérant 18). Monétisé signifie, en pratique : vous fixez un prix, vous vendez une version pro ou une clé de licence, vous vendez du support payant, vous acceptez des dons qui dépassent la simple couverture de vos coûts, ou vous traitez des données personnelles au-delà de ce que la sécurité exige (considérants 18 et 19).

• Extension gratuite d'un particulier, licence open source, un lien de sponsoring qui couvre au mieux l'hébergement : hors du champ du règlement. Gardez cette configuration si vous voulez rester en dehors.
• Extension publiée par une entreprise qui vend un service (le client de votre SaaS, de votre base de données, de votre assistant IA) : elle fait partie de l'activité commerciale, même si l'installation est gratuite. Fabricant.
• Freemium, gratuite sur le Marketplace, fonctions pro débloquées par une clé de licence vendue sur votre site (le Marketplace n'a pas de bouton d'achat, seulement une étiquette « Free » ou « Trial ») : la version gratuite fait partie d'une activité commerciale. Fabricant.
• Badge « Verified Publisher » : il atteste un nom de domaine et six mois d'ancienneté du compte, rien sur l'argent. Il ne change rien ici.
• Open VSX : pas de frais, licences non open source acceptées. Le Publisher Agreement (v1.1, septembre 2025) fait de vous le distributeur de votre extension, seul responsable de celle-ci. Rien de trouvé n'indique qu'Eclipse joue le rôle de gestionnaire de logiciel libre (article 24) pour les extensions de tiers. Votre statut dépend de votre activité, pas du registre.

Une entreprise qui reprend votre extension et la republie sous son propre nom d'éditeur en devient le fabricant (article 22).

Ce qui s'applique maintenant, ce qui s'applique en 2027

« Activement exploitée » signifie que quelqu'un utilise la faille contre de vrais postes de développeurs, pas qu'un scanner l'a détectée. Quand un éditeur de sécurité publie une « exploitation dans la nature » visant votre extension, vos 24 heures ont commencé, ou ont commencé plus tôt si vous étiez déjà informé avant lui.

Des cas récents donnent une idée concrète, tous antérieurs à l'entrée en application. Code Spell Checker (CVE-2026-25931) : un fichier de configuration dans un dépôt cloné exécutait du code à l'ouverture, corrigé en 4.5.4, publié le 9 février 2026. Live Server (CVE-2025-65717, CVSS 9.1), Markdown Preview Enhanced (CVE-2025-65716) et Code Runner (CVE-2025-65715) : exfiltration de fichiers et exécution de code, 125 millions d'installations cumulées, et au 18 février 2026 seule Live Preview de Microsoft disposait d'un correctif. Les rapports publics ne disent pas si l'une de ces failles a été exploitée dans la nature. Deux cas de chaîne d'approvisionnement sans CVE : GlassWorm, 72 extensions Open VSX transformées en vecteurs à partir du 31 janvier 2026 via extensionPack, et une version 18.95.0 empoisonnée de nrwl.angular-console, en ligne onze minutes, à l'origine de l'exfiltration d'environ 3 800 dépôts internes de GitHub du 18 au 20 mai 2026. Au titre de l'article 14, un fabricant dont l'extension est ainsi retournée contre ses utilisateurs dispose de 24 heures, à compter du moment où il l'apprend, pour déposer une alerte précoce.

Ce que les plateformes demandent déjà

• Visual Studio Marketplace : le Publisher Agreement (janvier 2019) précise que c'est vous, et non Microsoft, qui fournissez l'extension, et que vous êtes seul responsable de ses fonctions de sécurité. Microsoft analyse chaque soumission, signe chaque extension, et bloque dans VS Code toute extension retirée ; en 2025, il a retiré 110 des 136 extensions examinées. Il ne publie pas de délai de correction.
• Open VSX : Eclipse ne fait aucune revue ; vous vous engagez à ce que votre extension ne contienne pas de code malveillant et à ce que sa collecte de données soit intégralement déclarée. Depuis mars 2026, chaque envoi passe une analyse obligatoire avant publication. Les signalements vont à [email protected], avec un accusé de réception sous deux jours ouvrés (politique du 9 avril 2026).
• Aucun des deux registres ne dépose votre rapport au titre de l'article 14 à votre place. Microsoft n'a publié aucune position sur le CRA pour les auteurs d'extensions ; les travaux d'Eclipse sur le CRA portent sur les gestionnaires et sur ses propres projets, pas sur les éditeurs Open VSX. L'obligation légale reste la vôtre.

Dans quelle classe se situe votre extension ?

La plupart des extensions sont des produits « par défaut » : auto-évaluation, sans organisme notifié. L'annexe III liste des produits « importants » pour lesquels une évaluation par un tiers peut être exigée, sauf si vous appliquez une norme harmonisée. Deux familles concernent VS Code : les gestionnaires de mots de passe, et les « logiciels qui recherchent, suppriment ou mettent en quarantaine des logiciels malveillants ». Une extension qui stocke et remplit des identifiants ou des clés d'API, ou qui analyse un espace de travail à la recherche de malwares, doit lire l'annexe III, classe I, avant de présumer une simple auto-évaluation.

Cette semaine, dans l'ordre

1. Déterminez votre statut avec le test de champ d'application gratuit. Huit questions, un résultat écrit avec les références d'articles. Extension gratuite sans activité commerciale : arrêtez-vous ici, et consignez cette décision par écrit.
2. Publiez un contact sécurité : un fichier SECURITY.md dans le dépôt, un security.txt sur votre site, et une politique de divulgation coordonnée des vulnérabilités en un paragraphe. L'annexe I, partie II, point 5, l'exigera en 2027 ; aujourd'hui, c'est ce qui pousse un chercheur à vous écrire plutôt qu'à publier sur un blog.
3. Rédigez la procédure des 24 h / 72 h sur une seule page : qui surveille les flux des éditeurs de sécurité, qui décide « exploité ou non », qui dépose le signalement sur la plateforme de l'ENISA, où se trouve le registre. Ajoutez une ligne pour le vol d'un jeton d'éditeur : révoquer, dépublier, puis signaler.
4. Générez votre SBOM. Pour une extension, cela veut dire package-lock.json ou son équivalent yarn ou pnpm, plus ce que votre bundler embarque réellement dans le VSIX. Le scanner gratuit lit le fichier de verrouillage et signale tout ce qui figure sur la liste CISA KEV.
5. Tranchez la question de la période de support. L'article 13, paragraphe 8, demande au moins cinq ans, sauf si le produit est destiné à être utilisé moins longtemps. Indiquez la date dans votre README et sur votre page de tarifs.

Le kit génère les treize documents qui soutiennent ces étapes à partir d'un seul formulaire, en anglais ou en français : politique de divulgation coordonnée, security.txt, procédure de signalement avec des modèles au format ENISA, déclaration de support, analyse de risques de l'annexe I et squelette de l'annexe VII. Trois d'entre eux sont visibles en entier avant tout paiement.

Où poser vos questions

Sur microsoft/vscode-discussions, posez vos questions dans Extension Development QnA et ne présentez votre produit que dans Extension Show and Tell. Le Slack VS Code Dev ne publie pas de règles de promotion : gardez-y la même séparation. Stack Overflow accueille les questions techniques sous le tag vscode-extensions. Pour Open VSX, ouvrez un ticket sur eclipse-openvsx/openvsx, ou écrivez à [email protected] pour les questions juridiques. Aucun fil sur le CRA entre auteurs d'extensions n'a été trouvé. Le groupe de travail Eclipse ORC, rejoint par l'OWASP en juillet 2026, anime les guides et les tables rondes de mainteneurs qui couvrent les questions propres à l'open source.

Sources : règlement (UE) 2024/2847 publié au Journal officiel ; Visual Studio Marketplace Publisher Agreement (janvier 2019) ; Microsoft, Security and Trust in Visual Studio Marketplace (11 juin 2025) ; documentation VS Code (15 septembre 2026) ; Open VSX Publisher Agreement v1.1 (septembre 2025), FAQ (8 mai 2024) et politique de sécurité (9 avril 2026) ; GlobeNewswire sur Eclipse et l'OWASP (30 juillet 2026) ; SentinelOne sur le CVE-2026-25931 (9 février 2026) ; The Hacker News sur quatre extensions VS Code (18 février 2026) et sur GlassWorm (14 mars 2026) ; Phoenix Security sur nrwl.angular-console (20 mai 2026). Ce n'est pas un conseil juridique.