Quantifier les risques réels liés aux logiciels open source non pris en charge

L'angle mort du cycle de vie dans l'open source d'entreprise

L'essor fulgurant de l'adoption de l'open source a profondément transformé la manière dont les logiciels d'entreprise sont développés. Selon le rapport 2024 de Synopsys intitulé « Open Source Security and Risk Analysis » (OSSRA), 96 % des bases de code auditées contiennent des composants open source et, dans de nombreux cas, plus de 70 % du code d'une application est open source.

‍

Ce qui est toutefois moins bien compris, c’est la manière dont ces composants sont maintenus au fil du temps — et qui en assume la responsabilité lorsque les projets en amont ne fournissent plus de support. La communauté open source, malgré sa rapidité d’innovation et sa force de collaboration, n’est pas structurée pour offrir des garanties de maintenance à long terme. Les contributeurs et les responsables de maintenance individuels, souvent bénévoles, opèrent avec des ressources limitées et sans obligations contractuelles envers les entreprises qui dépendent de leur travail.

‍

Il en résulte un décalage fondamental. Les entreprises ont besoin que leurs systèmes logiciels restent stables et sécurisés pendant 5 à 10 ans. L'écosystème open source, en revanche, fonctionne selon des cycles de vie plus rapides et plus flexibles, sans obligation de prendre en charge les anciennes versions au-delà d'une date de fin de vie définie.

‍

Comprendre la fin de vie : ce que cela signifie réellement

Lorsqu'un composant OSS atteint la fin de vie déclarée, il entre dans un état où :

• Aucun autre correctif de sécurité ni aucune autre mesure corrective relative aux CVE ne sera publié
• Aucune correction de bogues ni mise à jour de compatibilité n'est fournie
• L'engagement de la communauté, l'activité sur les forums et le suivi des problèmes connaissent une forte baisse
• Les projets peuvent être archivés ou officiellement abandonnés.

Le composant peut continuer à fonctionner d'un point de vue technique, mais les garanties opérationnelles et de sécurité cessent d'être assurées. Cela passe souvent inaperçu auprès des équipes d'ingénieurs concentrées sur la mise en production, jusqu'à ce qu'un audit de conformité, un scan de sécurité ou la divulgation d'une vulnérabilité ne vienne mettre le problème en évidence.

‍

L'impact de l'utilisation de logiciels libres en fin de vie (EOL) n'est pas seulement théorique. Le rapport OSSRA de Synopsys a souligné qu'en 2024, 45 % des applications analysées contenaient au moins un composant open source qui n'était plus activement maintenu. Ces composants sont souvent profondément enfouis dans les arborescences de dépendances, ce qui les rend difficiles à détecter et à remplacer sans une refactorisation importante.

‍

Quatre catégories de risques liés à l'utilisation de logiciels libres non pris en charge

Vulnérabilités de sécurité non corrigées

Les logiciels libres non pris en charge ne peuvent pas être mis à jour par les canaux officiels. Lorsqu'un nouveau CVE est identifié dans un composant en fin de vie, aucun correctif n'est publié en amont. Cela signifie que les vulnérabilités restent non corrigées, indéfiniment.

‍

Dans une étude réalisée en 2023 sur les risques liés à la chaîne d'approvisionnement logicielle, 48 % des vulnérabilités connues dans les environnements d'entreprise ont été attribuées à des bibliothèques open source non maintenues ou en fin de vie (EOL). Ces vulnérabilités sont particulièrement dangereuses car elles sont connues du grand public et facilement exploitables, mais elles restent souvent en production pendant des mois, voire des années, en raison de la complexité de la migration.

‍

Les équipes de sécurité sont confrontées à un choix difficile : appliquer manuellement un correctif à un composant obsolète et assumer la charge de travail technique que cela implique, ou le laisser tel quel et accepter le risque que cela représente. Aucune de ces deux options n'est viable à grande échelle.

‍

Manquements en matière de conformité et d'audit

Les référentiels de conformité modernes (par exemple, SOC 2, ISO 27001, HIPAA, PCI DSS, NIST 800-53) prévoient de plus en plus souvent des exigences imposant aux organisations de démontrer qu'elles utilisent des logiciels sécurisés et bénéficiant d'un support actif. Les composants en fin de vie, par définition, ne répondent pas à ces critères.

‍

