Guide du développeur sur la conformité en matière de sécurité

Résumé analytique

Autrefois, la conformité était le problème de quelqu’un d’autre. Une équipe chargée de la gouvernance, de la gestion des risques et de la conformité (GRC) remplissait des questionnaires, un auditeur venait une fois par an, et les développeurs continuaient à livrer leurs produits. Cette époque est révolue. Partout dans le monde, les régulateurs et les organismes de normalisation se sont mis d’accord sur un ensemble d’obligations en matière de sécurité qui incombent désormais directement aux équipes chargées d’écrire le code et de livrer les applications : les équipes d’ingénierie. 

‍

Il existe des principes communs que l'on retrouve dans pratiquement tous les grands cadres réglementaires et toutes les réglementations majeures :

1. Tenir à jour un inventaire précis des composants logiciels, de plus en plus souvent sous la forme d'une nomenclature logicielle (SBOM).
2. Corriger les vulnérabilités connues dans les délais fixés, souvent de 30 jours ou moins pour les vulnérabilités de gravité critique.
3. Présenter un processus documenté et reproductible permettant d'identifier les vulnérabilités, d'établir leur ordre de priorité et d'y remédier.

‍

Par définition, les logiciels en fin de vie (EOL) ne répondent à aucun de ces trois critères. Lorsqu’une version de framework, d’environnement d’exécution ou de bibliothèque cesse de bénéficier de correctifs de sécurité, chaque vulnérabilité CVE identifiée par la suite ne sera plus jamais corrigée par les voies habituelles. Aucun correctif ne sera publié. C’est ce simple fait qui fait passer des affirmations telles que « nous utilisons AngularJS » ou « nous sommes toujours sous Node.js 16 » du domaine de la dette technique à celui de la conformité.

‍

Ce livre blanc passe en revue l'ensemble des principales normes, référentiels, directives et réglementations, en mettant l'accent sur quatre aspects que les développeurs peuvent réellement maîtriser : la gestion des vulnérabilités, les logiciels open source, les versions prises en charge et les logiciels en fin de vie. Pour chacun de ces aspects, il propose des exemples concrets et des recommandations pratiques.

‍

États-Unis d'Amérique

PCI DSS 4.x (Norme de sécurité des données de l'industrie des cartes de paiement)

S'applique à : toute entité qui stocke, traite ou transmet des données relatives aux cartes de paiement. Obligation contractuelle, imposée par les réseaux de cartes et les banques acquéreuses.

‍

Ce que cela implique. L'exigence 6.3.1 impose aux organisations d'identifier les nouvelles failles de sécurité à l'aide de sources reconnues par le secteur et de leur attribuer un niveau de risque. L'exigence 6.3.2 impose de dresser un inventaire des logiciels sur mesure et personnalisés, y compris les composants tiers et open source qui y sont intégrés. L'exigence 6.3.3 impose l'installation des correctifs relatifs aux vulnérabilités critiques ou de gravité élevée dans un délai d'un mois à compter de leur publication, les autres correctifs applicables devant être installés dans un délai défini par l'entité (généralement trois mois). L'exigence 11.3.1 prévoit la réalisation d'analyses internes de vulnérabilité au moins une fois par trimestre, tandis que l'exigence 11.3.1.1 impose une analyse ciblée des risques pour les vulnérabilités qui ne sont ni critiques ni de gravité élevée. Pour résumer l’ensemble de ces exigences, l’exigence 12.3.4 impose un examen annuel de l’ensemble du matériel et des logiciels utilisés, afin de vérifier que les technologies bénéficient toujours des correctifs de sécurité fournis par les éditeurs, qu’elles permettent de maintenir la conformité et que leur fin de vie est suivie, avec un plan approuvé par la direction pour remédier aux technologies obsolètes ou en fin de vie.

‍

Pourquoi les logiciels en fin de vie (EOL) posent problème. Le délai d’un mois prévu dans la version 6.3.3 suppose l’existence d’un correctif. Lorsqu’un CVE critique est publié concernant un framework en fin de vie, aucun correctif, qu’il provienne d’un éditeur ou d’un projet open source, ne sera jamais fourni ; cette exigence devient donc structurellement impossible à satisfaire. Un auditeur qui identifie un composant en fin de vie présentant un CVE critique connu dans l’environnement de données des titulaires de carte constate un cas de non-conformité, et non un point susceptible de faire l’objet d’une négociation.

‍

Exemple. Une plateforme de paiement utilise AngularJS .x pour son interface de paiement, version dont la fin de vie a été atteinte en janvier 2022. Une nouvelle vulnérabilité CVE critique est publiée concernant AngularJS. En vertu de la norme 6.3.3, l’organisation dispose d’un mois pour installer un correctif qui n’existe pas. Ses options réalistes sont une migration d’urgence (rarement réalisable en 30 jours pour un processus de paiement en production), des contrôles compensatoires documentés qu’un évaluateur doit accepter, ou un support étendu commercial qui fournit un correctif rétroporté et rétablit une voie de remédiation défendable.

‍

Recommandations à l'intention des développeurs :

• Gérez l'inventaire des composants 6.3.2 sous forme d'artefact de build, et non sous forme de feuille de calcul. Générez une SBOM dans l'environnement d'intégration continue (CI) à chaque mise en production afin que l'inventaire soit toujours à jour.
• Suivez les dates de fin de vie (EOL) de chaque framework et environnement d'exécution dans l'environnement de production, et considérez une date de fin de vie imminente comme une échéance de conformité, et non comme une tâche en attente.
• Pour les composants dont la fin de vie (EOL) est déjà dépassée, il convient soit de les isoler hors de l'environnement de production, soit de les migrer, soit de les placer sous un contrat de support étendu commercial afin que les vulnérabilités CVE critiques puissent encore être corrigées dans le délai de 30 jours.

‍

Règle de sécurité de la loi sur la portabilité et la responsabilité en matière d'assurance maladie (HIPAA)

S'applique aux : entités concernées et partenaires commerciaux traitant des informations de santé protégées sous forme électronique (ePHI) aux États-Unis. Loi fédérale obligatoire.

‍

Ce que cela implique. La règle de sécurité exige une évaluation précise et approfondie des risques et des vulnérabilités pesant sur les ePHI (45 CFR 164.308(a)(1)(ii)(A)), ainsi que des mesures de sécurité suffisantes pour ramener ces risques à un niveau raisonnable et approprié. Les directives du HHS considèrent l’analyse des risques et la gestion des vulnérabilités comme fondamentales, et la lettre d’information sur la cybersécurité de janvier 2026 du Bureau des droits civils (OCR) stipule explicitement que l’analyse des risques doit identifier les vulnérabilités, telles que les logiciels non mis à jour, et associer cette identification à des mesures correctives actives. Un avis de projet de réglementation (NPRM) daté de décembre 2024 irait plus loin, en ajoutant des normes explicites en matière de gestion des vulnérabilités et des correctifs, un scan des vulnérabilités au moins tous les six mois, des tests d’intrusion annuels, ainsi que des délais de correction proposés pouvant aller jusqu’à 15 jours pour les vulnérabilités critiques. À la mi-2026, l’avis de projet de réglementation n’avait pas encore été finalisé et la décision finale avait été reportée, mais l’OCR applique activement la réglementation existante, et sa politique de contrôle vise déjà les organisations qui répertorient les risques sans pour autant prendre les mesures nécessaires pour y remédier.

‍

Pourquoi les logiciels en fin de vie posent problème. La loi HIPAA n’interdit jamais l’utilisation de « logiciels en fin de vie ». Elle stipule simplement que les mesures de protection doivent être raisonnables et appropriées. Après une violation, il est extrêmement difficile de justifier comme raisonnable l’utilisation d’un composant non pris en charge, présentant des vulnérabilités CVE connues et non corrigibles, au sein d’un système en contact avec des données ePHI. Les enquêtes de l’OCR révèlent régulièrement que les mêmes vulnérabilités apparaissent année après année dans les évaluations des risques, sans qu’aucune mesure corrective ne soit prise, jusqu’à ce qu’elles soient exploitées ; c’est ce schéma qui conduit à des conclusions de négligence délibérée.

‍

Exemple. Un portail patient fonctionne sous une version de Drupal arrivée en fin de vie Drupal v7). L'analyse annuelle des risques le signale, le constat est consigné, mais rien n'est fait pendant deux ans car la migration est coûteuse. Une faille de sécurité survient via un CVE connu. Le constat consigné mais ignoré devient alors l'élément central de l'enquête de l'OCR, transformant ainsi un raccourci technique en preuve de négligence.

‍

Recommandations à l'intention des développeurs :

