Pourquoi votre pile open source en fin de vie constitue un risque en matière de conformité, et non une dette technique

Bienvenue et informations pratiques

Erin Hannaford : Bonjour et bienvenue à notre webinaire intitulé « Pourquoi votre pile open source en fin de vie constitue un risque en matière de conformité, et pas seulement une dette technique ». Je m'appelle Erin Hannaford et je vais animer le webinaire d'aujourd'hui.

‍

Avant d'entrer dans le vif du sujet, j'aimerais aborder quelques points d'ordre pratique. Le webinaire d'aujourd'hui est enregistré, et une fois la session terminée, nous vous enverrons par e-mail à la fois l'enregistrement et le livre blanc qui l'accompagne. Gardez donc un œil sur votre boîte de réception.

‍

Nous avons prévu suffisamment de temps pour répondre à vos questions à la fin. N'hésitez pas à utiliser la fonctionnalité de commentaires pour poser vos questions ou faire part de vos remarques tout au long du webinaire ; nous répondrons en direct à autant de questions que possible. Pour celles que nous ne pourrons pas traiter en direct, nous vous contacterons directement après le webinaire.

‍

J'aimerais maintenant vous présenter l'intervenant d'aujourd'hui, Rob Nalen, directeur des opérations chez HeroDevs. Rob, à vous la parole.

‍

Rob Nalen : Merci, Erin. Je suis ravi de vous voir tous ici — j'ai vraiment hâte d'aborder ce sujet.

‍

Pour vous donner un peu de contexte, comme vous le savez tous, je suis directeur des opérations chez HeroDevs. Notre objectif est de permettre aux entreprises de respecter leurs exigences de conformité internes et externes, notamment le règlement européen CRA, dont nous allons parler ici. Pour ce faire, nous proposons une correction continue des vulnérabilités CVE ainsi qu’un support pour les logiciels open source en fin de vie. Dans le cadre de cette offre destinée aux entreprises, nous avons noué des partenariats stratégiques avec des communautés open source telles que l’OpenJS Foundation, la Linux Foundation et la Commonest Foundation, tout en collaborant directement avec de nombreux projets open source comme Bootstrap, Vue, .NET et bien d’autres encore.

‍

Mon objectif pour ce webinaire est non seulement de vous expliquer en détail ce qu’est le CRA de l’UE et comment les entreprises peuvent s’assurer de leur conformité, mais aussi de vous donner un aperçu des raisons qui ont conduit à la mise en place de cette exigence, ainsi que d’autres exigences qui seront mises en œuvre à l’échelle mondiale en raison des progrès de l’IA et de l’open source. Nous aborderons la manière dont les organisations doivent envisager la conformité en ce qui concerne les logiciels open source en fin de vie. Enfin, nous passerons à une séance de questions-réponses, au cours de laquelle j’ai hâte d’aborder vos questions et les sujets qui vous intéressent — c’est toujours un plaisir d’avoir une discussion interactive.

‍

L'histoire se répète : les enseignements tirés des données personnelles

Dans cette optique, voyons rapidement comment l'histoire se répète et comment nous pouvons en tirer des leçons pour l'avenir.

‍

Avant d’aborder la loi sur la cyber-résilience, j’aimerais prendre un peu de recul, car tout cela n’est pas entièrement nouveau. Ce que nous vivons actuellement avec les logiciels et l’intelligence artificielle suit un schéma similaire à celui que nous avons observé avec la collecte et l’utilisation des données à caractère personnel.

‍

Commençons donc par le schéma général. Il y a environ quinze ans, les entreprises ont compris qu’elles pouvaient exploiter les données personnelles à une échelle que personne n’avait imaginée. Cette valeur ajoutée pour les entreprises s’accompagnait d’un risque, et ce risque pesait principalement sur les personnes qui n’avaient jamais vraiment consenti à ce que leurs données soient exploitées ou utilisées. Au cours des premières années, le modèle de protection des données personnelles reposait sur le principe du « mieux possible », sans véritable obligation de rendre des comptes et, a fortiori, sans législation ni normes de conformité définitives pour encadrer les comportements.

‍

En résumé, les défaillances se sont multipliées et les données personnelles des utilisateurs ont été compromises à grande échelle, ce qui a conduit à un durcissement de la législation. En Europe, il s’agissait du RGPD. Aux États-Unis, il s’agissait de la loi Gramm-Leach-Bliley, de la loi HIPAA, puis, plus tard, de la loi CCPA.

‍