Ce risque est devenu plus manifeste au cours des 18 derniers mois, en particulier dans les secteurs soumis à une surveillance réglementaire. Un rapport de la Linux Foundation publié en 2023 a révélé que plus de 70 % des agences fédérales considéraient les composants OSS non pris en charge comme un risque significatif pour leur conformité³.

‍

Les éditeurs de logiciels indépendants sont également concernés. Lors de la mise en place de contrats avec de grandes entreprises ou des administrations publiques, on leur demande systématiquement de fournir une liste des composants logiciels (SBOM) et de vérifier leur statut de prise en charge. La présence de composants en fin de vie peut retarder la conclusion d'un contrat, voire entraîner son annulation.

‍

Fragilité opérationnelle

Les composants logiciels non pris en charge allongent le délai de résolution des incidents lorsqu'ils surviennent. À mesure que le support et la documentation en amont s'amenuisent, des silos de connaissances internes apparaissent. Les équipes d'ingénierie doivent consacrer des ressources à la rétro-ingénierie des correctifs, à la résolution des conflits de dépendances ou à la réécriture des intégrations, ce qui les détourne de leurs objectifs de développement principaux.

‍

De plus, plus une organisation utilise longtemps une version en fin de vie, plus les mises à niveau futures s'avèrent difficiles. Le verrouillage des dépendances et la divergence des contrats d'API introduisent une fragilité dans la pile technologique, augmentant ainsi le risque de défaillances en cascade ou d'interruptions de service pendant la modernisation.

‍

Perturbations stratégiques et opérationnelles

Dans les contextes à enjeux élevés — fusions et acquisitions, processus de diligence raisonnable, renouvellements d'assurances en matière de cybersécurité —, l'utilisation de logiciels open source (OSS) ne bénéficiant plus d'un support technique peut être considérée comme un risque important. Les organisations incapables de fournir des documents prouvant la continuité du support technique se voient souvent attribuer des cotes de risque plus élevées ou subissent des retards dans l'exécution de leurs contrats.

‍

Dans une étude de cas datant de 2023, une entreprise SaaS cherchant à nouer des partenariats avec des grandes entreprises a échoué à un audit de sécurité des fournisseurs en raison de la présence AngularJS Lodash , deux technologies qui avaient atteint leur fin de vie (EOL). Bien que les applications fussent stables, l’équipe de sécurité du client potentiel exigeait l’assurance d’un support actif ou d’une couverture LTS officielle. L’absence de l’un ou de l’autre a retardé la mise en place de 90 jours et entraîné d’importants travaux de correction imprévus.

‍

Pourquoi les mesures d'atténuation traditionnelles échouent-elles ?

Mise à jour immédiate

En théorie, la migration vers la dernière version d'un projet OSS permet d'éliminer ce risque. Dans la pratique, cette approche s'avère souvent irréalisable, notamment lorsque des changements incompatibles sont introduits d'une version à l'autre, ou lorsque les systèmes sont étroitement liés au comportement des versions antérieures.

‍

Des frameworks tels que Spring, Angular et Node.js ont introduit des changements architecturaux majeurs d'une version à l'autre. Ces changements nécessitent des mois de planification, d'assurance qualité et de formation du personnel. Selon une étude Gartner de 2023, plus de 65 % des projets de modernisation logicielle ont dépassé leur budget, et plus de 40 % n'ont pas atteint les objectifs fixés.

‍

Les éditeurs de logiciels indépendants sont également concernés. Lors de la mise en place de contrats avec de grandes entreprises ou des administrations publiques, il est systématiquement demandé aux éditeurs de fournir une liste des composants logiciels (SBOM) et de vérifier leur statut de prise en charge. La présence de composants en fin de vie peut retarder la conclusion d'un contrat, voire entraîner son annulation.

‍

Création de branches et gestion en interne

Certaines équipes tentent de créer des branches dérivées de bibliothèques non prises en charge et d'y appliquer leurs propres correctifs. Si cela peut suffire pour des corrections à court terme, cela entraîne toutefois des contraintes à long terme :

• Les équipes d'ingénieurs sont désormais chargées de recenser les vulnérabilités et de développer des correctifs
• L'intégration avec des outils externes (par exemple, des scanners, des pipelines de CD) se détériore
• Les connaissances sont concentrées entre les mains de quelques membres de l'équipe, ce qui engendre un risque lié aux personnes clés