• Veillez à ce que chaque composant en fin de vie (EOL) en contact avec des données de santé protégées (ePHI) figure dans l'analyse formelle des risques, accompagnée d'un plan de remédiation et d'un responsable. Une analyse des risques qui omet les logiciels non mis à jour est désormais explicitement considérée comme insuffisante selon les directives de l'OCR.
• Faites le point : pour chaque vulnérabilité identifiée, consignez la mesure corrective mise en œuvre (correctif, mise à jour, mise en quarantaine, prolongation du support), car l'application de la réglementation de l'OCR se concentre désormais sur les mesures prises par les organisations face aux risques identifiés.
• N'attendez pas que le projet de règlement (NPRM) soit finalisé. Les mesures de contrôle qu'il propose (fréquence des analyses, délais d'application des correctifs, inventaire des actifs) correspondent à ce que les autorités de régulation considèrent déjà comme un niveau de sécurité raisonnable en 2026.

‍

FedRAMP et NIST SP 800-53 SI-2 (correction des failles)

S'applique à : tous les services cloud vendus aux agences fédérales américaines. Obligatoire.

‍

Ce que cela implique. Les exigences de base du programme FedRAMP s’appuient sur les contrôles définis dans la norme NIST SP 800-53. Le contrôle SI-2 impose aux organisations d’identifier, de signaler et de corriger les failles du système, ainsi que d’installer les mises à jour logicielles liées à la sécurité dans des délais définis. FedRAMP met cela en œuvre à l’aide de délais de correction basés sur le niveau de gravité : 30 jours pour les failles de gravité élevée, 90 jours pour celles de gravité modérée et 180 jours pour celles de faible gravité, dont le suivi est assuré par le processus mensuel « Plan d’action et jalons » (POA&M) et par des analyses de surveillance continues.

‍

Pourquoi les logiciels en fin de vie (EOL) posent problème. Les outils d’analyse de sécurité signalent les CVE ; un composant EOL présentant un CVE de gravité élevée génère un élément POA&M assorti d’un délai de 30 jours et pour lequel aucun correctif n’est disponible. Les résultats qui dépassent ce délai sans avoir été corrigés mettent en péril l’autorisation d’exploitation (ATO). Contrairement à un audit commercial, il ne s’agit pas d’un événement annuel : les analyses sont effectuées tous les mois, voire plus souvent, de sorte que les logiciels en fin de vie génèrent un flux continu de résultats en retard.

‍

Exemple. Un fournisseur de SaaS agréé FedRAMP constate que son service de reporting repose sur une version Express en fin de vie (EOL). À chaque analyse de sécurité, le composant est à nouveau signalé ; chaque nouvelle vulnérabilité CVE donne lieu à un nouvel élément POA&M d’une durée de 30 ou 90 jours ; et l’évaluateur de l’organisme d’évaluation tiers (3PAO) répertorie cette dépendance non prise en charge comme une faiblesse persistante. Le fournisseur doit présenter soit un plan de migration crédible, soit une assistance assurée par le fournisseur qui rétablit la disponibilité des correctifs.

‍

Recommandations à l'intention des développeurs :

• Considérez les délais FedRAMP de 30, 90 et 180 jours comme des accords de niveau de service (SLA) techniques et intégrez-les à votre outil de suivi des incidents afin que les tickets relatifs aux vulnérabilités soient automatiquement assortis de dates d'échéance.
• Éliminez les composants en fin de vie (EOL) ou assurez-vous qu’ils soient couverts avant l’évaluation initiale. Cela revient bien moins cher que de devoir justifier chaque mois les postes récurrents liés à l’exploitation et à la maintenance (POA&M) par la suite.
• Veillez à ce que les demandes de dérogation et les ajustements liés aux risques restent justifiés et sporadiques ; les évaluateurs analysent les tendances, et les demandes de dérogation répétées concernant un même élément non justifié sont le signe d'un risque non maîtrisé.

‍

Cadre de cybersécurité (CSF) 2.0 du NIST

S'applique à : caractère facultatif pour la plupart des organisations privées ; obligatoire pour les agences fédérales américaines et largement exigé de leurs sous-traitants. Constitue également le modèle de référence de facto pour la cyberassurance et les rapports destinés au conseil d'administration.

‍

Ce que cela implique. La sous-catégorie PR.PS-02 du CSF 2.0 stipule que les logiciels doivent être « maintenus, remplacés et supprimés en fonction du risque ». Les sous-catégories ID.RA exigent que les vulnérabilités des actifs soient identifiées, validées et enregistrées. Le cadre est axé sur les résultats : il ne prescrit pas de délais de correction, mais établit l’attente selon laquelle chaque logiciel de l’environnement soit soit activement maintenu, soit délibérément retiré en fonction du risque.

‍

Pourquoi les logiciels en fin de vie (EOL) ne répondent pas à ces critères. Par définition, un logiciel en fin de vie n’est plus maintenu. Selon la norme PR.PS-02, une organisation dispose exactement de trois options justifiables pour ce type de logiciel : le remplacer, le supprimer ou rétablir sa maintenance. Continuer à l’utiliser sans rien dire est la seule option que le cadre ne permet pas. C’est également le cadre dans lequel le support étendu commercial s’inscrit le plus clairement, car l’application de correctifs par le fournisseur pour un composant en fin de vie correspond littéralement à la situation « maintenue ».

‍

Exemple. Un fabricant qui se conforme à la norme CSF 2.0 dans le cadre du renouvellement de son assurance cyber procède à un inventaire des applications utilisées dans ses ateliers et découvre un outil de planification reposant sur une Vue 2 de vie (EOL) et une version EOL du moteur d'exécution Node.js. Le questionnaire de l'assureur demande si tous les logiciels sont pris en charge et mis à jour. Pour répondre honnêtement, il faut soit disposer d'un plan de migration avec un calendrier précis, soit d'un contrat de support ; une réponse mensongère rendra caduques les arguments relatifs à la couverture en cas d'incident.

‍

Recommandations à l'intention des développeurs :

• Classer chaque application dans l'un des trois états suivants : maintenue activement par le projet en amont, maintenue dans le cadre d'un support étendu commercial, ou dont le remplacement ou la suppression est prévu à une date donnée. Tout élément non classé correspond à une lacune au titre de la norme PR.PS-02.
• Intégrez les données relatives à la fin de vie (EOL) et au statut de support dans le même inventaire des actifs que celui utilisé pour le profilage CSF, afin que les responsables des risques puissent visualiser le statut du cycle de vie des logiciels parallèlement à leur niveau de criticité.
• Consignez les décisions relatives aux risques. Le CSF repose sur des données factuelles : la différence entre « nous acceptons ce risque jusqu'à la migration du troisième trimestre » et « personne ne s'en est occupé » réside dans la documentation.

‍

SSDF du NIST (SP 800-218, Cadre de développement logiciel sécurisé)

S'applique à : Cadre volontaire. Le mémorandum M-26-05 de l'OMB a abrogé l'obligation d'auto-attestation imposée aux éditeurs de logiciels vendant leurs produits aux agences fédérales américaines, obligation qui était auparavant prévue par le décret présidentiel n° 14028 et les mémorandums M-22-18/M-23-16 de l'OMB. Les agences peuvent toutefois choisir d'exiger des attestations ou des SBOM en fonction de leurs propres évaluations des risques.

‍

Ce que cela implique. Le SSDF constitue un cadre flexible axé sur l’intégration précoce de la sécurité, ce qui signifie que la sécurité est intégrée dès le début dans l’ensemble du processus de création logicielle. Il exige des organisations qu’elles définissent et maintiennent des politiques de développement sécurisées (pratiques PO), qu’elles protègent les logiciels (PS), qu’elles produisent des logiciels bien sécurisés (PW) et qu’elles réagissent aux vulnérabilités (RV). La pratique PW.4 porte sur la réutilisation de logiciels bien sécurisés et impose aux organisations d’évaluer et de surveiller les composants tiers et open source. Le groupe de pratiques RV exige l’identification, l’évaluation et la correction continues des vulnérabilités dans les logiciels déjà mis sur le marché, ce qui suppose que les composants concernés puissent encore bénéficier de correctifs.

‍

Pourquoi les logiciels en fin de vie (EOL) posent problème. Un éditeur ne peut garantir une réponse aux vulnérabilités conforme au SSDF pour un produit reposant sur des composants qui ne bénéficient plus de mises à jour de sécurité. L'exigence du PW.4 concernant l'acquisition de composants provenant de sources maintenues, ainsi que celle du RV relative à la correction continue des failles, s'effondrent toutes deux lorsque le projet open source sous-jacent a cessé d'être pris en charge.

‍

Exemple. Une entreprise de logiciels vendant ses produits à une agence fédérale signe volontairement le formulaire d’attestation de développement de logiciels sécurisés de la CISA. Son produit phare est toutefois toujours livré avec jQuery . jQuery et une Bootstrap en fin de vie. Le service juridique demande au service d’ingénierie si l’attestation est exacte. Soit le service d’ingénierie met en place à la hâte un programme de correction, soit l’entreprise atteste d’un élément contredit par son arbre de dépendances, ce qui représente un risque de fausse déclaration, et pas seulement un risque de sécurité.

‍

Recommandations à l'intention des développeurs :

• Mettre en place une politique d'intégration des logiciels libres qui permette de consigner le statut du support et la date prévue de fin de vie de chaque nouvelle dépendance avant son adoption, et non après.
• Surveillez les dépendances en fonction des événements liés au cycle de vie (mode maintenance, dépôts archivés, dates de fin de vie annoncées), et pas uniquement en fonction des CVE. La fin du support d'un projet constitue un événement de sécurité.
• Avant toute attestation fédérale, effectuez un audit du cycle de vie des dépendances et corrigez les problèmes ou obtenez une couverture prise en charge pour chaque composant en fin de vie (EOL) inclus dans le produit.

‍

NIST SP 800-171 et la certification du modèle de maturité en matière de cybersécurité (CMMC)

S'applique aux : sous-traitants du ministère de la Défense (DoD) et fournisseurs fédéraux traitant des informations non classifiées mais soumises à des restrictions d'accès (CUI). Obligatoire, les évaluations CMMC étant désormais progressivement intégrées aux contrats du DoD.

‍

Ce que cela implique. L'exigence 3.14.1 (renumérotée 03.14.01 dans la révision 3) impose d'identifier, de signaler et de corriger les failles du système dans les meilleurs délais. Les directives d'évaluation mentionnent explicitement les correctifs, les service packs et les hotfixs installés comme preuves de la correction. Les exigences connexes portent sur l'analyse des vulnérabilités et leur correction (3.11.2, 3.11.3).

‍

Pourquoi les logiciels en fin de vie (EOL) constituent un problème. Le principe « corriger les failles dans les meilleurs délais » ne prévoit aucune exception pour les logiciels dont le fournisseur ou le projet open source a cessé de publier des correctifs. La présence d’un composant en fin de vie comportant des vulnérabilités CVE connues au sein d’une enclave CUI constitue un manquement permanent à la clause 3.14.1, qui sera sanctionné par l’évaluateur CMMC à l’encontre du prestataire ; un seul manquement à cette pratique peut entraîner la perte de la certification et, par conséquent, l’inéligibilité au contrat.

‍

Exemple. Le portail de documents techniques d’un fournisseur du secteur de la défense fonctionne sur un framework web en fin de vie (EOL). Lors de l’évaluation CMMC de niveau 2, l’évaluateur demande des preuves attestant que les failles du portail sont corrigées en temps opportun. Le fournisseur peut présenter des rapports d’analyse identifiant les CVE, mais aucune correction, car aucune n’a été apportée en amont. Cette pratique est jugée « non conforme », ce qui compromet la certification dont l’entreprise a besoin pour conserver ses contrats avec le ministère américain de la Défense (DoD).

‍

Recommandations à l'intention des développeurs :

• Définissez le périmètre de manière stricte : veillez à ce que les logiciels en fin de vie (EOL) ne se trouvent pas du tout dans le périmètre des informations sensibles (CUI) dans la mesure du possible, car tout ce qui se trouve à l'intérieur de ce périmètre fait l'objet d'une évaluation.
• Lorsqu'un composant en fin de vie doit rester dans le périmètre, documentez les contrôles compensatoires et associez-les à une source de correctifs prise en charge afin de pouvoir démontrer que la « correction a été apportée en temps opportun ».
• Conservez les justificatifs relatifs aux correctifs (tickets, journaux de déploiement, analyses avant/après) classés par exigence ; les évaluations CMMC reposent sur la présentation de justificatifs, et les corrections non documentées sont considérées comme inexistantes.

‍

Règles de la SEC relatives à la publication d'informations sur la cybersécurité

S'applique à : toutes les sociétés cotées en bourse aux États-Unis. Obligatoire, à compter de décembre 2023.

‍

Exigences. Les sociétés enregistrées doivent déclarer les incidents de cybersécurité significatifs au moyen du formulaire 8-K dans un délai de quatre jours ouvrés à compter de la constatation de leur caractère significatif, et doivent rendre compte chaque année (règlement S-K, rubrique 106) de leurs processus d'évaluation, d'identification et de gestion des risques de cybersécurité significatifs, y compris le contrôle exercé par le conseil d'administration sur la gestion des risques de cybersécurité, la stratégie et la gouvernance en la matière, dans leurs rapports annuels (formulaire 10-K).

‍

Pourquoi la question des logiciels en fin de vie (EOL) est-elle importante dans ce contexte ? Les règles ne mentionnent ni les correctifs ni les logiciels en fin de vie. En revanche, la notion d’importance significative en tient compte. Une vulnérabilité critique connue et non corrigée dans un composant dont dépend l’entreprise peut en soi constituer un risque significatif nécessitant une divulgation ; de même, un incident imputable à un système dont la fin de vie est connue correspond précisément au type de situation qui transforme une violation de données en litige en matière de valeurs mobilières, car les plaignants feront valoir que le risque était connu, qu’il n’avait pas été corrigé et qu’il n’avait pas fait l’objet d’une divulgation adéquate.

‍

Exemple. Une entreprise du secteur des services financiers subit une violation de sécurité via une application Java utilisant Spring , dont la prise en charge a pris fin (EOL). Lors de la gestion de l'incident, les juristes découvrent des tickets internes signalant ce statut EOL six mois plus tôt. Le délai de divulgation de quatre jours est désormais la partie la plus facile ; le plus difficile consiste à expliquer, dans le formulaire 8-K et les documents déposés par la suite, pourquoi un risque documenté et connu n'a jamais été corrigé, alors que les processus de contrôle du conseil d'administration font l'objet d'une attention particulière.

‍

Recommandations à l'intention des développeurs :

• Il faut savoir que les documents techniques internes (tickets, fils de discussion sur Slack, entrées du registre des risques) concernant les logiciels en fin de vie peuvent faire l'objet d'une demande d'accès et seront examinés à la lumière des informations rendues publiques à la suite d'un incident.
• Fournissez aux équipes chargées de la sécurité et aux services juridiques des données précises sur le cycle de vie : un inventaire fidèle des risques liés à la fin de vie des produits permet à l'entreprise de décrire en toute transparence son processus de gestion des risques dans les informations fournies au titre de la rubrique 106.
• Donnez la priorité à la mise en conformité des composants en fin de vie (EOL) dans les chemins critiques pour le chiffre d'affaires, car c'est là que se recoupent les notions de « matériel » et de « non patché ».

‍

Canada

CCSPA (loi sur la protection des systèmes cybernétiques critiques, projet de loi C-8)

S'applique aux : opérateurs désignés dans les infrastructures essentielles relevant de la réglementation fédérale : télécommunications, secteur bancaire, énergie et transports. Obligatoire. Le projet de loi C-8 a reçu la sanction royale le 15 juin 2026, et les obligations prévues par la CCSPA entrent en vigueur progressivement par décret.

‍

Ce que cela implique. Les opérateurs désignés doivent mettre en place et appliquer un programme de cybersécurité, atténuer les risques liés à la chaîne d’approvisionnement et aux tiers, signaler les incidents de cybersécurité dans les délais fixés, se conformer aux directives en matière de cybersécurité et tenir des registres. Les sanctions peuvent atteindre 15 millions de dollars canadiens pour les organisations, et les infractions répétées peuvent être comptabilisées séparément pour chaque jour où elles se poursuivent. Les membres du conseil d’administration et les dirigeants de l’entreprise peuvent être tenus personnellement responsables s’ils ont ordonné, autorisé ou toléré la non-conformité de l’organisation.

‍

Pourquoi les logiciels en fin de vie (EOL) posent problème. La responsabilité en matière de risques liés à la chaîne d’approvisionnement s’étend directement à la pile logicielle. Une bibliothèque open source non corrigée ou un framework en fin de vie (EOL) au sein d’un système informatique critique correspond exactement au type de risque tiers que le programme doit identifier et atténuer ; compte tenu des pénalités journalières encourues, l’attitude consistant à « savoir et ne rien faire » revient très cher. La CCSPA exige la mise en place de programmes comprenant des évaluations de vulnérabilité régulières, des analyses du système et des plans d’atténuation actifs visant à corriger ou à isoler les failles avant qu’elles ne puissent être exploitées.

‍

Exemple. Le portail de gestion des pannes d’un opérateur du secteur de l’énergie relevant de la réglementation fédérale fonctionne sous une Angular en fin de vie (EOL). Une fois désigné au titre de la CCSPA, le programme de cybersécurité de l’opérateur doit recenser les risques liés à la chaîne d’approvisionnement. Le front-end en fin de vie apparaît dans l’évaluation ; l’opérateur doit démontrer qu’il a mis en place des mesures d’atténuation, ce qui, dans la pratique, implique une migration selon un calendrier précis, l’isolation du système ou le rétablissement du support du fournisseur assorti de contrats de niveau de service (SLA) pour les correctifs.

‍

Recommandations à l'intention des développeurs :

• Si votre employeur exerce ses activités dans les secteurs canadiens des télécommunications, de la finance, de l'énergie ou des transports, commencez dès maintenant à dresser l'inventaire du cycle de vie des logiciels ; les désignations et les réglementations sont progressivement mises en place, et un programme élaboré après la désignation devra être mis en place à la hâte.
• Dans le cadre du CCSPA, considérez les dépendances open source comme des fournisseurs : consignez qui assure la maintenance de chaque composant critique, son statut en matière d'assistance, ainsi que la manière dont les correctifs de sécurité vous sont transmis.
• Intégrer les mécanismes de signalement des incidents dans les pratiques d'ingénierie (conservation des journaux, cartographie de la zone d'impact au niveau des composants) afin qu'un rapport puisse identifier rapidement les systèmes et composants affectés.