Pour ceux d’entre vous qui travaillent dans le domaine de la conformité, vous vous souvenez sans doute que la mise en place de ces normes n’a pas été sans heurts. Certains se souviennent peut-être de l’arrêt « Schrems I », sans pour autant en garder un très bon souvenir. En 2015, la Cour de justice de l’Union européenne a invalidé du jour au lendemain le cadre « Safe Harbor » entre les États-Unis et l’UE, estimant qu’il ne protégeait pas suffisamment les données des Européens. Des milliers d’entreprises qui pensaient être en conformité se sont soudainement retrouvées en situation d’infraction. C’est cette affaire, ainsi que quelques autres cas et évolutions similaires, qui a été à l’origine du RGPD. La protection « au mieux » est devenue une obligation impérative, permanente et exécutoire — assortie de sanctions réelles en cas de manquement.

‍

Nous assistons aujourd’hui à un échange de données personnelles contre l’IA et l’open source, et le scénario se répète. Les entreprises utilisent l’open source à très grande échelle, et l’IA multiplie la vitesse à laquelle nous le déployons. Le risque se propage à travers le code et touche tous ceux qui en dépendent. Ces facteurs ont un impact notable sur la sécurité des infrastructures et des applications, ce qui a donné lieu à de nombreux incidents de sécurité — dont certains seront abordés un peu plus tard.

‍

L'élément essentiel réside dans le fait que la réponse a été identique dans sa forme : une législation et des normes de conformité sont mises en place pour garantir que la sécurité ne soit plus une simple question de « faire de son mieux », mais qu'elle doive au contraire être démontrée et pleinement étayée. Cette législation prend la forme, par exemple, du CRA de l'UE, de la directive NIS2 et de la loi DORA ; aux États-Unis également, il existe une multitude d'exigences.

L'ampleur des risques liés à l'open source et à l'intelligence artificielle

Pour mieux cerner l'adoption des logiciels libres et les changements induits par l'IA, Black Duck, Sonatype et d'autres acteurs du secteur fournissent des données utiles.

‍

En ce qui concerne l'open source, je ne pense pas qu'il y ait la moindre ambiguïté quant à l'ampleur de son adoption : les entreprises, et plus fondamentalement le monde et Internet, dépendent entièrement de l'open source. Pour replacer les choses dans leur contexte :

‍

• On recense chaque année environ 10 000 milliards de téléchargements de logiciels libres.
• Rien que sur GitHub, on compte plus de 150 millions de développeurs.
• 70 % de l'ensemble du code est désormais open source.
• Les applications d'entreprise comptent en moyenne plus de 900 dépendances open source par application.

‍

Cela peut paraître surprenant pour ceux qui ne sont pas familiers avec les organisations de développeurs, mais il ne s’agit pas seulement d’une utilisation massive : les composants essentiels sur lesquels s’appuient les entreprises sont également créés et diffusés par des communautés open source. Avec une telle omniprésence de l’open source, il peut s’avérer pratiquement impossible de rester à jour, d’autant plus que les exigences liées au cycle de vie des produits peuvent obliger les entreprises à maintenir certaines versions à la disposition de leurs propres clients. Nous y reviendrons un peu plus tard.

‍

En ce qui concerne l'IA : tout le monde est au courant des mises à jour qui semblent paraître chaque jour, voire chaque semaine. Personnellement, j'entends presque tous les jours parler de choses que je ne pensais pas que l'IA puisse ou veuille faire. De nombreuses questions restent en suspens quant à ce que l'IA peut et va faire à l'avenir — mais nous savons en quoi elle excelle dès à présent, et pour l'instant, l'IA est extrêmement douée pour détecter les vulnérabilités. Cela entraîne un afflux massif de CVE.

‍

HeroDevs a constaté des exemples très parlants à cet égard. Prenons l’exemple du framework Spring : en 2025, 17 vulnérabilités (CVE) avaient été signalées pour le framework Spring . Pour 2026, à la date de ce webinaire, on en compte déjà plus de 200.

‍

Cela n'affecte pas seulement les entreprises, mais aussi les communautés et les projets chargés d'examiner ces problèmes de sécurité signalés. Ceux-ci doivent désormais traiter des milliers de demandes par semaine, qu'il leur faut examiner afin de détecter et de corriger les vulnérabilités avant qu'elles ne soient exploitées. Des projets tels que l'initiative « Glasswing » d'Anthropic ont permis d'accélérer considérablement l'identification des CVE, et le nombre de paquets open source contenant du code malveillant ne cesse lui aussi d'augmenter.

‍

Ces deux facteurs — l'ampleur de l'utilisation des logiciels libres et l'accélération de la découverte des vulnérabilités — ont un impact particulièrement important sur les entreprises, car celles-ci ont recours à une quantité bien plus importante de logiciels libres et ont énormément de mal à suivre le rythme de leur cycle de vie. Et dès lors qu'elles prennent du retard, les entreprises ne peuvent plus compter sur les correctifs en amont ni sur les correctifs CVE, puisque la communauté ne les fournit plus.

