L'ARC exige des mises à jour de sécurité sur plusieurs années : vos dépendances risquent de ne pas tenir aussi longtemps

Principaux enseignements

• En vertu de la loi sur la cyber-résilience, vous êtes tenu de corriger les vulnérabilités de votre produit, y compris celles de ses dépendances, pendant au moins cinq ans, sauf si son utilisation prévue est d'une durée inférieure.
• De nombreux frameworks open source bénéficient d'un support technique d'une durée d'un à trois ans ; ainsi, un produit lancé sur une version récente peut se retrouver privé des correctifs de sécurité fournis par l'éditeur avant la fin de sa période de support.
• Quatre solutions pour continuer à bénéficier de correctifs de sécurité une fois que le support en amont a pris fin : passer à une version plus récente, remplacer la dépendance, corriger le problème soi-même ou acheter les correctifs.
• Les obligations de signalement s'appliquent depuis le 11 septembre 2026 ; ainsi, une vulnérabilité activement exploitée dans une dépendance dont la fin de vie est déjà dépassée doit être signalée dès aujourd'hui, même s'il n'existe aucun correctif en amont à indiquer. Les règles relatives à la période de support entreront en vigueur le 11 décembre 2027.

La période de support prévue par la loi européenne sur la cyber-résilience (CRA) doit durer au moins cinq ans, sauf si la durée d'utilisation prévue d'un produit est plus courte. Les versions récentes de frameworks populaires tels que Laravel, Django et Spring Boot ont cessé de bénéficier de correctifs de sécurité open source dans un délai de 1 à 3 ans après leur sortie. Si vous commercialisez des logiciels développés à partir de ces frameworks, les correctifs en amont cessent d'être fournis avant la fin de votre période de support, et vous devez alors fournir vous-même les correctifs pour la durée restante.

Une période de support désigne la durée pendant laquelle un fabricant est tenu de continuer à corriger les vulnérabilités d’un produit. Au sens de la CRA, le fabricant est toute personne qui commercialise le produit sous son propre nom ou sa propre marque dans le cadre d’une activité commerciale, que ce soit à titre onéreux ou gratuit. L’obligation du fabricant de corriger les vulnérabilités s’étend à l’ensemble du produit, y compris ses composants. Les personnes chargées de la maintenance des bibliothèques sous-jacentes n’ont généralement pas d’obligation équivalente ; rien ne les oblige donc à continuer à corriger la version que vous commercialisez.

Les principales obligations prendront effet le 11 décembre 2027, une date qui peut sembler lointaine jusqu’à ce que l’on compare la durée de la période de support requise avec la durée pendant laquelle les frameworks que vous choisiriez aujourd’hui continueront de bénéficier de correctifs.

Exigences relatives à la période de soutien de l'ARC

La loi sur la cyber-résilience correspond au règlement (UE) n° 2024/2847. Aux termes de cette loi, on entend par « fabricant » toute personne physique ou morale qui développe un produit, ou le fait développer, et le commercialise sous son propre nom ou sa propre marque, que ce soit à titre onéreux ou gratuit. Elle définit la « période de support » comme la durée pendant laquelle le fabricant doit veiller à ce que les vulnérabilités du produit soient corrigées de manière efficace.

L'article 13 de la CRA impose aux fabricants de fixer une durée correspondant à la durée d'utilisation prévue du produit. Les attentes raisonnables des utilisateurs, la nature du produit et l'usage auquel il est destiné sont autant d'éléments à prendre en compte. Cette durée doit être d’au moins cinq ans. La seule exception concerne les produits dont la durée d’utilisation prévue est inférieure à cette durée, auquel cas celle-ci correspond à la durée d’utilisation prévue. Lorsqu’on peut raisonnablement s’attendre à ce qu’un produit soit utilisé pendant plus de cinq ans, la durée doit être plus longue. Les considérants de la loi citent comme exemples les routeurs, les systèmes d’exploitation et les systèmes de contrôle industriels.