‍

Union européenne

DORA (loi sur la résilience opérationnelle numérique)

S'applique aux : entités financières de l'UE (banques, assureurs, entreprises d'investissement, établissements de paiement, prestataires de services liés aux crypto-actifs) et aux prestataires tiers de services TIC essentiels. Obligatoire, en vigueur depuis le 17 janvier 2025.

‍

Ce que cela implique. Le cadre de gestion des risques informatiques de la DORA impose aux entités financières d'utiliser des systèmes informatiques fiables, dotés d'une capacité suffisante et résilients sur le plan technologique, de tenir à jour un inventaire de tous les actifs informatiques (y compris le suivi des actifs arrivant en fin de vie), de mettre en œuvre une gestion des correctifs, ainsi que d'identifier et de répertorier les systèmes informatiques obsolètes en vue de leur suppression progressive ou de leur gestion spécifique.

‍

Pourquoi les logiciels en fin de vie posent problème. La directive DORA est d’une franchise inhabituelle : les systèmes qui ne bénéficient plus d’un support technique sont considérés comme une faille fondamentale de la résilience opérationnelle, et l’obligation d’inventaire des actifs prévoit expressément le suivi des logiciels en fin de vie. Une entité financière utilisant des logiciels en fin de vie dans ses processus de paiement ou de négociation présente une faille de résilience documentée que les autorités de contrôle et leurs auditeurs ont pour instruction de rechercher.

‍

Exemple. Le tableau de bord des transactions d’un établissement de paiement de l’UE fonctionne sous Vue 2, dont la fin de vie (EOL) est prévue depuis décembre 2023. L’inventaire des actifs DORA doit consigner cette information, son niveau de criticité et le plan d’action prévu. Lors d’un contrôle prudentiel, l’absence de plan constitue un constat ; en revanche, « migration prévue pour 2027 avec des correctifs de sécurité commerciaux assurant la sécurité pendant la période transitoire » correspond à un système hérité maîtrisé.

‍

Recommandations à l'intention des développeurs :

• Ajoutez les dates de fin de vie et le statut de prise en charge en tant que champs obligatoires dans l'inventaire des actifs informatiques, et automatisez leur renseignement à partir de vos manifestes de dépendances.
• Pour chaque composant obsolète ou en fin de vie (EOL) intervenant dans une fonction critique ou importante, documentez l'un des trois plans suivants : migration avant une date donnée, mise hors service avant une date donnée, ou application de correctifs jusqu'à ce que l'une des deux premières options soit mise en œuvre.
• Tester les hypothèses de résilience : la norme DORA exige la réalisation de tests de résilience opérationnelle numérique, et les composants en fin de vie (EOL) dont la vulnérabilité est connue constituent la première cible qu’un test d’intrusion axé sur les menaces cherchera à exploiter.

‍

RGPD (Règlement général sur la protection des données), article 32

S'applique à : toutes les organisations traitant des données à caractère personnel provenant de l'UE, quel que soit leur lieu d'implantation. Obligatoire.

‍

Ce qu'il exige. L'article 32 exige la mise en œuvre de « mesures techniques et organisationnelles appropriées » afin de garantir un niveau de sécurité adapté au risque, en tenant explicitement compte de « l'état de la technique ». Il n'impose ni la mise en place de correctifs, ni de délais, ni de technologies spécifiques.

‍

Pourquoi les logiciels en fin de vie (EOL) constituent un problème. L’expression clé est « état de la technique ». Après une violation de données à caractère personnel, l’autorité de contrôle examine si les mesures mises en place étaient appropriées compte tenu des technologies disponibles. Il est très difficile de justifier qu’un logiciel présentant une vulnérabilité CVE rendue publique, pour laquelle aucun correctif n’est disponible et dont la période de support a expiré depuis longtemps, correspond à l’état de la technique ; les régulateurs européens ont d’ailleurs infligé à plusieurs reprises des amendes à des organisations à la suite de violations dues à des vulnérabilités connues et non corrigées.

‍

Exemple. Une solution SaaS de marketing traitant des données de clients de l’UE est victime d’une faille de sécurité due à un CVE connu dans une chaîne jQuery en fin de vie. L’analyse au titre de l’article 32 ne vise pas à déterminer si l’entreprise a été victime d’un coup du sort, mais à établir s’il était « approprié » de continuer à utiliser un composant dont le support avait pris fin et qui faisait l’objet d’exploits publics. Les amendes prévues par le RGPD peuvent atteindre 4 % du chiffre d’affaires annuel mondial lorsque des violations des principes fondamentaux sont également constatées, et une violation due à une vulnérabilité connue constitue un facteur aggravant classique (négligence et défaillance des mesures techniques).

‍

Recommandations à l'intention des développeurs :

• Donner la priorité à la correction des vulnérabilités sur les systèmes traitant des données à caractère personnel, et être en mesure d'expliquer la logique de hiérarchisation.
• Lorsqu'un composant arrive en fin de vie (EOL), consignez la décision prise à ce moment-là concernant les risques (migration, mise en isolation, contrat de support), car une documentation établie au moment des faits constitue le meilleur moyen de défense au titre de l'article 32.
• Appliquer le principe de minimisation des données dans les systèmes existants : moins un système en fin de vie traite de données à caractère personnel, moindre est son exposition au risque visé à l'article 32 pendant la migration.

‍

Directive NIS2

S'applique aux entités essentielles et importantes dans 18 secteurs de l'UE (énergie, transports, santé, infrastructures numériques, fabrication de produits critiques, fournisseurs de services numériques, etc.). Obligatoire ; la transposition dans le droit des États membres devait être achevée en octobre 2024 et la mise en œuvre s'accélère dans les États membres selon des calendriers nationaux.

‍

Ce que cela implique. L’article 21, paragraphe 2, impose dix mesures minimales de gestion des risques, notamment (e) « la sécurité lors de l’acquisition, du développement et de la maintenance des réseaux et des systèmes d’information, y compris la gestion et la divulgation des vulnérabilités » et (d) la sécurité de la chaîne d’approvisionnement couvrant les relations avec les fournisseurs directs et les prestataires de services. L’article 21, paragraphe 3, impose aux entités de prendre en compte les vulnérabilités spécifiques à chaque fournisseur ainsi que la qualité globale et les pratiques de développement sécurisées des produits de ces derniers. L’article 23 fixe les délais de signalement des incidents à 24 heures (alerte précoce), 72 heures (notification) et un mois (rapport final). Les amendes peuvent atteindre 10 millions d’euros ou 2 % du chiffre d’affaires mondial pour les entités essentielles, et la directive NIS2 introduit une responsabilité personnelle pour les organes de direction.

‍

Pourquoi les logiciels en fin de vie (EOL) posent problème. L'article 21, paragraphe 2, point e), fait de la gestion des vulnérabilités lors du développement et de la maintenance une obligation légale, et les logiciels EOL sont des logiciels pour lesquels la gestion des vulnérabilités a structurellement pris fin. Les mesures relatives à la chaîne d'approvisionnement prévues aux articles 21, paragraphe 2, point d), et 21, paragraphe 3, étendent cette même logique aux composants open source : une entité doit tenir compte des pratiques de sécurité sous-jacentes aux logiciels dont elle dépend, et un projet en amont abandonné n'en présente aucune.