Chronologie des violations ayant conduit à la mise en place de la réglementation

Je vais aborder brièvement l'histoire de la réglementation relative aux données à caractère personnel, mais je ne m'étendrai pas trop sur le sujet, car beaucoup d'entre vous en gardent peut-être des séquelles. Les normes de conformité actuelles, si l'on examine leur chronologie, sont le fruit de plusieurs événements majeurs. Pour moi, comprendre l'histoire de ces exigences est utile pour deux raisons : premièrement, je trouve plus facile d'aborder les choses lorsque je comprends d'où vient le problème ; deuxièmement, cela nous aide à anticiper les attentes futures.

‍

Si l'on examine les révélations de l'informateur Snowden et la violation de données subie par TalkTalk, on constate que l'adoption et la mise en œuvre du RGPD ont suivi de près plusieurs violations et divulgations de données à caractère personnel de très grande ampleur.

‍

Si l’on examine la CRA de l’UE, on observe une tendance similaire. Prenons l’exemple de la fuite de données chez Equifax en 2017, au cours de laquelle les données personnelles de millions de personnes ont été divulguées et où Equifax s’est vu infliger une amende de plus de 500 millions de dollars par la FTC. Citons également l’incident Log4Shell, dont nous parlerons un peu plus tard. On retrouve ici un schéma similaire : des failles de sécurité critiques suivies d’un renforcement des normes.

‍

Il est important de noter ici que, qu’il s’agisse de la question des données à caractère personnel ou de celle, plus récente, de la sécurité des infrastructures, ces deux aspects sont directement concernés par l’utilisation de logiciels open source en fin de vie, que ce soit au titre de l’article 32 du RGPD ou de l’article 13, paragraphe 8, de la CRA de l’UE.

‍

Et cela ne concerne pas uniquement l'Europe : c'est un phénomène mondial. Le Canada dispose du projet de loi C-26. Les États-Unis ont publié récemment une multitude de décrets présidentiels, ainsi que les exigences FedRAMP, CMMC 2.0 et PCI, sans oublier un projet de révision et de refonte des mesures de sécurité de la loi HIPAA. Partout dans le monde, on observe l'émergence d'exigences similaires, y compris dans la région Asie-Pacifique, où l'Australie dispose de la loi sur la cybersécurité ainsi que de la norme CPS-A.

‍

Ces exigences auront des répercussions tant sur les organisations que sur les entreprises qui fournissent des logiciels et des services aux sociétés concernées. D’un point de vue général, ces normes de conformité requièrent les mêmes éléments fondamentaux :

‍

1. Sachez ce que vous exécutez et ce que vous utilisez.
2. Disposer d'un processus et des moyens nécessaires pour corriger les vulnérabilités.
3. Disposer d'une procédure et des moyens nécessaires pour signaler les incidents graves susceptibles d'avoir une incidence sur les données à caractère personnel ou les informations générales.
4. Disposer d'une documentation prête pour un audit, à présenter à tout organe de tutelle.

‍

Présentation de la loi européenne sur la cyber-résilience (CRA)

Maintenant que nous avons passé en revue l'historique, penchons-nous plus précisément sur la CRA de l'UE : certaines de ses dispositions sont déjà en vigueur et elle aura des répercussions considérables.

‍

Commençons par définir ce qu’est la CRA de l’UE : il s’agit de la première loi horizontale en matière de cybersécurité. « Horizontale » signifie qu’il s’agit de la première législation qui s’applique à toutes les catégories de produits, et non pas à un seul secteur. À titre de comparaison, beaucoup d’entre vous connaissent sans doute la loi sur la résilience opérationnelle numérique (DORA), entrée en vigueur en janvier 2025 — mais celle-ci s’applique spécifiquement aux entités financières et aux organisations leur fournissant certains services, ce qui en fait une réglementation sectorielle ou verticale.

‍

Le règlement européen sur la gestion du cycle de vie (CRA) a été proposé par la Commission européenne et adopté par le Parlement européen et le Conseil de l'UE. Son nom officiel est « Règlement (UE) CRA » — non pas que quiconque l'utilisera, mais c'est bon à savoir. Son objectif principal est d'instaurer une obligation relative au cycle de vie pour tout produit comportant des éléments numériques.

Les quatre piliers de l'évaluation de la crédibilité de l'UE (CRA)

Les obligations relatives au cycle de vie s'articulent autour de quatre éléments principaux :

‍