Cette période s'accompagne de trois obligations. Les fabricants doivent publier des mises à jour de sécurité sans délai et gratuitement. La seule exception concerne les produits sur mesure, pour lesquels le fabricant et l'utilisateur professionnel peuvent convenir d'un tarif pour les mises à jour. La date de fin, indiquant au minimum le mois et l'année, doit être clairement précisée au moment de l'achat. Et chaque mise à jour de sécurité reste disponible pendant au moins 10 ans, ou jusqu'à la fin de la période de support si celle-ci est plus longue. Ces trois obligations s’appliquent aussi bien aux correctifs des composants open source intégrés au produit qu’à votre propre code. La date de fin publiée constitue un engagement public ; veillez donc à vous renseigner sur la durée pendant laquelle vos dépendances continueront de bénéficier de correctifs en amont avant de l’imprimer.

Remarque : les produits mis sur le marché avant le 11 décembre 2027 ne sont soumis aux principales exigences de la CRA que s’ils font l’objet d’une modification substantielle après cette date. Cela signifie une modification postérieure à la mise sur le marché qui affecte la conformité aux exigences de la loi relatives au produit ou qui modifie la finalité pour laquelle le produit a été évalué. L’article 14, qui porte sur les obligations de déclaration, fonctionne différemment : ses obligations s’appliquent aux produits concernés déjà présents sur le marché, et elles sont en vigueur depuis le 11 septembre 2026.

Combien de temps durent les dépendances courantes ?

Trois versions de frameworks, une pour Python, une pour PHP et une pour Java, ont récemment atteint leur fin de vie. Dans cet article, on entend par « fin de vie » la date à partir de laquelle un projet cesse de publier des correctifs de sécurité pour une version donnée.

Chaque projet formule cela différemment. Django parle de « fin du support étendu », Laravel précise à partir de quand les correctifs de sécurité ne sont plus fournis, et Spring parle de « fin du support open source ». Pour vous, cela revient au même, car la version que vous avez déployée ne bénéficie plus des correctifs fournis par l'éditeur.

Aucun des trois n’a bénéficié de cinq ans de correctifs de sécurité en amont, ce qui est le minimum exigé par la CRA. La date de sortie du framework importe toutefois moins que la date de lancement de votre produit, car votre période de support commence dès la mise sur le marché de ce dernier. Le jour du lancement, vérifiez la durée restante du support en amont du framework. Prenons l’exemple d’un produit lancé le 11 décembre 2027, date à laquelle les règles relatives à la période de support entrent en vigueur : sa période de support doit s’étendre au moins jusqu’au 11 décembre 2032. S’il est développé avec Laravel 13, sorti le 17 mars 2026, il continuerait à bénéficier des correctifs de sécurité en amont jusqu’au 17 mars 2028, soit environ trois mois après le début de cette période. S’il était développé avec Django 5.2, une version à support à long terme, il continuerait à en bénéficier jusqu’en avril 2028, soit environ quatre mois après le début de cette période. De nouvelles versions des frameworks verront le jour avant décembre 2027 : Laravel publie une version majeure environ chaque année, et la version 6.2 de Django est prévue pour avril 2027, avec un support étendu jusqu’en avril 2030, soit un peu plus de deux ans après le début de cette même période. Quelle que soit la version sur laquelle vous lancez votre projet, les correctifs en amont prendront fin des années avant la fin de votre période de support, et les correctifs pour les années restantes devront venir de vous.

Vous pouvez passer à une version plus récente, et de nombreuses équipes le feront, mais cela implique un travail d'ingénierie qui devra être réalisé avant ou pendant votre période de support. Ces trois frameworks ne constituent pas l'intégralité de votre pile technologique, et certaines de vos dépendances auront une durée de vie supérieure à cinq ans. Il vous appartient donc de comparer les dates de publication de chacune d'entre elles avec les vôtres.

Qui est redevable de quoi concernant le code open source que vous distribuez ?