‍

Exemple. Un groupe hospitalier (entité essentielle) utilise une application Nuxt en fin de cycle de vie (EOL) pour gérer la planification des horaires de son personnel. Une attaque par ransomware s'introduit via une vulnérabilité CVE connue dans cette pile logicielle. Une fois le délai de 24 heures pour le signalement écoulé, l'enquête menée par l'autorité nationale examine si les mesures prévues à l'article 21 étaient en place ; un système dont la fin de vie est connue, présentant une vulnérabilité connue et pour lequel aucune procédure de gestion n'est documentée constitue un manquement direct à l'article 21, paragraphe 2, point e), et, en vertu de la directive NIS2, le conseil d'administration assume la responsabilité personnelle d'avoir approuvé les mesures de gestion des risques.

‍

Recommandations à l'intention des développeurs :

• Mettre en place un processus de gestion des vulnérabilités qui couvre explicitement les dépendances open source : identification (analyse SCA), triage, accords de niveau de service (SLA) relatifs aux mesures correctives et gestion de la divulgation.
• Tenir à jour les SBOM des systèmes prenant en charge des services essentiels ou importants afin de pouvoir répondre aux questions relatives à la chaîne d'approvisionnement à l'aide de données.
• Signalez par écrit à la direction les risques liés à la fin de vie des produits. Conformément aux dispositions de la norme NIS2 relatives à la responsabilité individuelle, la direction doit en être informée ; lui fournir des données précises sur le cycle de vie fait partie des missions de l'ingénierie.

‍

Loi sur la cyber-résilience (CRA)

S'applique aux : fabricants, importateurs et distributeurs de « produits comportant des éléments numériques » mis sur le marché de l'UE, qu'il s'agisse de matériel ou de logiciels, quel que soit le lieu d'établissement du fabricant. Obligatoire. Les obligations de déclaration des vulnérabilités activement exploitées et des incidents graves s'appliquent à compter du 11 septembre 2026 ; l'ensemble des exigences essentielles, l'évaluation de la conformité et le marquage CE s'appliquent à compter du 11 décembre 2027. Les sanctions peuvent atteindre 15 millions d'euros ou 2,5 % du chiffre d'affaires mondial.

‍

Ce qu’elle impose. Il s’agit de la loi la plus importante de cette liste pour les développeurs, car elle réglemente le produit lui-même tout au long de son cycle de vie. L’annexe I, partie I, exige que les produits soient livrés sans vulnérabilités exploitables connues. L’annexe I, partie II, définit les exigences en matière de gestion des vulnérabilités : les fabricants doivent identifier et documenter les vulnérabilités et les composants, notamment en établissant une liste des composants logiciels (SBOM) dans un format lisible par machine couvrant au moins les dépendances de premier niveau ; corriger les vulnérabilités sans délai au moyen de mises à jour de sécurité gratuites ; effectuer des tests de sécurité efficaces et réguliers ; et divulguer publiquement les vulnérabilités corrigées. Ces obligations s’appliquent pendant toute la durée de la période de support, qui doit être d’au moins cinq ans dans la plupart des cas. L’article 14 impose de signaler les vulnérabilités activement exploitées à l’ENISA et au CSIRT national dans un délai de 24 heures (alerte précoce), de 72 heures (notification complète) et de 14 jours après la mise à disposition d’un correctif (rapport final). Il est essentiel de noter que l’obligation de signalement prévue pour septembre 2026 s’applique aux produits déjà commercialisés, y compris les produits hérités commercialisés il y a plusieurs années.

‍

C’est pourquoi les logiciels open source et en fin de vie (EOL) revêtent ici une importance capitale. Un éditeur commercial qui intègre des composants open source est légalement responsable des vulnérabilités présentes dans ces composants. Si une vulnérabilité activement exploitée est détectée dans une bibliothèque open source intégrée à votre produit commercialisé, les délais de notification s’appliquent à vous, tout comme l’obligation de corriger le problème « sans délai », que le projet en amont existe encore ou non. Commercialiser un produit reposant sur un framework en fin de vie (EOL) revient à s’engager, en vertu de la loi, à traiter les vulnérabilités d’un composant dont le projet en amont ne s’en chargera plus jamais. La CRA transforme un « CVE ignoré dans une ancienne dépendance », qui relevait auparavant de la dette technique, en une responsabilité juridique passible des amendes les plus élevées prévues par la réglementation technologique.

‍

Exemple. Un éditeur de logiciels indépendant (ISV) commercialise un produit de gestion documentaire au sein de l’Union européenne. Ce produit intègre une Bootstrap en fin de vie (EOL) et un Express en fin de vie (EOL). En octobre 2026, une vulnérabilité CVE présente dans cette Express fait l’objet d’une exploitation active. En vertu de l’article 14, le fournisseur dispose de 24 heures pour émettre une alerte précoce, de 72 heures pour transmettre une notification complète et de 14 jours après la mise à disposition d’un correctif pour déposer le rapport final. Il n’existe pas de correctif en amont. Le fournisseur doit soit produire son propre correctif rétroporté, soit en acheter un via un support commercial étendu, soit expliquer aux autorités de régulation pourquoi aucun correctif n’est prévu pour un produit qu’il continue de commercialiser.

‍

Recommandations à l'intention des développeurs :

• Générez et mettez à jour dès maintenant des SBOM lisibles par machine (CycloneDX ou SPDX) pour chaque produit expédié ; vous ne pourrez pas respecter le délai de 24 heures pour la déclaration en septembre 2026 si vous ne connaissez pas déjà la composition de chaque version du produit.
• Vérifiez chaque gamme de produits afin d'identifier les composants en fin de vie (EOL) et réglez chaque cas avant décembre 2027 : mettez à niveau, retirez ces composants ou concluez un contrat de support permettant de bénéficier de correctifs pendant la période de support que vous avez définie.
• Définir et publier une durée de support réaliste pour chaque produit, et intégrer le coût des correctifs liés à cet engagement (y compris les composants tiers) dans la planification du produit ; la durée de support constitue désormais un engagement juridique, et non plus un simple argument marketing.
• Mettre en place une politique coordonnée de divulgation des vulnérabilités ainsi qu'un processus de prise en charge, de triage et de signalement, testé selon les délais de 24 et 72 heures.

‍

Royaume-Uni

RGPD au Royaume-Uni

S'applique aux : organisations traitant des données à caractère personnel au Royaume-Uni. Obligatoire, mise en œuvre par l'Information Commissioner's Office (ICO).

‍