1. La sécurité dès la conception. Les entreprises qui fournissent ou utilisent des logiciels comportant des éléments numériques doivent intégrer directement des fonctionnalités de cybersécurité dans ces logiciels, et non les ajouter a posteriori comme un simple complément. Ces fonctionnalités doivent être maintenues tout au long de la période de support.
2. Gestion des vulnérabilités. Il s'agit d'une obligation permanente consistant à identifier, documenter, corriger et signaler les failles de sécurité lorsque cela s'avère nécessaire. Cela inclut la distribution rapide et sécurisée de correctifs, ainsi qu'une politique de divulgation coordonnée des vulnérabilités (CVD) permettant aux chercheurs en sécurité et aux clients de signaler des problèmes.
3. Signalement des incidents. En cas de découverte d'une vulnérabilité, il doit exister une documentation et des procédures claires pour les notifications, respectant les délais fixés.
4. Exigence relative à la SBOM. Une « Software Bill of Materials » (liste des composants logiciels) — un inventaire lisible par machine de l'ensemble des composants logiciels, bibliothèques et dépendances présents dans le produit numérique.

‍

Ce sont là les quatre éléments indispensables au sein de l’Agence européenne de notation (CRA).

Qu'est-ce qui est considéré comme un « élément numérique » ?

La CRA de l'UE s'applique aux produits comportant, je cite, des « éléments numériques » — une définition aussi large qu'elle en a l'air. Les éléments numériques peuvent inclure les systèmes d'exploitation, les applications de bureau et mobiles, les micrologiciels et les bibliothèques. Cela inclut les logiciels libres embarqués. En somme, tout ce qui permet à un appareil de se connecter à un réseau ou de communiquer avec celui-ci.

‍

Il existe quelques exceptions régies par d'autres exigences réglementaires : par exemple, le SaaS pur relève de la directive NIS2, tandis que certains secteurs, tels que l'automobile, l'aéronautique et le secteur médical, sont soumis à leurs propres normes. La définition de l'« élément numérique » reste toutefois volontairement très large.

‍

Une exception mérite d’être précisée : celle relative aux logiciels open source non commerciaux. On entend par « logiciel open source non commercial » un logiciel développé et fourni gratuitement, sans modèle commercial ni voie de monétisation — c’est-à-dire sans intention de tirer profit de sa distribution. Concrètement, cette exemption s’applique aux projets et communautés en amont. Soyons clairs : tout fabricant qui intègre des logiciels open source — y compris des logiciels open source non commerciaux — dans ses produits est soumis à la CRA de l’UE.

‍

Et tout comme le RGPD, la CRA de l'UE a une portée extraterritoriale. Si vous n'êtes pas établi dans l'UE mais que vous vendez des produits sur le marché européen, vous êtes concerné par cette réglementation, quel que soit le lieu de votre siège social ou celui où vous exercez vos activités.

L'histoire derrière Log4Shell

Il convient de noter que la proposition de la Commission européenne relative à la CRA de l’UE faisait spécifiquement référence à la vulnérabilité Log4Shell. Une petite bibliothèque Java, connue sous le nom d’Apache Log4j, était intégrée à des millions d’applications. Du jour au lendemain, une faille de sécurité a mis une grande partie d’Internet en danger : cette vulnérabilité (CVE) permettait aux attaquants d’exécuter du code malveillant sur un ordinateur ou un serveur cible depuis n’importe quel endroit sur Internet. Quiconque l’exploitait pouvait prendre le contrôle total du système, voler des données, installer un rançongiciel ou lancer des attaques réseau à grande échelle.

‍

Cela a mis en lumière une dure réalité à laquelle la Commission européenne cherchait à remédier : personne n'était responsable de la sécurité de Log4j dans l'ensemble de ces déploiements. L'autorité de régulation de l'UE attribue cette responsabilité à celui qui met le produit sur le marché.

‍

Principales échéances et articles relatifs à la directive européenne sur les agences de notation de crédit (CRA)

Passons rapidement en revue la chronologie des événements et examinons plus en détail certains éléments clés de la CRA de l'UE.

‍

• L'agence européenne de notation (CRA) a été proposée par la Commission européenne en 2022.
• Elle est entrée en vigueur en décembre 2024, date à partir de laquelle elle a commencé à susciter davantage d'intérêt.
• 11 septembre 2026 — les obligations de signalement des vulnérabilités s'appliquent désormais. (Il s'agit de la semaine dernière, à la date de ce webinaire.)
• 11 décembre 2027 — entrée en vigueur de l'ensemble des exigences.

‍

Ainsi, à compter d’aujourd’hui, le délai de signalement est bel et bien lancé. Si une vulnérabilité de votre produit fait l’objet d’une exploitation active, vous devez la signaler — par l’intermédiaire de l’Agence de l’Union européenne chargée de la cybersécurité (ENISA), via la plateforme unique de signalement (SRP). Cette information est ensuite prise en charge et examinée par l’équipe nationale d’intervention en cas d’incident de sécurité informatique (CSIRT). Il faut adorer les acronymes si l’on veut se lancer dans le cadre du CRA de l’UE — c’est une condition indispensable.