La CRA fait deux remarques concernant les composants que vous n’avez pas développés vous-même. Le terme « composant » désigne les dépendances que vous intégrez. L’article 13 impose aux fabricants de faire preuve de diligence raisonnable lors de l’intégration de composants tiers, y compris ceux open source, afin que ces composants ne compromettent pas la sécurité du produit. Et lorsqu’un fabricant détecte une vulnérabilité dans un composant, il doit la signaler aux responsables de la maintenance de ce composant et y remédier dans son propre produit. Si le fabricant développe un correctif, il doit partager le code ou la documentation avec ces responsables, dans un format lisible par machine le cas échéant.

Les responsables sont traités différemment selon leur nature. Un « responsable de logiciel libre » est une personne morale, autre qu’un fabricant, qui assure le soutien systématique de produits libres spécifiques destinés à des activités commerciales et veille à leur pérennité. Les fondations et les entreprises qui publient des logiciels libres dans un contexte commercial peuvent entrer dans cette catégorie. L'article 24 demande aux gestionnaires de mettre en place et de documenter une politique de cybersécurité favorisant un développement sécurisé et une gestion efficace des vulnérabilités, ainsi que de coopérer avec les autorités de surveillance du marché. Il ajoute des obligations de déclaration limitées. Les projets open source qui ne sont pas monétisés échappent généralement aux obligations des fabricants, et les contributeurs individuels à des projets qu'ils ne gèrent pas ne sont pas concernés.

Extrait du règlement : lorsqu'un fabricant détermine la durée de sa période de support, l'article 13 lui permet de prendre en compte les périodes de support des composants tiers qui assurent des fonctions essentielles. Cela peut justifier une période plus longue. Cette durée ne peut toutefois pas être inférieure au minimum de cinq ans ; ainsi, un cadre qui ne prend plus en charge les correctifs en amont au bout de deux ans ne vous permet pas de déclarer une période de deux ans. Le minimum de cinq ans reste applicable.

En résumé, les fournisseurs en amont ne vous doivent généralement aucune période de support, et l'Agence canadienne du revenu (ARC) vous tient, en tant que fabricant, pour responsable de la gestion des vulnérabilités du produit fini.

Que faire lorsqu'une dépendance arrive en fin de vie ?

Une fois que le processus en amont s'arrête, quelqu'un doit élaborer les correctifs, et la CRA ne précise pas qui doit s'en charger. Il reste donc quatre options possibles, chacune correspondant à un projet de loi différent.

Passer à une version plus récente : cette approche fonctionne lorsque vous contrôlez le moment où les clients reçoivent les nouvelles versions, mais elle nécessite un investissement en temps de développement à chaque cycle. Dans une pile logicielle comprenant plusieurs frameworks suivant des calendriers différents, ces migrations finissent par représenter une charge importante.

Remplacez la dépendance : une alternative maintenue permet de résoudre le problème, s'il y en a un, à condition que vous puissiez vous permettre de réécrire le code.

Réparez-le vous-même : votre équipe applique les correctifs de sécurité à la version que vous distribuez. Cela nécessite des personnes qui connaissent bien le code, et l'article 13 vous oblige à signaler la vulnérabilité aux responsables de la maintenance et à leur communiquer votre correctif.

Achetez les correctifs : certains projets proposent une assistance prolongée pour les anciennes versions. L’annonce de Spring, par exemple, précise que l’assistance commerciale pour Spring Framework 6.2 s’étend jusqu’à mi-2032. Les données de support de Spring indiquent que le support entreprise pour Spring Boot 3.5, la version mentionnée dans le tableau ci-dessus, s'étend jusqu'au 30 juin 2032. Des fournisseurs indépendants proposent également des correctifs pour les versions en fin de vie. La couverture dépend des versions spécifiques que vous utilisez ; veillez donc à fournir au fournisseur la liste de vos versions réelles et à vérifier que chacune d'entre elles est bien couverte avant de vous engager.