La création d'une branche accentue également la divergence par rapport à la version communautaire, ce qui complique toute migration ou tout rebase ultérieur.

‍

Accepter le risque

La troisième approche (et la plus courante) est celle de l'acceptation passive. Les équipes continuent d'utiliser des logiciels en fin de vie, souvent sans en mesurer pleinement les implications, jusqu'à ce qu'un événement déclencheur survienne : un échec d'audit, une faille de sécurité ou un conflit de dépendances qui bloque le développement.

‍

Cette attitude réactive a un coût élevé, tant sur le plan opérationnel qu'en termes de réputation. Le coût financier lié à la correction d'une vulnérabilité connue mais non traitée est généralement 4 à 6 fois plus élevé après un incident que lors d'une mise à niveau planifiée ou d'une intervention de support.

‍

Le rôle de l'accompagnement commercial à long terme

Le support à long terme (LTS) proposé par un partenaire commercial offre une alternative structurée à ces solutions insuffisantes. Cette approche garantit une couverture de sécurité durable et une atténuation des risques pour les composants OSS qui ne sont plus pris en charge par leurs auteurs d'origine ou leurs fondations.

‍

Chez HeroDevs, c'est ce que nous appelons le « soutien sans fin ».

‍

Notre modèle propose :

• Application de correctifs de sécurité couverte par un contrat SLA pour les versions de logiciels libres en fin de vie (EOL)
• Surveillance et gestion continues des vulnérabilités
• Documentation de niveau audit, y compris l'historique des correctifs et les rapports de conformité
• Mises à jour préservant la compatibilité, testées dans votre environnement
• Calendriers de prise en charge spécifiques à chaque version, permettant une modernisation planifiée

Cela permet aux organisations de conserver leur version actuelle tout en garantissant la conformité, l'intégrité de la sécurité et la rapidité de développement.

‍

Les avantages stratégiques d'un accompagnement continu

Les organisations qui adoptent une version LTS commerciale bénéficient des avantages suivants :

• Une pression moindre en matière de mises à jour, ce qui leur permet de moderniser leur système selon leur propre calendrier, et non celui de la communauté
• Meilleure préparation aux audits, avec une couverture des correctifs documentée et des références aux accords de niveau de service (SLA)
• Réduction du risque de violation de sécurité grâce à la correction proactive des vulnérabilités (CVE)
• Une meilleure efficacité technique, grâce à la suppression des travaux de mise à niveau imprévus
• Prévisibilité financière, par rapport aux budgets de migration s'étalant sur plusieurs trimestres

Ces avantages sont particulièrement évidents dans les environnements complexes comportant de nombreuses applications ou un parc de systèmes hérités important.

‍

La fin de vie d'un produit constitue un risque commercial, et pas seulement un risque technique

Le recours généralisé aux logiciels libres a dépassé la capacité de la plupart des organisations à les gérer de manière responsable. À mesure que les projets de logiciels libres arrivent en fin de vie, l'absence de structures de support officielles engendre des risques cachés et croissants en matière de sécurité, de conformité et d'exploitation.

‍

HeroDevs vous ouvre la voie. Notre programme « Never-Ending Support » aide les équipes d'ingénierie, de sécurité et de conformité à garder le contrôle de leurs environnements OSS bien après la fin du support officiel.

‍

Dans un monde où tous les systèmes reposent sur l'open source, la capacité à étendre la prise en charge des composants critiques n'est plus un simple avantage, mais un impératif stratégique.

‍

À propos de HeroDevs

HeroDevs propose une assistance de niveau professionnel, assortie d'un accord de niveau de service (SLA), pour les logiciels open source en fin de vie. Notre offre « Never-Ending Support » aide les entreprises à sécuriser, maintenir et documenter leurs environnements OSS hérités. Nous accompagnons des clients issus de divers secteurs, notamment la finance, la santé, les infrastructures et les logiciels.

‍

Pour plus d'informations, rendez-vous sur herodevs.com ou contactez-nous à l'adresse support@herodevs.com.

‍

Références

1. Synopsys. Rapport 2024 sur la sécurité et l'analyse des risques liés à l'open source.
2. Forrester. Sécuriser la chaîne d'approvisionnement logicielle. 2023.
3. Linux Foundation. L'état des lieux de l'open source dans la fonction publique. 2023.
4. Gartner. Enquête sur les tendances en matière de modernisation des logiciels. 2023.