‍

L'horloge est impitoyable :

‍

• 24 heures — obligation d'alerte précoce
• 72 heures — notification complète
• 14 jours — rapport final, une fois qu’un correctif aura été mis à disposition

‍

Point important : si vous avez expédié un produit avant septembre et qu'il se trouve déjà sur le marché, vous êtes toujours soumis à ces obligations. La définition large de l'applicabilité donnée par l'Autorité européenne de protection des données (CRA) ne se limite pas à un seul secteur ni aux organisations opérant principalement dans l'UE : si vous exercez des activités commerciales dans l'UE, cela aura très probablement des répercussions sur vous.

Les trois exigences les plus importantes à l'heure actuelle

Article 13, paragraphe 8 — la période de support. Les fabricants proposant un produit comportant des éléments numériques doivent s'engager à assurer une période de support d'au moins cinq ans. Au cours de ces cinq années, ils doivent corriger les vulnérabilités de chaque composant, y compris les composants open source intégrés. Les mises à jour doivent également rester disponibles pendant dix ans — cela empêche les fabricants d’utiliser les conditions de licence pour retirer les correctifs a posteriori. Les régulateurs souhaitent donner aux utilisateurs dépendants de ces logiciels le temps de migrer ; les fabricants ne peuvent donc pas publier un correctif pour le retirer immédiatement par la suite.

‍

Article 14 — Déclaration des vulnérabilités. Cet article porte sur les délais de déclaration de 24 heures, 72 heures et 14 jours décrits ci-dessus. Principales mesures que les entreprises doivent prendre dès aujourd’hui :

‍

• Si vous proposez un produit comportant des éléments numériques, désignez un représentant attitré, c’est-à-dire la personne qui se connectera au SRP de l’ENISA en cas de découverte d’une vulnérabilité.
• Demandez à ce représentant de créer au préalable un identifiant UE (un compte auprès de la Commission européenne) — mais notez que la Commission européenne déconseille expressément de s'inscrire au préalable directement sur la plateforme SRP elle-même.
• Mettre en place un processus interne clair précisant qui est responsable de quoi lors d'un rapport SRP.

‍

Annexe I — Exigences relatives à la liste des composants logiciels (SBOM), à compter de décembre. Quatre éléments principaux :

‍

1. Générer des SBOM lisibles par machine pour chaque version distincte d'un produit logiciel, et les inclure dans la documentation technique afin que les autorités de régulation (autorités de surveillance) puissent les examiner.
2. Mettez régulièrement à jour la SBOM: elle ne doit pas se limiter à un instantané obsolète datant d'il y a douze mois ; elle doit refléter les composants, correctifs et mises à jour actuels.
3. Intégrer la gestion des vulnérabilités: la SBOM doit s'interfacer avec des outils de détection et de suivi continus des vulnérabilités afin de faciliter la mise en conformité et la génération rapide de rapports.

Sanctions

L'objectif est que chaque organisation respecte ces exigences et reste en conformité — mais le règlement européen sur la protection des données (CRA) est doté de véritables sanctions. Les amendes peuvent atteindre plusieurs dizaines de millions d'euros ou un pourcentage du chiffre d'affaires annuel mondial, le montant le plus élevé étant retenu. En cas d'infractions graves, les produits peuvent être entièrement retirés du marché européen, ce qui pourrait avoir de graves conséquences.

Que faire maintenant ?

• Assurez-vous de bien comprendre si vous relevez du champ d'application du règlement européen sur les droits d'auteur (CRA) — lisez attentivement les définitions. Si vous fournissez des contenus numériques au sein de l'Union européenne, ce règlement vous concerne.
• Identifiez le représentant qui vous a été attribué.
• Commencez à évaluer les fournisseurs susceptibles de vous aider à générer des SBOM lisibles par machine.
• Mettez en place une plateforme DevSecOps afin de pouvoir surveiller les risques en temps réel.
• Avec le référent qui vous a été attribué, entraînez-vous à suivre la procédure de signalement dans les délais de 24 heures, 72 heures et 14 jours.
• Conservez les preuves : une piste d'audit, les registres DevSecOps et les SBOM seront indispensables.

‍

Décembre 2027 peut sembler lointain, mais cette date arrivera bien plus vite qu'on ne le pense — et ce sont les organisations qui s'appuient sur des logiciels libres en fin de vie qui en subiront le plus les conséquences.

‍

Ce que signifie réellement l'expression « open source en fin de vie »

Nous avons déjà abordé l'histoire et la raison d'être de la CRA, ainsi que ses exigences. Concentrons-nous à présent sur les domaines où le risque est le plus marqué pour les organisations aujourd'hui.

‍