Ce que cela implique. Repris du RGPD de l’UE après le Brexit, le RGPD britannique prévoit la même obligation, énoncée à l’article 32, de mettre en œuvre des « mesures techniques et organisationnelles appropriées ». Les antécédents de l’ICO en matière d’application de la loi concrétisent cette interprétation : le fait de ne pas corriger une vulnérabilité connue est considéré comme un manquement aux obligations de sécurité appropriées, et les violations attribuables à des logiciels dont le support a pris fin ou qui n’ont pas été corrigés depuis longtemps sont considérées comme de la négligence plutôt que comme un simple accident.

‍

Exemple. L'ICO a constaté que le Chartered Institute for Securities & Investment (CISI) avait enfreint l'article 32 en utilisant un logiciel de site web dont la fin de vie (EOL) était dépassée ; de plus, des pirates ont exploité une vulnérabilité critique pour laquelle un correctif était disponible depuis 2017, mais qui n'avait jamais été appliqué.

‍

Recommandations à l'intention des développeurs :

• Appliquer les mêmes règles que celles prévues par le RGPD de l'UE : inventaire, application prioritaire des correctifs pour les systèmes traitant des données à caractère personnel, et documentation en temps réel des décisions relatives aux risques liés aux composants en fin de vie.
• Lorsqu'un système existant ne peut pas être migré rapidement, réduisez la quantité de données à caractère personnel qu'il contient, isolez-le et conservez des preuves de ces deux mesures.
• Suivez les recommandations et les avis d'application relatifs aux ICO ; ils constituent une source jurisprudentielle évolutive permettant de déterminer ce que signifie « approprié » dans la pratique.

‍

Règlement britannique de 2018 sur la sécurité des systèmes d'information nationaux (NIS)

S'applique aux : opérateurs de services essentiels (eau, énergie, transports, santé) et aux fournisseurs de services numériques concernés (cloud, places de marché en ligne, moteurs de recherche). Obligatoire et juridiquement contraignant.

‍

Ce que cela implique. Les opérateurs doivent prendre des mesures appropriées et proportionnées pour gérer les risques pesant sur les réseaux et les systèmes d’information, ainsi que pour prévenir et minimiser l’impact des incidents, et doivent signaler les incidents significatifs dans un délai de 72 heures. Le cadre d’évaluation cybernétique (CAF) du NCSC, utilisé par les autorités de régulation britanniques pour évaluer la conformité, comprend des objectifs relatifs à la gestion des vulnérabilités et au maintien à jour des systèmes ; dans la pratique, les attentes en matière de rapidité d’application des correctifs correspondent souvent à la norme « Cyber Essentials », qui prévoit l’application des mises à jour critiques dans un délai de 14 jours.

‍

Pourquoi les logiciels en fin de vie (EOL) posent problème. Si un incident perturbant un service essentiel trouve son origine dans un système EOL non mis à jour, l'autorité de régulation conclura probablement à un manquement à l'obligation d'assurer la continuité du service, et le rapport à remettre dans les 72 heures servira alors de point de départ à une procédure de sanction. Un délai de 14 jours pour l'application d'un correctif est irréalisable pour un logiciel dont les correctifs ne sont plus disponibles.

‍

Exemple. Le tableau de bord de télémétrie d’un service des eaux britannique fonctionne sur une AngularJS en fin de vie. Une vulnérabilité CVE connue est exploitée, entraînant une perte de visibilité opérationnelle pendant une journée. L’incident doit être signalé dans les 72 heures, et l’évaluation CAF qui s’ensuit porte sur la gestion des vulnérabilités ; un composant non pris en charge présentant une vulnérabilité CVE publique et pour lequel aucun correctif n’est disponible obtient de mauvais résultats pour plusieurs indicateurs CAF.

‍

Recommandations à l'intention des développeurs :

• Réaliser une cartographie des systèmes de services essentiels par rapport au CAF et signaler chaque composant non pris en charge ; le CAF vérifie explicitement si les systèmes sont pris en charge et si les vulnérabilités sont gérées.
• Mettre en place une source de correctifs (en amont ou commerciale) capable de respecter un délai de 14 jours pour la mise à disposition des correctifs critiques concernant l'ensemble des éléments du parc des services essentiels.
• Répétez le processus de signalement sur 72 heures avec les équipes techniques, afin que les informations au niveau des composants (quels éléments étaient vulnérables, depuis quand, quelles mesures ont été prises) soient rapidement disponibles.

‍

Asie-Pacifique

APPI (Japon, loi sur la protection des données à caractère personnel)

S'applique aux : organisations traitant les données à caractère personnel de personnes physiques au Japon. Obligatoire.

‍

Ce que la loi exige. La loi APPI impose aux opérateurs économiques de prendre les mesures nécessaires et appropriées pour assurer la gestion sécurisée des données à caractère personnel, afin de prévenir toute fuite, perte ou détérioration. Les lignes directrices de la Commission de protection des données à caractère personnel précisent que ces mesures doivent porter sur les aspects organisationnels, humains, physiques et techniques ; les mesures techniques comprennent notamment la maintenance des logiciels, l'application régulière de correctifs de sécurité et la surveillance des vulnérabilités.

‍

Pourquoi les logiciels en fin de vie posent problème. À l’instar du RGPD, la loi ne mentionne pas explicitement les logiciels en fin de vie, mais les autorités de régulation s’attendent clairement à ce que l’on utilise des logiciels pris en charge et maintenus. Une fuite de données à caractère personnel due à une vulnérabilité connue dans un logiciel qui n’est plus pris en charge est difficilement conciliable avec une gestion de la sécurité « nécessaire et appropriée », et l’obligation de notification des violations (introduite par les amendements de 2022) garantit que de tels incidents soient portés à la connaissance de l’autorité de régulation.

‍

Exemple. Un opérateur japonais de commerce électronique subit une fuite de données due à une version arrivée en fin de vie d'un framework JavaScript utilisé dans son portail de gestion des comptes. La déclaration obligatoire auprès de la PPC donne lieu à un examen minutieux des mesures de sécurité techniques, et le constat principal est que « ce composant n'était plus pris en charge depuis trois ans ».

‍

Recommandations à l'intention des développeurs :

• Considérez les recommandations de la PPC relatives aux mesures de sécurité techniques comme la norme opérationnelle de référence : application régulière des correctifs, surveillance des vulnérabilités et utilisation de logiciels pris en charge pour tout système contenant des données à caractère personnel de personnes résidant au Japon.
• Intégrer les systèmes destinés au marché japonais dans les mêmes accords de niveau de service (SLA) relatifs à l'inventaire du cycle de vie et aux mesures correctives que ceux utilisés pour la conformité aux normes de l'UE et des États-Unis, plutôt que de maintenir une norme distincte et moins stricte.
• Consignez les décisions relatives à la protection des documents sous une forme permettant d'étayer un rapport de violation, car la notification est désormais obligatoire et les questions de suivi sont prévisibles.

‍

Loi sur la cyberdéfense active (Japon, « loi ACD » ou « ACDA »)

S'applique aux : fournisseurs d'infrastructures essentielles désignés en vertu de la loi japonaise sur la promotion de la sécurité économique, ainsi qu'aux fournisseurs de technologies de l'information qui les approvisionnent. Obligatoire. Entrée en vigueur le 16 mai 2025, avec une mise en œuvre progressive qui atteindra sa pleine portée d'ici 2027.

‍

Ce que cela implique. L’ACDA restructure la cyberdéfense du Japon autour de quatre piliers : la collaboration entre les secteurs public et privé, l’utilisation des données de communication pour la détection des menaces, la neutralisation par l’État des infrastructures des attaquants et la réforme organisationnelle. Les fournisseurs désignés sont tenus de signaler les incidents de cybersécurité aux autorités compétentes, une obligation qui entrera en vigueur le 1er octobre 2026 (date non encore officiellement fixée). En cas de vulnérabilités affectant des systèmes critiques, le gouvernement peut en informer les fournisseurs informatiques et le ministre compétent peut demander des mesures correctives ; ces demandes ne sont pas contraignantes, mais les fournisseurs doivent faire des efforts raisonnables pour y répondre. Ce cadre permet également au gouvernement de demander sans délai aux opérateurs de remédier aux vulnérabilités de type « zero-day ».

‍

Pourquoi les logiciels en fin de vie (EOL) constituent un obstacle. L’ACDA établit un canal direct entre les autorités de régulation et les logiciels intégrés aux infrastructures critiques, et les logiciels EOL échouent à ces deux niveaux. La notification préalable permet aux autorités de régulation de connaître la composition des systèmes critiques avant leur déploiement ; ainsi, un framework non pris en charge est identifié dès cette phase d’examen comme une faiblesse documentée. Le mécanisme de remédiation présuppose qu’une correction est possible : lorsque le ministre demande une action corrective concernant une vulnérabilité CVE dans un composant en fin de vie, aucun correctif en amont n’existe, et les « efforts raisonnables » se résument à produire un correctif de manière indépendante ou à admettre qu’aucun ne sera disponible. Le signalement obligatoire des incidents garantit alors qu’une faille due à une vulnérabilité CVE connue dans un logiciel non pris en charge soit portée à la connaissance des autorités dans un délai défini.

‍

Exemple. Un opérateur d'électricité désigné exploite son portail de signalement des pannes sur une .NET en fin de vie. Le NCO identifie l'exploitation active d'une vulnérabilité CVE dans cette .NET et le ministre compétent demande au fournisseur informatique de l'opérateur de prendre des mesures correctives. Il n’existe aucun correctif en amont. Les options qui s’offrent au fournisseur sont une migration d’urgence ou un support étendu commercial permettant de rétablir l’accès à la source du correctif ; la mention « le composant est en fin de vie et ne peut pas être corrigé » est désormais consignée dans le dossier du ministère avant tout futur signalement d’incident.

‍

Recommandations à l'intention des développeurs :

• Si vos systèmes sont au service d'opérateurs d'infrastructures japonais désignés, dressez dès maintenant l'inventaire de tous les frameworks et environnements d'exécution, et remplacez les composants en fin de vie avant que les obligations de notification et de déclaration n'entrent en vigueur en novembre 2026.
• Tenir à jour une source de correctifs pour chaque composant d'un système critique, qu'il s'agisse de correctifs en amont, développés en interne ou issus d'un support étendu commercial, afin de pouvoir répondre rapidement aux demandes de correction émanant des pouvoirs publics.
• Considérez l'ACDA et l'APPI comme des risques complémentaires : l'APPI régit les fuites de données à caractère personnel, tandis que l'ACDA régit les perturbations des services essentiels ; un seul incident survenant dans un système du marché japonais peut déclencher les deux.