Deux autres mesures semblent intéressantes. Il n'est pas possible de déclarer une période de support plus courte, sauf si vous prévoyez que le produit sera utilisé pendant moins de cinq ans. Le fait de consigner une vulnérabilité connue dans un registre des risques permet de justifier cette décision, mais l'ACRA exige des fabricants qu'ils traitent et corrigent les vulnérabilités sans délai, et une entrée dans le registre ne constitue pas une correction.

Éléments à prendre en compte avant de fixer une période de pension alimentaire

Vous devez indiquer la date de fin au moment de l'achat ; il est donc plus simple de régler les questions de dépendance avant la publication plutôt qu'après.

• Commencez par dresser un inventaire : une liste à jour du contenu de votre produit, généralement appelée « nomenclature logicielle » (SBOM), vous indique les dépendances à vérifier, y compris celles introduites par vos dépendances directes.
• Alignez les dates : inscrivez la date de fin de vie publiée pour chaque dépendance à côté de la période de prise en charge par la CRA que vous envisagez. Un tableur fera l'affaire.
• Vérifiez chaque version : la prise en charge s'applique par version, comme l'indiquent les dates mentionnées pour Django, Laravel et Spring Boot. Recherchez la date de fin de vie de la version exacte que vous commercialisez. Les recommandations de la Commission prévoient également qu'une période de prise en charge soit déclarée pour chaque version ayant subi des modifications substantielles que vous mettez sur le marché.
• Déterminez une solution pour chaque lacune : pour chaque dépendance qui n'est pas satisfaite, choisissez l'une des quatre pistes et désignez la personne en charge de la mettre en œuvre.
• Signaler ce qui a déjà dépassé sa date de fin de vie : si une dépendance d’un produit commercialisé a dépassé sa date de fin de vie à ce jour, la faille existe dès à présent. Si le produit est concerné, toute vulnérabilité activement exploitée dans cette dépendance doit être signalée dans les 24 heures à compter du 11 septembre 2026. La notification qui doit suivre dans les 72 heures doit préciser les mesures que vous avez prises à ce sujet, en l’absence de correctif en amont à indiquer.
• Notez pourquoi : la documentation technique doit inclure les informations sur lesquelles vous vous êtes basé pour définir cette période ; veillez donc à consigner votre raisonnement.

Combler l'écart avant décembre 2027

Lorsque vous commercialisez un produit et que vous le proposez pendant des années, vous définissez une période de support, alors que les frameworks sous-jacents suivent leurs propres calendriers. En alignant ces deux calendriers avant de vous engager, vous saurez combien d’années vous passerez à rechercher des correctifs de sécurité pour un code dont les responsables de maintenance ont cessé de publier des correctifs.

Si l’un des frameworks sur lesquels repose votre produit ne bénéficie plus des correctifs de sécurité en amont avant la fin de votre période de support, quelqu’un doit tout de même fournir ce correctif. C’est là qu’intervient le service « Endless Lifecycle Support » (ELS) de TuxCare. Les ingénieurs de TuxCare adaptent les correctifs de sécurité aux versions exactes que vous utilisez déjà, aussi longtemps que vous en avez besoin. Vos développeurs conservent les versions dont ils disposent et les workflows qu’ils utilisent. L’ELS s’associe également à SecureChain, qui vérifie les paquets open source avant leur installation et les corrige tant que le développeur en amont est encore actif.

Achetés ensemble, SecureChain et ELS assurent automatiquement la continuité de la couverture. Lorsqu'un éditeur cesse de publier des correctifs de sécurité pour une version que vous utilisez, la couverture de cette version passe de SecureChain à ELS. Vous n'avez pas besoin de suivre la date de fin de vie de chaque composant pour savoir quand les correctifs en amont cessent d'être disponibles. Ces produits couvrent désormais les écosystèmes JavaScript, Python, Java, Go et PHP.

FAQ

Quelle est la durée minimale de la période de soutien au titre du CRA de l'UE ?