L'expression « logiciel open source en fin de vie » peut recouvrir plusieurs réalités :

‍

• Totalement abandonné par la communauté. Exemple : AngularJS. Google ne souhaitait plus en assurer la maintenance, les utilisateurs ont donc dû migrer vers React ou vers une version plus récente de Angular. Si vous utilisez encore AngularJS, sachez que la communauté ne le contrôle plus pour détecter les failles de sécurité et ne fournit plus de correctifs CVE.
• Une version qui ne bénéficie plus du soutien de la communauté, même si le projet lui-même est toujours actif. Exemple : le framework Spring , utilisé pour développer des applications Java destinées aux entreprises. La communauté suit un calendrier de publication selon lequel les anciennes versions ne bénéficient plus de correctifs CVE. Ainsi, si vous utilisez Spring Boot 2.5, cette version est en fin de vie et la communauté ne fournira plus de correctifs, alors même que les failles de sécurité se multiplient de manière exponentielle en raison de l'IA.

‍

On serait tenté de penser que les entreprises n'utilisent pas de logiciels dont le support a pris fin et qui présentent des vulnérabilités CVE classées « critiques » ou « élevées », mais la réalité est tout autre :

‍

• Entre 5 % et 15 % des composants des entreprises ont déjà atteint leur fin de vie.
• Plus de 81 000 paquets présentent des vulnérabilités CVE connues pour lesquelles aucun correctif n'est disponible, car la communauté est passée à autre chose.
• Ce risque ne se limite pas aux principales dépendances ou aux frameworks les plus connus : 93 % de ces CVE se trouvent en réalité dans des dépendances transitives que de nombreuses organisations n'ont jamais choisies explicitement. Elles font simplement partie intégrante de la solution déployée.

‍

Le problème ne faiblit pas. Rien qu'entre avril et juillet, plusieurs outils ont atteint leur fin de vie : MySQL, Node.js, Django, Angular et Spring Boot — le tout en l'espace de 90 jours. Les entreprises utilisant ces outils se sont lancées dans une course effrénée pour se moderniser et rester sur des versions prises en charge, souvent au détriment d'autres projets et d'activités créatrices de valeur.

Exemples concrets de risques liés à la conformité

Il ne s'agit pas d'un problème hypothétique. Deux exemples récents sont directement liés à la CRA de l'UE :

‍

• Spring Security présente une vulnérabilité CVE critique qui empêche, de manière silencieuse, l'application des en-têtes de sécurité HTTP. L'application continue de fonctionner et de passer tous les contrôles d'état, mais la protection côté navigateur — qui est essentielle — disparaît complètement, sans qu'aucune erreur ni aucun avertissement ne soit consigné.
• Angular présentait une vulnérabilité CVE de gravité élevée : une faille de type « cross-site scripting » (XSS) qui permettait à des attaquants d'exécuter du code JavaScript malveillant sur la page Web d'un utilisateur, en dissimulant ce code malveillant dans des fichiers de texte traduits au sein de l'application Angular .

‍

Dans les deux cas, en vertu du règlement européen sur la protection des données (CRA) — voire de la loi DORA —, une organisation s’exposerait à deux types de non-conformité : d’une part, une infraction à l’article 13, paragraphe 8, pour avoir utilisé une version non prise en charge d’un logiciel dans un produit comportant des éléments numériques ; d’autre part, si l’organisation ne respectait pas les délais de déclaration prévus à l’article 14.

‍

L'utilisation de logiciels open source en fin de vie est très répandue, et cette utilisation peut entraîner un non-respect de la CRA de l'UE, du RGPD et d'autres normes.

‍

Deux voies pour l'avenir

Alors, que faire dans ce cas ? Il y a deux possibilités.

‍

Option 1 : Passer à une version prise en charge. Cela semble intuitif, mais comme peuvent en témoigner de nombreux techniciens ici présents, la migration peut s’avérer extrêmement difficile — en particulier lorsqu’il s’agit de gérer les dépendances au sein d’un écosystème. La migration d’ Spring, par exemple, peut également nécessiter d’abandonner Java 8, ce qui repousserait votre calendrier de migration au-delà de douze mois. Pendant ce temps, vous consacrez des ressources à la modernisation sans gagner beaucoup de nouvelles fonctionnalités — et, pire encore, vous restez entre-temps en situation de non-conformité. Cette voie exige des entreprises qu’elles réfléchissent très attentivement aux logiciels open source qu’elles déploient et qu’elles surveillent en permanence les dates de fin de vie, ce qui est difficile compte tenu du volume considérable d’adoption.

‍