‍

Loi SOCI (Australie, loi de 2018 sur la sécurité des infrastructures critiques)

S'applique aux : propriétaires et exploitants d'infrastructures critiques dans 11 secteurs en Australie. Obligatoire.

‍

Ce que cela implique. La loi SOCI et les règles de son programme de gestion des risques liés aux infrastructures critiques (CIRMP) exigent des entités responsables qu’elles identifient les risques significatifs (y compris les menaces cybernétiques et celles liées à la chaîne d’approvisionnement) et qu’elles mettent en œuvre des contrôles visant à les minimiser ou à les atténuer, avec la présentation d’un rapport annuel approuvé par le conseil d’administration. De nombreuses entités satisfont à l’obligation relative au cadre de cybersécurité en adoptant les « Essential Eight » de l’ACSC, dont les niveaux de maturité en matière de correctifs prévoient l’application des correctifs critiques dans des délais courts et définis, et qui considèrent explicitement les logiciels non pris en charge comme une lacune à combler ou à remplacer.

‍

Pourquoi les logiciels en fin de vie (EOL) constituent un problème. Les logiciels EOL ne sont pas mentionnés nommément dans la loi, mais ils relèvent clairement de son champ d'application au titre de l'obligation de gestion des risques : un composant non pris en charge au sein d'un système critique constitue un risque cybernétique significatif nécessitant des contrôles documentés ou des mesures correctives, et les conseils d'administration doivent attester chaque année de l'existence d'un programme permettant d'y remédier.

‍

Exemple. L'application logistique d'un opérateur portuaire australien fonctionne sur une version Node.js en fin de vie (EOL). Le rapport annuel CIRMP, signé par le conseil d'administration, doit décrire les risques significatifs et les mesures d'atténuation. Soit l'environnement d'exécution EOL fait l'objet d'une mesure d'atténuation crédible (calendrier de migration, isolation ou support prolongé avec fourniture de correctifs), soit son omission devient un constat lorsqu'un incident ou un audit la met en évidence.

‍

Recommandations à l'intention des développeurs :

• Aligner les pratiques en matière de correctifs et de gestion du cycle de vie sur le modèle de maturité « Essential Eight », que la plupart des autorités de régulation et des conseils d'administration australiens utilisent comme référence pour définir ce qui est « raisonnable ».
• Intégrer l'exposition liée à la fin de vie des produits (EOL) dans le registre des risques du CIRMP, en proposant des mesures correctives, car l'attestation du conseil d'administration fait des risques techniques non signalés un problème de gouvernance.
• Pour les systèmes liés aux technologies opérationnelles qui ne peuvent véritablement pas être mis à niveau, il convient de documenter explicitement les contrôles de segmentation et de surveillance en tant que mesures de gestion des risques.

‍

Normes mondiales

Contrôles du Center for Internet Security (CIS) v8.1

S'applique à : un cadre de bonnes pratiques volontaire, largement adopté, auquel se réfèrent les autorités de régulation et les assureurs, et obligatoire dans certains contextes contractuels.

‍

Ce que cela implique. Le contrôle n° 2 (Inventaire et contrôle des actifs logiciels) exige des organisations qu’elles gèrent activement l’ensemble de leurs logiciels afin que seuls les logiciels autorisés et pris en charge soient installés et exécutés ; les mesures de protection prévues par le contrôle n° 2 imposent explicitement de s’assurer que les logiciels sont pris en charge et de traiter le cas des logiciels non pris en charge. Le contrôle n° 7 (Gestion continue des vulnérabilités) exige d’évaluer et de suivre en permanence les vulnérabilités, ainsi que de mettre en place des processus de correction selon une cadence définie.

‍

Pourquoi les logiciels en fin de vie posent problème. Le CIS est l'un des rares référentiels à nommer le problème sans détour : les logiciels qui ne bénéficient plus d'un support technique sont considérés comme intrinsèquement vulnérables et doivent être répertoriés comme une exception assortie de mesures d'atténuation, ou bien supprimés. Les organisations qui se réfèrent au CIS (ou dont les clients et assureurs le font) échoueront aux audits internes si elles utilisent ne serait-ce qu'un seul composant en fin de vie non géré.

‍

Exemple. Une entreprise de SaaS de taille moyenne adopte les contrôles CIS pour répondre à des questionnaires sur la sécurité d'entreprise. Son inventaire logiciel « Control 2 » révèle la présence de quatre applications reposant sur des frameworks en fin de vie (EOL). Chacune d'entre elles doit être répertoriée en tant qu'exception documentée, accompagnée de contrôles compensatoires et d'une date de fin de prise en charge, ou bien être transférée vers un statut « pris en charge » ; ne pas les répertorier entraîne l'échec du contrôle et, pire encore, fausse les réponses au questionnaire qui s'appuient sur celui-ci.

‍

Recommandations à l'intention des développeurs :

• Automatiser la gestion de l'inventaire Control 2 à partir des manifestes des paquets et des outils de déploiement, et ajouter un champ « pris en charge jusqu'au » pour chaque framework et chaque environnement d'exécution.
• Définissez des accords de niveau de service (SLA) pour les mesures correctives en fonction du niveau de gravité dans le cadre du contrôle n° 7 et évaluez les résultats par rapport à ces SLA ; ce contrôle exige un processus régulier, et non des mesures correctives ponctuelles.
• Considérez chaque composant en fin de vie (EOL) comme une exception formelle nécessitant une documentation, des mesures d'atténuation et une date d'expiration, conformément à l'objectif de la mesure de contrôle.

‍

Critères SOC 2 relatifs aux services de confiance

S'applique à : une attestation volontaire, mais qui est de fait obligatoire pour les fournisseurs de SaaS et de services cloud B2B, car les entreprises clientes exigent ce rapport par contrat.

‍

Ce que cela implique. Les critères relatifs aux services de confiance (notamment le CC7.1) exigent une veille des nouvelles vulnérabilités, des analyses périodiques, une correction rapide ainsi qu’un processus opérationnel de gestion des correctifs et des changements. Les auditeurs vérifient si les vulnérabilités identifiées au cours de la période d’audit ont été corrigées dans le respect des accords de niveau de service (SLA) définis par l’organisation elle-même et si le processus a fonctionné de manière cohérente.

‍

Pourquoi les logiciels en fin de vie (EOL) posent problème. Un rapport SOC 2 de type II couvre une période de plusieurs mois. Un composant en fin de vie présentant des CVE non corrigées apparaît dans chaque analyse effectuée au cours de cette période, sans qu'aucune correction ne soit possible, ce qui entraîne soit une exception dans le rapport, soit une explication de plus en plus fantaisiste à ce sujet. Les entreprises clientes prennent connaissance de ces exceptions ; une exception liée à la gestion des vulnérabilités dans le rapport d'un fournisseur SaaS constitue autant un problème commercial qu'un problème de sécurité.

‍

Exemple. La période d'audit de type II d'un fournisseur SaaS s'étend de janvier à juin. En février, une vulnérabilité CVE de gravité élevée est publiée concernant un outil open source en fin de vie (EOL) utilisé dans son pipeline de compilation et une Express en fin de vie (EOL) dans un service interne. La politique du fournisseur stipule que les problèmes de gravité élevée doivent être corrigés dans un délai de 30 jours. L’auditeur procède à un échantillonnage de ces tickets en juillet. En l’absence de correctif en amont ou commercial, les tickets sont toujours ouverts au 120e jour, et le rapport est publié avec une exception signalée.

‍

Recommandations à l'intention des développeurs :

