Comment choisir des solutions open-source pour votre entreprise ?

Selon le rapport State of Open Source 2025, 96 % des entreprises interrogées utilisent des applications à code source ouvert. Leur vaste choix, leurs nombreuses options de personnalisation et leurs coûts de licence inexistants sont des atouts très intéressants. Cependant, plus de la moitié des entreprises sondées sont confrontées à des défis de taille pour assurer la maintenance continue des applications à code source ouvert. Un taux stupéfiant de 63 % éprouve des difficultés à maintenir les solutions à jour et à appliquer les correctifs. Suivent de près les problèmes de cybersécurité, de conformité réglementaire et la présence d’applications à code source ouvert en fin de vie, autrement dit qui ne sont plus prises en charge. Alors, comment pouvez-vous minimiser la probabilité de ces problèmes et à quoi devez-vous prêter attention lors de la sélection d’un logiciel à code source ouvert (OSS) ?

Mises à jour et correctifs

Étant donné que la mise à jour régulière des logiciels à code source ouvert est le problème le plus répandu, il convient d’examiner très attentivement, sous cet angle, les candidats potentiels. Il est facile de vérifier la fréquence et l’étendue des mises à jour, ainsi que leur contenu, directement dans le stockage public de l’application. Prêtez attention à la qualité de la documentation des mises à jour, aux types de problèmes qu’elles résolvent, aux nouvelles fonctionnalités qu’elles ajoutent, à la fréquence à laquelle des correctifs mineurs sont publiés quelques jours ou semaines après une version majeure et à la rapidité avec laquelle les demandes de correction de bugs sont traitées.

Des outils standards comme Git Insights, ainsi que des services complémentaires comme Is it maintained?, Repology et Libraries.io, peuvent apporter des réponses à ces questions. Le service Libraries.io indique immédiatement les dépendances obsolètes utilisées par la version existante.

Accordez une attention particulière aux mises à jour relatives à la sécurité. Sont-elles publiées séparément ou sont-elles regroupées avec les mises à jour de fonctionnalités ? En général, les développeurs choisissent la deuxième option. Dans ce cas, vous devez comprendre depuis combien de temps les mises à jour de sécurité attendent d’être publiées.

Évaluez également la complexité du processus d’installation des mises à jour. La documentation et l’assistance officielles sont utiles pour commencer, mais elles restent insuffisantes. Il est probablement plus utile de passer attentivement en revue les commentaires de la communauté des utilisateurs.

Toutes ces informations vous aideront à comprendre les efforts qui seront nécessaires pour assurer la maintenance du produit. Vous aurez besoin d’allouer des ressources internes pour la gestion. Il ne suffit pas d’attribuer des responsabilités. Il faudra consacrer des heures de travail à ces tâches et à d’autres tâches connexes.

Vulnérabilités

Pour anticiper avec précision la fréquence des problèmes de cybersécurité, il est préférable d’évaluer dès le départ la culture d’ingénierie et l’hygiène de cybersécurité du produit. Bien que cette démarche puisse être laborieuse, vous pouvez utiliser des outils automatisés pour effectuer une première analyse de haut niveau.

Pour les produits et paquets populaires, une approche intéressante consiste à vérifier les résultats d’évaluations heuristiques déjà existantes à l’aide d’outils comme OpenSSF Scorecard. Cet outil fournit diverses données sur l’hygiène de cybersécurité, allant du nombre de vulnérabilités non corrigées et de la présence de stratégies de sécurité à l’utilisation du fuzzing et de l’épinglage des dépendances.

Examinez également les bases de données publiques liées aux vulnérabilités, comme NVD et les avis GitHub, pour déterminer combien de failles ont été découvertes dans le cadre du projet, leur degré de gravité et la rapidité avec laquelle elles ont été corrigées. Un nombre élevé de vulnérabilités en soi peut témoigner de la popularité d’un projet plutôt que de mauvaises pratiques de développement. Toutefois, ce qui importe vraiment, ce sont les types de problèmes et la manière dont les développeurs y ont réagi.

Dépendances et chaîne d’approvisionnement

Presque tous les projets de logiciels à code source ouvert s’appuient sur des modules tiers à code source ouvert, qui ne sont souvent pas documentés. Ces modules sont mis à jour individuellement et peuvent contenir des bugs, des vulnérabilités, voire du code malveillant. Le point essentiel est de comprendre à quelle vitesse les mises à jour des modules sont intégrées dans le projet en question.

Pour l’évaluer, vous aurez besoin d’outils SBOM (nomenclature logicielle) ou SCA (analyse de la composition logicielle). Les solutions à code source ouvert disponibles, comme OWASP Dependency-Check ou Syft, peuvent établir l’arbre des dépendances d’un projet, mais elles sont généralement conçues pour des projets déjà en fonctionnement, déployés dans vos propres stockages ou images de conteneurs. Par conséquent, il est préférable d’effectuer une analyse approfondie des dépendances sur un produit qui a déjà été soumis à une évaluation préliminaire et qui est un candidat sérieux pour être intégré dans votre infrastructure.