Option 2 : Trouver un fournisseur capable d’assurer la prise en charge des logiciels en fin de vie. C’est là qu’intervient HeroDevs : nous proposons une solution de remplacement directe pour les logiciels open source en fin de vie. Dans le cadre de nos services d’abonnement, vous bénéficiez d’une correction des vulnérabilités CVE et d’une assistance tout au long de la période, ce qui permet aux entreprises de contrôler leur propre calendrier de modernisation tout en restant conformes à tout moment.

L'essor du marché de la dépollution — et comment évaluer un prestataire

Avec tout le débat autour de l’IA et la multiplication des vulnérabilités (CVE), on assiste à ce que j’appellerais affectueusement un « boom du marché de la correction ». Les outils SCA et autres solutions similaires sont désormais très performants pour identifier les vulnérabilités dans les logiciels open source en fin de vie. Mais la vraie question qui se pose désormais est la suivante : que faire une fois ces vulnérabilités identifiées ?

‍

Avec 48 000 CVE divulgués en 2025 — soit une hausse de plus de 250 % par rapport à l’année précédente —, on assiste à une vague de promesses de la part des éditeurs, qui affirment pouvoir corriger les failles des logiciels open source, y compris celles dont les versions ne bénéficient plus du soutien de la communauté. J'ai personnellement vu des entreprises affirmer que l'IA pouvait y parvenir à elle seule. Mais des études récentes, notamment celles menées par 1Password, ont révélé que seul un correctif sur quatre créé exclusivement par l'IA corrigeait réellement le bug ou la vulnérabilité CVE sous-jacente.

‍

De notre côté, HeroDevs a mené des recherches et a découvert un fournisseur de premier plan qui se vantait d'avoir corrigé des vulnérabilités CVE pour Spring. En examinant la documentation, nous avons constaté que sur les 258 vulnérabilités CVE Spring que ce fournisseur prétendait avoir corrigées, près de deux sur trois n'étaient en réalité pas accompagnées d'un correctif fonctionnel.

‍

Dans ces conditions, je recommande vivement à toute personne chargée d'évaluer un fournisseur d'exiger des preuves concrètes, plutôt que de se contenter de croire sur parole n'importe quel fournisseur (y compris le nôtre). Plus précisément :

‍

1. Demandez les notes de mise à jour qui établissent un lien entre des CVE spécifiques et des versions spécifiques.
2. Demandez des instructions VEX qui mettent en évidence les CVE corrigées.
3. Vérifiez le niveau d'expertise du fournisseur. L'IA à elle seule n'est pas une solution miracle : privilégiez les fournisseurs certifiés CNA et qui ont fait leurs preuves en matière de détection autonome de vulnérabilités (CVE), sans se contenter de s'appuyer sur les correctifs fournis en amont.
4. Effectuez un scan de validation. Vérifiez que le correctif n'entraîne pas de dysfonctionnement de votre application et, surtout, assurez-vous qu'il ne se contente pas d'effacer le résultat négatif par une simple mise à jour de version alors que la vulnérabilité CVE sous-jacente est toujours présente.

‍

Le fait de ne pas disposer d'un soutien adéquat ne constitue pas seulement un risque pour vous : cela compromet également votre capacité à respecter ces réglementations, ce qui, par conséquent, représente un risque pour vos clients.

‍

Conclusions finales

L'histoire se répète, et nous avons déjà observé cette tendance par le passé. La réglementation européenne CRA ne sera pas la dernière exigence de ce type : tirez parti des pratiques que vous mettez en place pour vous conformer à la réglementation européenne CRA afin de vous préparer à ce qui va suivre. L'adoption des logiciels libres connaît un essor fulgurant, et l'intelligence artificielle permet de détecter plus facilement et plus rapidement les vulnérabilités. C'est pourquoi il est essentiel de disposer d'un plan pour prendre en charge les logiciels libres en fin de vie et pour répondre aux exigences de la réglementation européenne CRA.

‍

Les obligations imposées par l'Agence européenne de notation (CRA) sont déjà entrées en vigueur — il ne s'agit pas d'une mesure qui « prendra effet en décembre ». Les exigences concrètes sont déjà applicables. Par conséquent :

‍

• Identifiez les représentants qui vous ont été attribués.
• Configurez votre identifiant UE.
• Assurez-vous de disposer d'une liste des composants logiciels (SBOM) accessible et de procéder à des analyses de vulnérabilités afin de pouvoir établir vos rapports dans les délais.
• Prenez conscience que la fin de vie des logiciels libres constitue un problème direct de conformité auquel il faut remédier : choisissez un fournisseur disposant de l'expertise et de l'expérience nécessaires pour vous aider.

‍

Questions-réponses

Erin Hannaford : Merci beaucoup, Rob. Nous avons reçu quelques questions, je vais donc commencer par la première.

‍

