{"id":22905,"date":"2025-06-24T11:08:13","date_gmt":"2025-06-24T09:08:13","guid":{"rendered":"https:\/\/www.kaspersky.fr\/blog\/?p=22905"},"modified":"2025-06-24T11:08:13","modified_gmt":"2025-06-24T09:08:13","slug":"can-you-support-open-source-preliminary-assessment","status":"publish","type":"post","link":"https:\/\/www.kaspersky.fr\/blog\/can-you-support-open-source-preliminary-assessment\/22905\/","title":{"rendered":"Comment choisir des solutions open-source pour votre entreprise ?"},"content":{"rendered":"

Selon le rapport State of Open Source 2025<\/a>, 96\u00a0% des entreprises interrog\u00e9es utilisent des applications \u00e0 code source ouvert. Leur vaste choix, leurs nombreuses options de personnalisation et leurs co\u00fbts de licence inexistants sont des atouts tr\u00e8s int\u00e9ressants. Cependant, plus de la moiti\u00e9 des entreprises sond\u00e9es sont confront\u00e9es \u00e0 des d\u00e9fis de taille pour assurer la maintenance continue des applications \u00e0 code source ouvert. Un taux stup\u00e9fiant de 63\u00a0% \u00e9prouve des difficult\u00e9s \u00e0 maintenir les solutions \u00e0 jour et \u00e0 appliquer les correctifs. Suivent de pr\u00e8s les probl\u00e8mes de cybers\u00e9curit\u00e9, de conformit\u00e9 r\u00e9glementaire et la pr\u00e9sence d\u2019applications \u00e0 code source ouvert en fin de vie, autrement dit qui ne sont plus prises en charge. Alors, comment pouvez-vous minimiser la probabilit\u00e9 de ces probl\u00e8mes et \u00e0 quoi devez-vous pr\u00eater attention lors de la s\u00e9lection d\u2019un logiciel \u00e0 code source ouvert (OSS)\u00a0?<\/p>\n

Mises \u00e0 jour et correctifs<\/h2>\n

\u00c9tant donn\u00e9 que la mise \u00e0 jour r\u00e9guli\u00e8re des logiciels \u00e0 code source ouvert est le probl\u00e8me le plus r\u00e9pandu, il convient d\u2019examiner tr\u00e8s attentivement, sous cet angle, les candidats potentiels. Il est facile de v\u00e9rifier la fr\u00e9quence et l\u2019\u00e9tendue des mises \u00e0 jour, ainsi que leur contenu, directement dans le stockage public de l\u2019application. Pr\u00eatez attention \u00e0 la qualit\u00e9 de la documentation des mises \u00e0 jour, aux types de probl\u00e8mes qu\u2019elles r\u00e9solvent, aux nouvelles fonctionnalit\u00e9s qu\u2019elles ajoutent, \u00e0 la fr\u00e9quence \u00e0 laquelle des correctifs mineurs sont publi\u00e9s quelques jours ou semaines apr\u00e8s une version majeure et \u00e0 la rapidit\u00e9 avec laquelle les demandes de correction de bugs sont trait\u00e9es.<\/p>\n

Des outils standards comme Git Insights<\/a>, ainsi que des services compl\u00e9mentaires comme Is it maintained?<\/a>, Repology<\/a> et Libraries.io<\/a>, peuvent apporter des r\u00e9ponses \u00e0 ces questions. Le service Libraries.io indique imm\u00e9diatement les d\u00e9pendances obsol\u00e8tes utilis\u00e9es par la version existante.<\/p>\n

Accordez une attention particuli\u00e8re aux mises \u00e0 jour relatives \u00e0 la s\u00e9curit\u00e9. Sont-elles publi\u00e9es s\u00e9par\u00e9ment ou sont-elles regroup\u00e9es avec les mises \u00e0 jour de fonctionnalit\u00e9s\u00a0? En g\u00e9n\u00e9ral, les d\u00e9veloppeurs choisissent la deuxi\u00e8me option. Dans ce cas, vous devez comprendre depuis combien de temps les mises \u00e0 jour de s\u00e9curit\u00e9 attendent d\u2019\u00eatre publi\u00e9es.<\/p>\n

\u00c9valuez \u00e9galement la complexit\u00e9 du processus d\u2019installation des mises \u00e0 jour. La documentation et l\u2019assistance officielles sont utiles pour commencer, mais elles restent insuffisantes. Il est probablement plus utile de passer attentivement en revue les commentaires de la communaut\u00e9 des utilisateurs.<\/p>\n

Toutes ces informations vous aideront \u00e0 comprendre les efforts qui seront n\u00e9cessaires pour assurer la maintenance du produit. Vous aurez besoin d\u2019allouer des ressources internes pour la gestion. Il ne suffit pas d\u2019attribuer des responsabilit\u00e9s. Il faudra consacrer des heures de travail \u00e0 ces t\u00e2ches et \u00e0 d\u2019autres t\u00e2ches connexes.<\/p>\n

Vuln\u00e9rabilit\u00e9s<\/h2>\n

Pour anticiper avec pr\u00e9cision la fr\u00e9quence des probl\u00e8mes de cybers\u00e9curit\u00e9, il est pr\u00e9f\u00e9rable d\u2019\u00e9valuer d\u00e8s le d\u00e9part la culture d\u2019ing\u00e9nierie et l\u2019hygi\u00e8ne de cybers\u00e9curit\u00e9 du produit. Bien que cette d\u00e9marche puisse \u00eatre laborieuse, vous pouvez utiliser des outils automatis\u00e9s pour effectuer une premi\u00e8re analyse de haut niveau.<\/p>\n

Pour les produits et paquets populaires, une approche int\u00e9ressante consiste \u00e0 v\u00e9rifier les r\u00e9sultats d\u2019\u00e9valuations heuristiques d\u00e9j\u00e0 existantes \u00e0 l\u2019aide d\u2019outils comme OpenSSF Scorecard<\/a>. Cet outil fournit diverses donn\u00e9es sur l\u2019hygi\u00e8ne de cybers\u00e9curit\u00e9, allant du nombre de vuln\u00e9rabilit\u00e9s non corrig\u00e9es et de la pr\u00e9sence de strat\u00e9gies de s\u00e9curit\u00e9 \u00e0 l\u2019utilisation du fuzzing et de l\u2019\u00e9pinglage des d\u00e9pendances.<\/p>\n

Examinez \u00e9galement les bases de donn\u00e9es publiques li\u00e9es aux vuln\u00e9rabilit\u00e9s, comme NVD<\/a> et les avis GitHub<\/a>, pour d\u00e9terminer combien de failles ont \u00e9t\u00e9 d\u00e9couvertes dans le cadre du projet, leur degr\u00e9 de gravit\u00e9 et la rapidit\u00e9 avec laquelle elles ont \u00e9t\u00e9 corrig\u00e9es. Un nombre \u00e9lev\u00e9 de vuln\u00e9rabilit\u00e9s en soi peut t\u00e9moigner de la popularit\u00e9 d\u2019un projet plut\u00f4t que de mauvaises pratiques de d\u00e9veloppement. Toutefois, ce qui importe vraiment, ce sont les types de probl\u00e8mes et la mani\u00e8re dont les d\u00e9veloppeurs y ont r\u00e9agi.<\/p>\n

D\u00e9pendances et cha\u00eene d\u2019approvisionnement<\/h2>\n

Presque tous les projets de logiciels \u00e0 code source ouvert s\u2019appuient sur des modules tiers \u00e0 code source ouvert, qui ne sont souvent pas document\u00e9s. Ces modules sont mis \u00e0 jour individuellement et peuvent contenir des bugs, des vuln\u00e9rabilit\u00e9s, voire du code malveillant. Le point essentiel est de comprendre \u00e0 quelle vitesse les mises \u00e0 jour des modules sont int\u00e9gr\u00e9es dans le projet en question.<\/p>\n

Pour l\u2019\u00e9valuer, vous aurez besoin d\u2019outils SBOM (nomenclature logicielle) ou SCA (analyse de la composition logicielle). Les solutions \u00e0 code source ouvert disponibles, comme OWASP Dependency-Check<\/a> ou Syft<\/a>, peuvent \u00e9tablir l\u2019arbre des d\u00e9pendances d\u2019un projet, mais elles sont g\u00e9n\u00e9ralement con\u00e7ues pour des projets d\u00e9j\u00e0 en fonctionnement, d\u00e9ploy\u00e9s dans vos propres stockages ou images de conteneurs. Par cons\u00e9quent, il est pr\u00e9f\u00e9rable d\u2019effectuer une analyse approfondie des d\u00e9pendances sur un produit qui a d\u00e9j\u00e0 \u00e9t\u00e9 soumis \u00e0 une \u00e9valuation pr\u00e9liminaire et qui est un candidat s\u00e9rieux pour \u00eatre int\u00e9gr\u00e9 dans votre infrastructure.<\/p>\n

Examinez attentivement la liste des d\u00e9pendances pour d\u00e9terminer si elles proviennent de stockages fiables et bien contr\u00f4l\u00e9s, si elles sont populaires et si elles disposent de signatures num\u00e9riques. Il s\u2019agit essentiellement d\u2019\u00e9valuer les risques de compromission.<\/p>\n

Bien qu\u2019il soit th\u00e9oriquement possible de v\u00e9rifier manuellement les vuln\u00e9rabilit\u00e9s dans les d\u00e9pendances, si un logiciel \u00e0 code source ouvert est d\u00e9j\u00e0 d\u00e9ploy\u00e9 dans un environnement de test, il est beaucoup plus simple d\u2019utiliser des outils tels que Grype<\/a>.<\/p>\n

Un d\u00e9fi majeur souvent n\u00e9glig\u00e9\u00a0: le suivi des mises \u00e0 jour. En th\u00e9orie, chaque mise \u00e0 jour de d\u00e9pendance pour un projet devrait \u00eatre rev\u00e9rifi\u00e9e. Dans la pratique, cette v\u00e9rification n\u2019est possible qu\u2019avec des scanners automatis\u00e9s, car les autres approches sont tout simplement trop co\u00fbteuses.<\/p>\n

Si un projet utilise des d\u00e9pendances obsol\u00e8tes et n\u2019est g\u00e9n\u00e9ralement pas optimal du point de vue de la cybers\u00e9curit\u00e9, il est \u00e9videmment pr\u00e9f\u00e9rable de chercher une alternative. Mais qu\u2019en est-il si l\u2019entreprise choisit une solution particuli\u00e8re en raison de ses fonctionnalit\u00e9s de base\u00a0? La r\u00e9ponse est toujours la m\u00eame\u00a0: effectuer une analyse des risques plus approfondie, mettre au point des contr\u00f4les compensatoires et, surtout, allouer des ressources importantes \u00e0 une maintenance continue. \u00c9tant donn\u00e9 que les ressources internes sont souvent insuffisantes, il est judicieux d\u2019\u00e9valuer d\u00e8s le d\u00e9part les modalit\u00e9s d\u2019assistance technique professionnelle pour chaque produit.<\/p>\n

Respect des exigences internes et r\u00e9glementaires<\/h2>\n

Si les strat\u00e9gies r\u00e9glementaires qui s\u2019appliquent \u00e0 votre entreprise couvrent le logiciel que vous avez choisi et les donn\u00e9es qu\u2019il contient, \u00e9laborez imm\u00e9diatement un plan pour les audits de conformit\u00e9. Les tr\u00e8s grandes applications \u00e0 code source ouvert de niveau entreprise sont parfois accompagn\u00e9es d\u2019une documentation qui peut simplifier certains types d\u2019audits. Si ce n\u2019est pas le cas, vous devrez tout d\u00e9velopper vous-m\u00eame, ce qui implique encore une fois d\u2019y consacrer beaucoup de temps et de ressources.<\/p>\n

Presque tous les logiciels, dans tous les secteurs d\u2019activit\u00e9, devront faire l\u2019objet d\u2019un audit de conformit\u00e9 des licences. Certains modules et certaines applications \u00e0 code source ouvert sont distribu\u00e9s sous des licences restrictives, comme la licence AGPL<\/a>, qui limitent les possibilit\u00e9s de distribution et d\u2019utilisation d\u2019un logiciel. Gr\u00e2ce \u00e0 l\u2019analyse SBOM\/SCA, il est possible de dresser l\u2019inventaire de toutes les licences de votre logiciel et de ses d\u00e9pendances, puis de v\u00e9rifier que votre cas d\u2019utilisation n\u2019enfreint aucune d\u2019entre elles. Ces processus peuvent \u00eatre en grande partie automatis\u00e9s \u00e0 l\u2019aide d\u2019outils sp\u00e9cialis\u00e9s comme le logiciel \u00e0 code source ouvert Review Toolkit<\/a>, mais l\u2019automatisation n\u00e9cessitera des strat\u00e9gies claires et des d\u00e9marches de la part de votre \u00e9quipe de d\u00e9veloppement.<\/p>\n

Co\u00fbts li\u00e9s \u00e0 la gestion<\/h2>\n

Apr\u00e8s avoir analys\u00e9 tous ces aspects, vous devriez disposer d\u2019une id\u00e9e claire qui vous permettra de comparer les diff\u00e9rentes approches de gestion des applications. Pour la gestion par une \u00e9quipe interne, il faut pr\u00e9voir des heures de travail de sp\u00e9cialistes. Si votre \u00e9quipe ne dispose pas de l\u2019expertise n\u00e9cessaire, il vous faudra embaucher quelqu\u2019un. Les principaux responsables de la gestion et de la s\u00e9curit\u00e9 des logiciels \u00e0 code source ouvert devront \u00e9galement disposer de temps et d\u2019un budget pour assurer une formation professionnelle continue permanente.<\/p>\n

Si les ressources de votre \u00e9quipe interne sont insuffisantes pour assurer la gestion (en raison d\u2019un personnel ou d\u2019une expertise limit\u00e9s), il existe au moins deux types d\u2019assistances techniques professionnelles externalis\u00e9es\u00a0: les entreprises comme Red Hat, qui se sp\u00e9cialisent dans la gestion des applications, et les fournisseurs d\u2019h\u00e9bergement g\u00e9r\u00e9, pour des applications particuli\u00e8res (Clusters Kube, MongoDB Atlas, et autres).<\/p>\n

Au-del\u00e0 du temps et de l\u2019expertise, le co\u00fbt et la complexit\u00e9 de l\u2019assistance technique sont \u00e9galement d\u00e9termin\u00e9s par l\u2019\u00e9tat de pr\u00e9paration g\u00e9n\u00e9ral de l\u2019organisation \u00e0 l\u2019adoption g\u00e9n\u00e9ralis\u00e9e du code source ouvert\u00a0:<\/p>\n