[Tribune] Cinq étapes pour gérer les vulnérabilités et les licences des logiciels open source

Les risques concernant la sécurité et la conformité des composants tiers atteignent des proportions incontrôlables, et menacent l'intégrité même de la chaîne d'approvisionnement de logiciels. Il suffit de voir l'impact de la faille Heartbleed pour s'en convaincre !

Aujourd'hui, les entreprises incluent davantage de code open source que d'éléments conçus en interne ou propriétaires dans leurs produits. Malheureusement, en profitant de ces logiciels open source (OSS) pour accélérer le développement de leurs produits, la plupart d'entre elles ne respectent pas les licences open source associées à ces composants. Bien que les OSS soient gratuits, leurs utilisateurs ne sont pas pour autant libres de toute obligation les concernant. Celles-ci peuvent aller de la reproduction de déclarations de droits d'auteur ou d'une copie d'un document de licence à la divulgation de l'intégralité du code source de leurs produits. Des enquêtes récentes ont montré que la plupart des entreprises ne connaissent qu'un faible pourcentage des composants open source sur lesquels elles s'appuient, et ne sont donc pas en mesure de respecter les obligations indiquées dans les licences de ces éléments. En outre, ces logiciels peuvent comporter des bugs ou des vulnérabilités susceptibles d'affecter votre produit. Sans un suivi adéquat, ce dernier peut passer à côté de mises à jour ou de patches corrigeant des vulnérabilités connues. Mais malgré cela l'open source offre de précieux avantages.

Découverte, gestion et conformité en cinq étapes

Face aux problématiques de conformité ou de gestion des vulnérabilités des OSS, la première question est généralement : "Comment savoir quels composants open source nous utilisons ?" Il est possible de mieux comprendre ce que l'on fait et de mettre en place un processus pour découvrir, gérer et s'assurer de la conformité avec ces OSS en cinq étapes.

Étape 1 : comprendre comment les OSS sont introduits dans votre entreprise

Les OSS peuvent s'introduire de différentes façons. Cas classique : un développeur décide d'utiliser un composant open source, télécharge le code source, et l'intègre au produit. Ce cas est encore très fréquent, mais il existe bien d'autres scénarios. Très souvent, les développeurs utilisent ce qu'on appelle des gestionnaires de référentiels (repository manager). Ces outils leur permettent d'indiquer les composants qu'ils veulent utiliser, puis s'occupent eux-mêmes d'en télécharger le code source ou des fichiers binaires compilés. Ces gestionnaires stockent généralement les composants open source dans un référentiel distinct, hors du système classique de gestion des codes source. On peut notamment citer parmi eux Maven, Nuget ou npm.

Des éléments open source peuvent également être introduits dans une organisation en tant que sous-composant d'un composant open source plus important ou commercial. Les composants de premier niveau ont très souvent plusieurs sous-composants ou dépendances open source, qui sont rarement divulgués ou gérés.

En outre, ces éléments serviront de pièces d'une infrastructure runtime, comme des serveurs web, des systèmes d'exploitation ou des bases de données.