• Rédigez des accords de niveau de service (SLA) en matière de remédiation que vous êtes réellement en mesure de respecter, puis respectez-les ; les auditeurs évaluent votre conformité par rapport à votre propre politique, et des politiques ambitieuses dont les délais ne sont pas respectés sont pires que des politiques modestes mais respectées.
• Veillez à ce que chaque composant concerné dispose d'une source de correctifs avant le début de la période d'audit ; tout logiciel en fin de vie découvert en cours de période sera considéré comme un manquement documenté pouvant durer plusieurs mois.
• Veillez à ce que les tickets relatifs aux vulnérabilités soient clairs et complets (date d'identification, niveau de gravité, mesures correctives, preuve de clôture), car ils constituent l'échantillon d'audit.

‍

ISO/IEC 27001:2022

S'applique à : la certification internationale volontaire des systèmes de gestion de la sécurité de l'information, souvent rendue obligatoire par les contrats clients et les exigences en matière d'approvisionnement.

‍

Ce que cela implique. L'annexe A, mesure de contrôle 8.8 (Gestion des vulnérabilités techniques), exige de recueillir en temps opportun des informations sur les vulnérabilités techniques, d'évaluer l'exposition aux risques et de prendre les mesures appropriées. La mesure de contrôle 8.9 (Gestion des configurations) exige de définir, de documenter, de mettre en œuvre et de surveiller les configurations, y compris les modèles de référence pour le matériel et les logiciels. La mesure de contrôle 5.9 exige la réalisation d'un inventaire des informations et des actifs associés.

‍

Pourquoi les logiciels en fin de vie (EOL) constituent un problème. En vertu de la section 8.8, les « mesures appropriées » à prendre face à une vulnérabilité connue dans un composant en fin de vie ne peuvent pas consister à attendre un correctif qui ne viendra pas ; l’organisation doit procéder à une mise à niveau, isoler le composant, atténuer le risque ou rétablir le support, et doit justifier le processus décisionnel. En vertu de la section 8.9, les logiciels en fin de vie (EOL) se situent par définition en dehors de toute base de référence de sécurité défendable, car aucun modèle de renforcement de la sécurité ne peut compenser un composant qui accumule des CVE irréparables. Les audits de certification étant récurrents (audits de surveillance annuels, recertification tous les trois ans), un composant EOL non géré constitue une non-conformité potentielle à chaque visite.

‍

Exemple. Une société de conseil en informatique détient la certification ISO 27001 exigée par ses clients gouvernementaux. Lors d’un audit de surveillance, l’auditeur examine un échantillon des registres de gestion des vulnérabilités et constate des résultats récurrents issus d’un scanner concernant une jQuery en fin de vie (EOL) dans le portail client ; chacun de ces résultats a été clôturé avec la mention « risque accepté », sans mesure d’atténuation, sans responsable et sans date de clôture. L’auditeur signale une non-conformité par rapport à la clause 8.8 : l’acceptation d’un risque sans évaluation, sans traitement ni révision dans un délai défini ne constitue pas une « mesure appropriée ».

‍

Recommandations à l'intention des développeurs :

• Il convient de relier l'inventaire des actifs (5.9), les référentiels de configuration (8.9) et le processus de gestion des vulnérabilités (8.8) de manière à ce que l'état du cycle de vie soit pris en compte dans ces trois éléments ; les auditeurs vérifient en effet de plus en plus souvent les interfaces entre les contrôles.
• Veillez à ce que les acceptations de risques liés aux composants en fin de vie soient assorties d'un délai, attribuées à un responsable et accompagnées de mesures d'atténuation concrètes, et réexaminez-les à intervalles réguliers.
• Intégrer directement les résultats des analyses SCA et EOL dans le processus d'actions correctives du SMSI afin que les preuves d'une identification et d'une réaction « en temps opportun » s'accumulent automatiquement.

‍

Ce que tout cela signifie pour les développeurs : un guide pratique complet

En comparant vingt cadres réglementaires ou normes les uns à côté des autres, la tendance est indéniable. Les délais précis varient (30 jours selon la norme PCI DSS 6.3.3 et les constatations de niveau « élevé » du programme FedRAMP, 14 jours selon les exigences du programme britannique « Cyber Essentials », 24/72 heures pour les déclarations CRA et NIS2), mais les exigences sous-jacentes sont identiques, et toutes relèvent de l'ingénierie :

‍

1. Sachez ce que vous commercialisez et ce que vous exploitez. Les SBOM ne sont plus facultatives. La CRA en fait une obligation légale pour les produits vendus dans l’UE, la norme PCI DSS 6.3.2 exige un inventaire des composants, la directive DORA impose un inventaire des actifs TIC avec suivi de la fin de vie (EOL), et la mesure de contrôle CIS n° 2, la norme ISO 27001 5.9 ainsi que le NIST CSF partent tous du principe qu’il en existe une. Générez des SBOM dans votre infrastructure de continuité (CI), pour chaque version, au format CycloneDX ou SPDX, et veillez à ce qu’elles restent consultables. Lorsque le prochain incident de type Log4Shell se produira, chaque organisme de cette liste s’attendra à ce que vous répondiez en quelques heures aux questions suivantes : « Sommes-nous concernés ? Où ? Et depuis quand ? »

‍

2. Considérez les dates de fin de vie (EOL) comme des échéances de conformité. La date de fin de vie annoncée pour un projet open source correspond à la date à partir de laquelle toute nouvelle vulnérabilité CVE détectée dans ce projet ne pourra plus être corrigée de manière définitive par les voies habituelles. Suivez les échéances de fin de vie de chaque environnement d’exécution, framework et bibliothèque majeure (Node.js, Angular, AngularJS, Vue, les outils React, Express, Nuxt, Bootstrap, jQuery, Drupal, .NET, Spring et le reste de la pile) avec le même sérieux que pour l’expiration des certificats. Lancez une alerte 12 mois à l’avance, planifiez 9 mois avant et agissez avant le jour de la fin de vie.

‍

3. Attribuez à chaque composant exactement l’un des trois statuts suivants : maintenu activement en amont ; maintenu via un contrat de support étendu commercial fournissant des correctifs de sécurité (ce qui répond à la définition de « maintenu » selon la norme NIST CSF PR.PS-02, permet de respecter le délai de 30 jours imposé par la norme PCI et préserve les délais POA&M du programme FedRAMP) ; ou dont le remplacement ou la suppression est prévu à une date fixée. Tout élément ne présentant pas l’un de ces trois statuts constitue une lacune que chaque auditeur, évaluateur et régulateur figurant sur cette liste est formé à détecter.

‍

4. Définissez des accords de niveau de service (SLA) pour la résolution des incidents et mettez-les en œuvre. Intégrez dans le système de suivi des incidents des délais de résolution en fonction du niveau de gravité, mesurez le temps moyen de résolution et conservez les preuves de clôture. Les normes SOC 2, ISO 27001, CMMC et FedRAMP sont toutes, au fond, des exercices de justification : les organisations qui les satisfont sont celles dont le flux de travail technique habituel génère la piste d'audit comme sous-produit.

‍

5. Préparez-vous à des délais de déclaration qui partent du principe que vous disposez déjà de ces informations. L'alerte précoce de 24 heures de l'ARC (à compter du 11 septembre 2026, y compris pour les produits déjà commercialisés), l'alerte d'incident de 24 heures de la NIS2 et le délai de quatre jours ouvrés fixé par la SEC pour les informations significatives supposent tous que vous disposiez, avant l'incident, d'une connaissance de vos systèmes au niveau des composants. Entraînez-vous à suivre le processus : détection, identification des composants via la SBOM, évaluation de l'impact, rédaction de la notification.

‍

6. Signaler par écrit les risques liés au cycle de vie. La directive NIS2 rend les organes de direction personnellement responsables, les règles de la SEC imposent aux conseils d’administration de veiller à la publication des informations de surveillance, et le CIRMP australien exige une attestation du conseil d’administration. Les dirigeants ne peuvent gérer que les risques qu’ils identifient. Une analyse honnête et actualisée de l’exposition à la fin de vie des produits, accompagnée d’options (migration, isolation, prolongation du support), constitue l’un des documents les plus influents qu’une équipe d’ingénieurs puisse produire.

‍

La marche est à sens unique. La mise en œuvre complète de la CRA en décembre 2027, la maturation de l’application de la norme NIS2 dans les États membres, l’intégration progressive de la norme CMMC dans les contrats du ministère américain de la Défense (DoD), la mise en œuvre progressive de la loi canadienne CCSPA après la sanction royale, ainsi que la refonte proposée de la règle de sécurité HIPAA renforcent toutes les trois mêmes exigences : inventaire, correction en temps opportun, processus documenté. Les développeurs qui intègrent dès maintenant la prise en compte du cycle de vie dans leurs pipelines considéreront ces régimes comme une simple formalité administrative. Ceux qui ne le feront pas les vivront comme des situations d’urgence.

‍

Comment Never-Ending Support (NES) de HeroDevs Never-Ending Support (NES) les lacunes en matière de conformité à la fin de vie des produits

NES couvre un portefeuille de frameworks, d'environnements d'exécution et de bibliothèques open source en fin de vie qui représentent une part importante des risques liés à la fin de vie non résolus au sein d'organisations de toutes tailles, notamment AngularJS, Angular, Vue 2, Node.js, Spring, .NET, jQuery, Bootstrap, Express, Nuxt et bien d'autres. NES assure une correction continue des vulnérabilités CVE grâce à un registre privé et sécurisé ainsi qu’à un ensemble complet d’artefacts de conformité : un contrat de support signé, un journal publié des corrections de vulnérabilités CVE, des notes de mise à jour et des versions pouvant être intégrées dans une SBOM.

En se référant aux obligations décrites dans les sections précédentes, NES transforme ce qui est structurellement impossible en une couverture vérifiable :

• Les délais de correction redeviennent respectables. NES rétablit une source de correctifs commerciaux pour les composants dont le développeur en amont ne publiera plus jamais de correctif, ce qui permet de maintenir ces délais dans les limites du raisonnable et de clôturer les incidents.
• « Maintenu » devient une réponse valable. Conformément à la norme NIST CSF 2.0 PR.PS-02, les logiciels doivent être maintenus, remplacés ou supprimés en fonction du niveau de risque. L'application de correctifs fournis par le fournisseur pour un composant en fin de vie (EOL) correspond au résultat « maintenu ». 
• Les systèmes hérités deviennent des systèmes gérés. Les initiatives DORA et NIS2 n'interdisent pas les logiciels hérités ; elles interdisent les logiciels hérités non gérés. Un composant en fin de vie (EOL) couvert par un contrat NES, assorti d'un SLA de correctifs garanti et d'un journal de correction documenté, permet de sécuriser les logiciels hérités et de les maintenir sous support commercial. 
• Les engagements relatifs au cycle de vie des produits deviennent durables. En vertu de la loi sur la cyber-résilience, un fabricant commercialisant des composants open source est légalement tenu de corriger les vulnérabilités de ces derniers pendant toute la durée de la période de support déclarée. NES fournit les correctifs rétroportés qui garantissent la crédibilité de l'engagement de support pour les produits reposant sur des frameworks dont le support en amont a pris fin il y a plusieurs années.

Le NES ne remplace pas la migration lorsque celle-ci constitue la solution appropriée. Il s'agit du mécanisme qui garantit la fiabilité des délais de migration. Une organisation peut s'engager par écrit, auprès de son conseil d'administration, de ses auditeurs et de ses autorités de régulation, à respecter un calendrier de modernisation réaliste, tout en veillant à ce que chaque vulnérabilité (CVE) identifiée soit corrigée dans les délais et de manière documentée.

‍

La fréquence des vulnérabilités détectées par l'IA multiplie les risques liés aux logiciels en fin de vie. Sur le plan opérationnel, le fait de disposer d'un système NES permet à une entreprise utilisant en production des logiciels open source en fin de vie de transformer sa réponse à la question de l'auditeur : ce qui aurait pu constituer une divulgation entraînant une disqualification devient alors un contrôle documenté et défendable.

Pour consulter les dernières actualités technologiques, les notes de mise à jour et la documentation relative aux correctifs CVE, rendez-vous sur herodevs.com et https://docs.herodevs.com/guide/getting-started

‍

‍

Références

1. Conseil des normes de sécurité PCI, Norme de sécurité des données du secteur des cartes de paiement (PCI DSS) v4.0.1, exigences 6.3.1, 6.3.2, 6.3.3 et 11.3.1, juin 2024. https://www.pcisecuritystandards.org/document_library/https://blog.basistheory.com/pci-dss-requirement-6
2. Risk Associates, « Comment la norme PCI DSS v4.0.1 modifie les règles relatives à l'identification et à la correction des vulnérabilités », avril 2026. https://riskassociates.com/blogs/how-pci-dss-v4-0-1-shifts-the-rules-on-identifying-and-fixing-vulnerabilities/
3. Endor Labs (en collaboration avec Schellman), « Le point de vue d'un auditeur sur la gestion des vulnérabilités des logiciels libres dans le cadre de la norme PCI DSS v4 », janvier 2026. https://www.endorlabs.com/learn/an-auditors-perspective-on-addressing-oss-vulnerabilities-for-pci-dss-v4
4. Angular , « Fin du support à long terme pour AngularJS », Google, janvier 2022. angularjs
5. Code des règlements fédéraux des États-Unis, 45 CFR, partie 164, sous-partie C (règle de sécurité HIPAA). https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164
6. Medcurity, Mise à jour 2026 de la règle de sécurité HIPAA : nouvelles exigences auxquelles se préparer (résumé de la lettre d'information de l'OCR de janvier 2026 sur la cybersécurité, consacrée à l'analyse des risques et aux logiciels non mis à jour), juin 2026. https://medcurity.com/hipaa-security-rule-2026-update/
7. Ministère américain de la Santé et des Services sociaux, Bureau des droits civils, Règle de sécurité HIPAA : avis de projet de réglementation visant à renforcer la cybersécurité des informations de santé protégées sous forme électronique. https://www.hhs.gov/hipaa/for-professionals/security/hipaa-security-rule-nprm/index.html
8. Federal Register, « Règle de sécurité HIPAA visant à renforcer la cybersécurité des informations de santé protégées sous forme électronique », 90 FR 898, 6 janvier 2025. https://www.federalregister.gov/public-inspection/2024-30983/health-insurance-portability-and-accountability-act-security-rule-to-strengthen-the-cybersecurity-of
9. Clearwater Security, Application de la règle de sécurité HIPAA : état des lieux en 2026, juillet 2026. https://clearwatersecurity.com/blog/hipaa-security-rule-enforcement-2026/
10. Institut national des normes et de la technologie (NIST), NIST SP 800-53, rév. 5 : Mesures de sécurité et de protection de la vie privée pour les systèmes d'information et les organisations, mesure SI-2 (Correction des failles). https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r5.pdf
11. Guide de surveillance continue FedRAMP. https://www.fedramp.gov/resources/documents/Continuous_Monitoring_Playbook.pdf
12. Institut national des normes et de la technologie (NIST), Cadre de cybersécurité du NIST (CSF) 2.0, NIST CSWP 29, sous-catégorie PR.PS-02, février 2024. https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.29.pdf
13. Bureau de la gestion et du budget des États-Unis, Note de service adressée aux responsables des départements et agences de l'exécutif, M-26-05, 23 janvier 2026. https://www.whitehouse.gov/wp-content/uploads/2026/01/M-26-05-Adopting-a-Risk-based-Approach-to-Software-and-Hardware-Security.pdf
14. Institut national des normes et de la technologie (NIST), NIST SP 800-218 : Cadre de développement logiciel sécurisé (SSDF), version 1.1, pratiques PW.4 et RV.1 à RV.3. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-218.pdf
15. Agence américaine de cybersécurité et de sécurité des infrastructures (CISA), formulaire d'attestation de développement logiciel sécurisé. https://www.cisa.gov/secure-software-attestation-form
16. Federal Register, décret présidentiel n° 14028 : « Améliorer la cybersécurité nationale », 12 mai 2021. https://www.federalregister.gov/documents/2021/05/17/2021-10460/improving-the-nations-cybersecurity
17. Institut national des normes et de la technologie (NIST), NIST SP 800-171, rév. 3 : Protection des informations contrôlées non classifiées dans les systèmes et organisations non fédéraux, exigence 3.14.1. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-171r3.pdf
18. Commission américaine des opérations boursières (SEC), « Gestion des risques liés à la cybersécurité, stratégie, gouvernance et divulgation des incidents », communiqués n° 33-11216 et 34-97989, juillet 2023. https://www.sec.gov/files/rules/final/2023/33-11216.pdf
19. Parlement du Canada, projet de loi C-8 : Loi concernant la cybersécurité, modifiant la Loi sur les télécommunications et apportant des modifications corrélatives à d'autres lois, Lois du Canada 2026, chap. 9, LEGISinfo. https://www.parl.ca/legisinfo/en/bill/45-1/c-8
20. Sécurité publique Canada, le gouvernement du Canada renforce la cybersécurité et la protection des infrastructures essentielles grâce à la sanction royale du projet de loi C-8, juin 2026. https://www.canada.ca/en/public-safety-canada/news/2026/06/government-of-canada-strengthens-cyber-security-and-critical-infrastructure-with-royal-assent-of-bill-c8.html
21. Borden Ladner Gervais LLP, Adoption du projet de loi C-8 : Loi sur la protection des systèmes cybernétiques essentiels, juin 2026. https://www.blg.com/en/insights/2025/07/bill-c-8-revives-canadian-cyber-security-reform-what-critical-infrastructure-sectors-need-to-know
22. Union européenne, règlement (UE) 2022/2554 relatif à la résilience opérationnelle numérique du secteur financier (DORA), articles 5 à 15, EUR-Lex. https://eur-lex.europa.eu/eli/reg/2022/2554/oj
23. Union européenne, Règlement (UE) 2016/679 (Règlement général sur la protection des données), article 32, EUR-Lex. https://eur-lex.europa.eu/eli/reg/2016/679/oj
24. Union européenne, directive (UE) 2022/2555 (directive NIS2), articles 21 et 23, EUR-Lex. https://eur-lex.europa.eu/eli/dir/2022/2555/oj
25. NIS-2-Directive.com, Directive NIS 2, article 21 : Mesures de gestion des risques liés à la cybersécurité (texte intégral de l'article). https://www.nis-2-directive.com/NIS_2_Directive_Article_21.html
26. Glocert International, Explications sur les mesures de gestion des risques prévues à l'article 21 de la directive NIS 2 : les 10 contrôles, décembre 2025. https://www.glocertinternational.com/resources/guides/nis2-article-21-risk-management-measures-explained/
27. Union européenne, règlement (UE) n° 2024/2847 (loi sur la cyber-résilience), article 14 et annexe I, EUR-Lex. https://eur-lex.europa.eu/eli/reg/2024/2847/oj
28. Commission européenne, « La loi sur la cyber-résilience : résumé du texte législatif », Façonner l'avenir numérique de l'Europe. https://digital-strategy.ec.europa.eu/en/policies/cra-summary
29. CyberResilienceAct.eu, « La loi sur la cyber-résilience expliquée : champ d'application, catégories et délais », juin 2026. https://www.cyberresilienceact.eu/explained.html
30. Keysight Technologies, Compte à rebours d'un an avant la mise en conformité avec le règlement CRA de l'UE : le 11 septembre 2026 changera la donne, septembre 2025. https://www.keysight.com/blogs/en/tech/nwvs/2025/09/11/one-year-countdown-to-eu-cra-compliance-september-11-2026-changes-everything
31. Mend (via Security Boulevard), « La loi européenne sur la cyber-résilience : guide complet de mise en conformité pour 2026 et au-delà », mai 2026. https://securityboulevard.com/2026/05/the-eu-cyber-resilience-act-a-complete-compliance-guide-for-2026-and-beyond/
32. Bureau du commissaire à l'information, numéro de référence du dossier INV/0158/2020. https://ico.org.uk/media2/1kip5gw2/chartered-institiute-for-securities-and-investment-reprimand.pdf
33. Bureau du commissaire à l'information, Guide sur la sécurité des données (objectifs de sécurité du RGPD au Royaume-Uni). https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/security/a-guide-to-data-security/
34. Gouvernement britannique, Règlement de 2018 sur les réseaux et les systèmes d'information (SI 2018/506). https://www.legislation.gov.uk/uksi/2018/506/contents
35. Centre national de cybersécurité (Royaume-Uni), Cadre d'évaluation de la cybersécurité (CAF). https://www.ncsc.gov.uk/collection/cyber-assessment-framework
36. Centre national de cybersécurité (Royaume-Uni), Cyber Essentials : Exigences relatives à l'infrastructure informatique (mise à jour requise tous les 14 jours). https://www.ncsc.gov.uk/cyberessentials/overview
37. Commission de protection des données personnelles (Japon), Loi sur la protection des données personnelles (APPI) et lignes directrices de la PPC (ressources en anglais). https://www.ppc.go.jp/en/legal/
38. Japon - Lois et réglementations en matière de cybersécurité 2026. https://iclg.com/practice-areas/cybersecurity-laws-and-regulations/japan
39. La nouvelle loi japonaise sur la cyberdéfense active : conséquences pour les entreprises. https://connectontech.bakermckenzie.com/japans-new-active-cyber-defense-law-impact-on-businesses/
40. Gouvernement australien, loi de 2018 sur la sécurité des infrastructures critiques (y compris les règles relatives au programme de gestion des risques liés aux infrastructures critiques). https://www.legislation.gov.au/C2018A00029/latest
41. Centre australien de cybersécurité, modèle de maturité « Essential Eight » (application des correctifs aux applications et aux systèmes d'exploitation ; suppression des logiciels qui ne bénéficient plus d'un support technique). https://www.cyber.gov.au/resources-business-and-government/essential-cyber-security/essential-eight
42. Center for Internet Security, CIS Critical Security Controls v8.1, contrôle n° 2 (Inventaire et contrôle des actifs logiciels) et contrôle n° 7 (Gestion continue des vulnérabilités). https://www.cisecurity.org/controls
43. AICPA, Critères relatifs aux services fiduciaires (2017, avec points clés révisés en 2022), critère CC7.1. https://www.aicpa-cima.com/resources/download/2017-trust-services-criteria-with-revised-points-of-focus-2022
44. Organisation internationale de normalisation, ISO/IEC 27001:2022 Systèmes de gestion de la sécurité de l'information, annexe A, mesures de contrôle 5.9, 8.8, 8.9. https://www.iso.org/standard/27001
45. CyberResilienceAct.eu, « La loi sur la cyber-résilience expliquée : champ d'application, catégories et délais », juin 2026. https://www.cyberresilienceact.eu/explained.html
46. endoflife.date, Dates de fin de vie des frameworks, des environnements d'exécution et des bases de données (référence gérée par la communauté). https://endoflife.date/
47. Projet Node.js (Fondation OpenJS), versions précédentes et calendrier de fin de vie. https://nodejs.org/en/about/previous-releases
48. Équipe Vue.js, Vue 2 de vie Vue 2 (31 décembre 2023). https://v2.vuejs.org/eol/