La loi européenne sur la cyber-résilience (CRA) fixe une durée minimale de prise en charge de cinq ans. Un fabricant ne peut réduire cette durée que si la durée d'utilisation prévue du produit est inférieure ; dans ce cas, la durée de prise en charge correspond à cette durée d'utilisation. Un produit dont on peut raisonnablement supposer qu'il sera utilisé plus longtemps nécessite une durée de prise en charge plus longue.

Les responsables de projets open source sont-ils tenus de continuer à assurer le support des anciennes versions ?

En général, non. La loi sur la cyber-résilience (CRA) traite deux groupes de manière différente, et aucun des deux n’est soumis à une obligation de période de support. Les « stewards » de logiciels libres, c’est-à-dire les personnes morales qui assurent systématiquement le support de produits open source à usage commercial, doivent documenter une politique de cybersécurité, incluant la gestion des vulnérabilités, et coopérer avec les autorités. Les projets open source qui ne sont pas monétisés ne relèvent pas des obligations des fabricants, et les contributeurs individuels à des projets qu’ils ne gèrent pas ne sont pas concernés du tout. Dans tous les cas, le fabricant qui distribue le code doit continuer à le mettre à jour pendant la période de support qu’il a déclarée.

Que se passe-t-il lorsqu'une dépendance ne bénéficie plus de correctifs de sécurité pendant la période de support ?

La responsabilité incombe au fabricant. En vertu de la loi sur la cyber-résilience (CRA), les vulnérabilités du produit, y compris celles de ses composants, doivent être traitées pendant toute la durée de support déclarée. Les solutions possibles consistent notamment à passer à une version prise en charge, à remplacer la dépendance, à développer un correctif ou à acheter des correctifs pour l'ancienne version.

Que doivent indiquer les fabricants aux utilisateurs concernant la durée de la garantie ?

En vertu de la loi sur la cyber-résilience (CRA), la date de fin de la période de support, précisée au moins par le mois et l'année, doit être clairement indiquée au moment de l'achat. Les fabricants doivent également consigner la manière dont ils ont fixé cette période dans leur documentation technique et, lorsque cela est techniquement possible, informer les utilisateurs de la fin du support.

La loi sur la cyber-résilience s'applique-t-elle aux produits déjà commercialisés avant décembre 2027 ?

Uniquement s’ils font l’objet d’une modification substantielle. En vertu de la loi sur la cyber-résilience (CRA), les produits déjà commercialisés avant le 11 décembre 2027 ne seront soumis à ses exigences qu’à compter de cette date, s’ils font l’objet d’une modification substantielle. Les obligations de déclaration prévues à l’article 14, y compris celles relatives aux vulnérabilités activement exploitées, s’appliquent de toute façon à ces produits.

Les lignes directrices de la Commission relatives à la loi sur la cyber-résilience ont-elles force obligatoire ?

Non. La Commission européenne a publié le 27 juillet 2026 ses lignes directrices relatives à la loi sur la cyber-résilience (CRA) afin d’expliquer comment appliquer les règles, mais celles-ci ne sont pas contraignantes. C’est le règlement lui-même ainsi que les actes délégués ou d’exécution adoptés qui ont force de loi, et seule la Cour de justice de l’Union européenne peut en donner une interprétation faisant autorité. Ces lignes directrices indiquent toutefois comment la Commission souhaite que les règles soient appliquées ; il convient donc de s’y référer pour élaborer ses stratégies jusqu’à ce qu’un tribunal en décide autrement.

Résumé

Nom de l'article

Les exigences relatives à la période de prise en charge de l'ARC ont une durée supérieure à celle de vos personnes à charge

Description

La CRA exige au moins 5 ans de correctifs de sécurité. De nombreux frameworks open source assurent le support d'une version pendant 1 à 3 ans. C'est à vous de fournir les correctifs par la suite.

Auteur

Artem Karasev

Nom de l'éditeur

de TuxCare

Logo de l'éditeur