Question d'un participant : Vous avez brièvement évoqué les SBOM lisibles par machine. Pouvez-vous nous expliquer plus en détail ce qu'apporte une SBOM lisible par machine par rapport au manifeste de dépendances du dépôt ?

‍

Rob Nalen : Bonne question. Votre fichier package.json ou pom.xml vous indique ce que vos développeurs ont directement choisi d'ajouter. Mais — et c’est là qu’intervient l’obligation prévue à l’annexe I du règlement CRA de l’UE — il ne vous fournit pas la liste complète des dépendances, ni la piste d’audit que les auditeurs souhaitent consulter. Cette piste d’audit doit inclure les composants transitifs que, selon toute vraisemblance, personne au sein de votre équipe n’a sélectionnés explicitement — d’où ce chiffre de 93 % que j’ai mentionné plus tôt.

‍

C'est pourquoi une SBOM est essentielle. Un format tel que CycloneDX ou SPDX est conçu pour être analysé automatiquement et permet de comparer les différentes versions entre elles. Ainsi, lorsque la prochaine vulnérabilité apparaîtra — à l'instar de Log4Shell —, vous pourrez déterminer beaucoup plus rapidement si vous êtes concerné. Idéalement, vous disposerez d'une vue d'ensemble complète plutôt que d'une vision partielle.

‍

Erin Hannaford : Parfait, merci. Ralph demande comment nous pouvons vérifier que la correction apportée par un fournisseur résout réellement le problème, plutôt que de simplement le masquer — il a constaté que de nombreux tickets « résolus » ne font que déplacer le problème vers un endroit où le scanner ne peut pas le détecter.

‍

Rob Nalen : Bonne question. Je vous renvoie aux quatre questions que j’ai évoquées. Tout d’abord, collaborez avec le prestataire pour vous faire une idée précise de ce qu’il propose réellement avant de vous engager dans une mission — il peut s’agir d’une simple démonstration de faisabilité portant sur un seul framework, voire d’une simple correction.

‍

Consultez les notes de mise à jour : elles devraient établir un lien entre un CVE spécifique et une version précise. Vous ne pouvez pas vous contenter de vous fier à une page marketing indiquant simplement « oui, vous êtes pris en charge ». Viennent ensuite, et c'est peut-être le plus important, les déclarations VEX : celles-ci sont lisibles par machine, et vous pouvez les importer dans votre plateforme SCA ou DevSecOps afin de vérifier si elles correspondent à votre propre suivi des vulnérabilités.

‍

Au-delà de cela, renseignez-vous sur le fournisseur lui-même : est-il agréé en tant que CNA auprès de MITRE ? Pour les CVE que HeroDevs corrige, nous sommes spécifiquement identifiés comme l'organisation ayant découvert et corrigé la vulnérabilité — ce qui signifie que nous ne nous contentons pas d'attendre que des correctifs en amont nous parviennent ; nous recherchons activement ces problèmes par nous-mêmes.

‍

Enfin, lorsque vous réalisez votre validation de principe, exécutez le code réel et assurez-vous qu’il ne s’agit pas simplement d’une mise à jour de version — là encore, cela renvoie à la déclaration VEX et à la question de savoir si la vulnérabilité CVE a véritablement été corrigée. Ces étapes vous aideront à déterminer si un fournisseur dispose de l’expertise nécessaire.

‍

Erin Hannaford : Parfait, et je crois que nous avons le temps pour une dernière question. Richard demande : si nous disposons déjà d'un plan pluriannuel visant à abandonner les architectures héritées, cela ne nous met-il pas en conformité avec la CRA ?

‍

Rob Nalen : Bonne question — malheureusement, la réponse est non. En vertu de certaines autres réglementations, il était possible de demander une dérogation en invoquant le statut « en cours de développement » d’un produit afin de limiter les risques. Dans le cadre de la CRA de l’UE, cela ne dispense pas votre organisation de son obligation de conformité. Les obligations de déclaration prévues à l'article 14 sont en vigueur depuis le 11 septembre 2026 et s'appliquent à tous les produits commercialisés — le simple fait d'avoir engagé un processus de modernisation n'est donc pas suffisant en soi.

‍

Voici ce que je recommanderais : les entreprises devraient dès à présent passer au crible leurs outils de scan SCA afin d’identifier les logiciels open source en fin de vie, de migrer vers les versions actuelles aussi rapidement que possible lorsque cela est faisable et, lorsque ce n’est pas le cas, de faire appel à des prestataires tels que HeroDevs pour obtenir l’assistance dont elles ont besoin et garantir leur conformité dès aujourd’hui.

‍

Erin Hannaford : Merci, Rob, et merci à tous d'avoir participé à cette session. Cela conclut le webinaire d'aujourd'hui. Ne manquez pas l'enregistrement du webinaire et le livre blanc qui l'accompagne. Merci.

‍