Les composants open source ne sont pas suffisamment mis à jour dans les apps réseau
Les failles découvertes et corrigées par les équipes de projet open-source dans le code open-source des logiciels réseau commerciaux ne seront pas forcément adoptées dans les éditeurs. D'où l'intérêt de conférer contractuellement au fournisseur de service la responsabilité de l'analyse de la sécurité et de la résolution des problèmes.
Á bien des égards, l'arrivée permanente de logiciels open source (Open Source Software, OSS) dans les services IT des entreprises est une formidable aubaine, tant pour les fournisseurs que pour les utilisateurs. Pour les premiers, la possibilité d'utiliser des composants open source permet d'éviter beaucoup de travail redondant. Ainsi, au lieu d'avoir à concevoir chaque partie d'un produit de surveillance et de capteurs IoT à partir de zéro, le fournisseur pourra par exemple adopter une bibliothèque open source bien comprise et bien supportée pour sa pile réseau, et se concentrer davantage sur les fonctions de détection et d'analyse des données qui différencieront son produit de celui de ses concurrents. Pour les utilisateurs finaux, l'un des principaux avantages est - du moins en théorie - l'amélioration de la sécurité, argument habituel pour l'adoption des logiciels open source. L'idée étant que la nature ouverte d'un logiciel - et le fait que tout le monde puisse l'examiner pour y découvrir et en corriger les failles de sécurité - implique qu'il sera généralement plus sûr que son équivalent propriétaire.
Mais, selon Mark Driver, vice-président de la recherche chez Gartner, cette affirmation n'est que partiellement vraie. Et il avance à ce sujet un point de vue inverse : le caractère open source peut nuire aux logiciels, en permettant à de mauvais acteurs d'ajouter des éléments au code principal. « La réalité se situe quelque part entre les deux, à savoir que les logiciels libres ne sont ni plus ni moins sûrs que les logiciels propriétaires », a-t-il ajouté. « Tout dépend de la façon dont est géré le projet ». La théorie selon laquelle les logiciels libres sont plus sûrs est valable, mais, en pratique, tout dépend de l'activité et de l'habileté d'un ensemble donné de contributeurs qui travaillent sur un projet particulier. Selon Dimitrios Pavlakis, analyste principal pour l'IoT et la cybersécurité chez ABI Research, il y a parfois une disparité entre les efforts de chasse aux bugs de la part des équipes de projets open source et le décorticage minutieux de ce même code par les mauvais acteurs. « Pour les communautés open source, la chasse aux bugs est un passe-temps, alors que pour les attaquants, c'est un moyen de gagner leur vie », a-t-il déclaré.
Maintenance difficile
Il est donc essentiel que les entreprises qui utilisent des logiciels comportant des composants open source s'interrogent sur la qualité du support de ces composants. Certains projets open source ne bénéficient pas de support professionnel, ce qui signifie que les personnes chargées de leur maintenance - si tant est que le code est maintenu - effectuent ce travail pendant leur temps libre. Et même si ces projets sont activement maintenus, il n'est pas garanti que les fournisseurs qui utilisent le code dans leurs logiciels commerciaux appliquent les correctifs en temps voulu. « Le problème le plus répandu avec les logiciels libres concerne l'insuffisance de gestion des actifs libres », a encore déclaré M. Driver. Les problèmes de sécurité peuvent être corrigés par les équipes de logiciels libres, mais cela ne signifie pas que le code est corrigé dans les produits qui l'incorporent. « Les gens le téléchargeront et l'utiliseront, mais ne reviendront pas en arrière pour vérifier les correctifs », a-t-il ajouté.
Que peut donc faire une entreprise responsable face aux vulnérabilités potentielles des logiciels libres dans ses piles logicielles ? Une partie de la réponse à cette question est technologique. Un logiciel capable d'analyser automatiquement une pile donnée pour y rechercher des composants open source et la comparer aux vulnérabilités CVE connues peut grandement aider les entreprises soucieuses de leur protection. Des fournisseurs comme Checkmarx, Vericode et Whitesource, entre autres, proposent des offres de ce type, généralement connues sous le nom d'analyse de la composition logicielle ou Software Composition Analysis (SCA). Ces outils permettent de faire l'inventaire des composants open source utilisés dans une application. Mais, selon Jim Mercer, directeur de la recherche chez IDC, il est également important de noter que les logiciels SCA n'offrent pas de solution complète. Certains logiciels open source ne seront utilisés qu'en partie, de sorte que les vulnérabilités présentes dans une partie inutilisée du projet ou de la bibliothèque, qui seraient tout de même repérées par un outil SCA automatisé, pourraient créer de faux positifs. « L'outil SCA donnera des priorités en fonction de la classification CVE de départ, mais tous les outils ne comprendront pas comment est utilisé le logiciel », a-t-il ajouté. « Ce qui signifie qu'il faudra l'examiner soi-même ».
Soignant le support
Dès lors, l'autre partie de la solution, et sans doute la plus importante pour les entreprises, est contractuelle, étant donné la difficulté de l'analyse manuelle et statique d'une pile logicielle complexe et l'impossibilité potentielle pour les ingénieurs internes de résoudre des problèmes de logiciels open source qu'ils ne connaissent pas forcément. En d'autres termes, les accords de niveau de service SLA qui confèrent au fournisseur la responsabilité de l'analyse de la sécurité et de la résolution des problèmes pourraient être le meilleur outil pour éviter les problèmes potentiels liés aux logiciels libres de l'entreprise. « La solution consiste à établir un accord de niveau de service qui soutient la valeur du processus commercial, quel qu'il soit », a encore déclaré M. Driver. « Et s'il s'agit d'un processus critique pour l'entreprise, mieux vaut un accord de niveau de service en béton ».