Examinez attentivement la liste des dépendances pour déterminer si elles proviennent de stockages fiables et bien contrôlés, si elles sont populaires et si elles disposent de signatures numériques. Il s’agit essentiellement d’évaluer les risques de compromission.

Bien qu’il soit théoriquement possible de vérifier manuellement les vulnérabilités dans les dépendances, si un logiciel à code source ouvert est déjà déployé dans un environnement de test, il est beaucoup plus simple d’utiliser des outils tels que Grype.

Un défi majeur souvent négligé : le suivi des mises à jour. En théorie, chaque mise à jour de dépendance pour un projet devrait être revérifiée. Dans la pratique, cette vérification n’est possible qu’avec des scanners automatisés, car les autres approches sont tout simplement trop coûteuses.

Si un projet utilise des dépendances obsolètes et n’est généralement pas optimal du point de vue de la cybersécurité, il est évidemment préférable de chercher une alternative. Mais qu’en est-il si l’entreprise choisit une solution particulière en raison de ses fonctionnalités de base ? La réponse est toujours la même : effectuer une analyse des risques plus approfondie, mettre au point des contrôles compensatoires et, surtout, allouer des ressources importantes à une maintenance continue. Étant donné que les ressources internes sont souvent insuffisantes, il est judicieux d’évaluer dès le départ les modalités d’assistance technique professionnelle pour chaque produit.

Respect des exigences internes et réglementaires

Si les stratégies réglementaires qui s’appliquent à votre entreprise couvrent le logiciel que vous avez choisi et les données qu’il contient, élaborez immédiatement un plan pour les audits de conformité. Les très grandes applications à code source ouvert de niveau entreprise sont parfois accompagnées d’une documentation qui peut simplifier certains types d’audits. Si ce n’est pas le cas, vous devrez tout développer vous-même, ce qui implique encore une fois d’y consacrer beaucoup de temps et de ressources.

Presque tous les logiciels, dans tous les secteurs d’activité, devront faire l’objet d’un audit de conformité des licences. Certains modules et certaines applications à code source ouvert sont distribués sous des licences restrictives, comme la licence AGPL, qui limitent les possibilités de distribution et d’utilisation d’un logiciel. Grâce à l’analyse SBOM/SCA, il est possible de dresser l’inventaire de toutes les licences de votre logiciel et de ses dépendances, puis de vérifier que votre cas d’utilisation n’enfreint aucune d’entre elles. Ces processus peuvent être en grande partie automatisés à l’aide d’outils spécialisés comme le logiciel à code source ouvert Review Toolkit, mais l’automatisation nécessitera des stratégies claires et des démarches de la part de votre équipe de développement.

Coûts liés à la gestion

Après avoir analysé tous ces aspects, vous devriez disposer d’une idée claire qui vous permettra de comparer les différentes approches de gestion des applications. Pour la gestion par une équipe interne, il faut prévoir des heures de travail de spécialistes. Si votre équipe ne dispose pas de l’expertise nécessaire, il vous faudra embaucher quelqu’un. Les principaux responsables de la gestion et de la sécurité des logiciels à code source ouvert devront également disposer de temps et d’un budget pour assurer une formation professionnelle continue permanente.

Si les ressources de votre équipe interne sont insuffisantes pour assurer la gestion (en raison d’un personnel ou d’une expertise limités), il existe au moins deux types d’assistances techniques professionnelles externalisées : les entreprises comme Red Hat, qui se spécialisent dans la gestion des applications, et les fournisseurs d’hébergement géré, pour des applications particulières (Clusters Kube, MongoDB Atlas, et autres).

Au-delà du temps et de l’expertise, le coût et la complexité de l’assistance technique sont également déterminés par l’état de préparation général de l’organisation à l’adoption généralisée du code source ouvert :

• Votre équipe de cybersécurité dispose-t-elle d’analyseurs de vulnérabilité et d’outils de gestion des risques adaptés aux logiciels à code source ouvert ?
• Vos outils de suivi et de surveillance des ressources informatiques prennent-ils en charge les projets et les modules de logiciels à code source ouvert ?
• Pour les équipes de développement internes, les processus d’analyse des images, des stockages et d’autres sources de code sont-ils inclus dans votre pipeline CI/CD ? Des solutions de sécurité spécialisées, comme Kaspersky Hybrid Cloud Security, peuvent automatiser cet aspect.
• Votre entreprise a-t-elle élaboré une stratégie régissant l’utilisation des logiciels à code source ouvert et a-t-elle défini clairement qui prend les décisions et qui est responsable des questions opérationnelles ?

Enfin, il est essentiel de prendre en compte le large éventail des risques liés aux logiciels à code source ouvert, notamment l’interruption soudaine d’un projet, la prolifération de dépendances mineures et d’autres risques liés à la chaîne d’approvisionnement.