La disponibilité du code, des applications, des packages et des bibliothèques open source est l'un des facteurs les plus importants de l'écosystème des développeurs. Il s'agit d'un ingrédient essentiel compte tenu du rythme intense auquel les applications modernes sont créées, perfectionnées et maintenues. L'époque où les développeurs devaient créer à chaque fois un nouveau code pour fournir des fonctionnalités communément utilisées est révolue. Désormais, ils peuvent s'appuyer sur les avancées des grandes entreprises et se concentrer sur le développement des nouvelles caractéristiques et fonctions de leurs applications.
Ces dernières années, l'utilisation de l'open source est devenue quasiment universelle chez les développeurs d'applications. Selon Gartner, 96 % de toutes les applications contiennent des packages open source qui représentent l’immense majorité des fondations invisibles qui soutiennent le code natif des développeurs. Toujours selon Gartner, 80 % du code source des applications, toutes catégories confondues, est open source. Cette possibilité de créer plus rapidement sans avoir à réinventer la roue pour avancer est un immense avantage. Mais cette liberté implique une responsabilité considérable.
Ces dernières années, nous avons assisté à une augmentation importante des attaques de la supply chain par des cybercriminels ciblant des packages open source populaires : ces cybercriminels ont rejoint des projets existants et modifié leur code, ou créé de nouvelles variations sur des packages existants qui semblent être la dernière version mais contiennent en fait du code malveillant.
C’est un vecteur d’attaque assez facile et redoutablement efficace. De nombreuses librairies open source sont mises à jour presque quotidiennement et téléchargées dans des dépôts tels que NPM, RubyGems et PyPi avec peu, voire aucun contrôle de sécurité. Ces librairies peuvent ensuite être téléchargées des millions de fois par d’autres développeurs sans autre forme de vérification.
L'incident event-stream de 2018 en est un excellent exemple. Un cybercriminel s'est fait passer pour un nouveau contributeur enthousiaste et compétent sur event-stream, un utilitaire réputé qui était entré en phase de maintenance depuis 2015. Très vite, il a pu obtenir des droits d'édition et de publication. Il a d’abord ajouté un nouveau composant inoffensif au package, mais le mois suivant, il a mis à jour ce composant avec une nouvelle version contenant du code malveillant. Le package infecté a été téléchargé par des millions de développeurs et il a fallu attendre plus d'un mois avant que quelqu'un ne remarque le contenu malveillant. Ce code additionnel, hyper ciblé, ne visait qu’une seule entreprise qui développait des wallets pour bitcoins et avait pour effet de capter des informations sur les utilisateurs finaux. Mais bien évidemment il aurait pu contenir d’autres éléments plus génériques tels que des ransomware et autres ouvertures à des fuites de données.
Les développeurs ne peuvent donc pas avoir une confiance aveugle dans les packages open source. Si le code d'application développé en interne fait généralement l'objet d'un examen beaucoup plus approfondi en matière de sécurité, les librairies open source étaient supposées être intrinsèquement plus fiables. Mais aujourd'hui, on sait que cette hypothèse n’est pas judicieuse et les développeurs doivent effectuer des recherches approfondies sur les logiciels libres avant de les utiliser. Le processus de recherche doit se concentrer sur quatre questions clés.
Tout d’abord, il faut se demander qui d’autre utilise le package car le volume d’utilisation apporte une dose de sécurité. Un package largement utilisé à plus de chances d'être digne de confiance et efficace. Les vulnérabilités ou l'ajout de code malveillant sont plus susceptibles d'être repérés. Les dépôts nous donnent de la visibilité sur leurs nombre de téléchargements, les évaluations, les bifurcations, les dépendances et autres indicateurs de succès. Toutefois, l’exemple d’event-stream nous rappelle que la popularité d’un package n’apporte aucune garantie de sécurité.
Ensuite, il faut se demander si le package est toujours maintenu. Malgré leur popularité, certains packages ne sont plus maintenus quand ils sont jugés "terminés" ou si les principaux développeurs n’y portent plus d’intérêt. Cela devrait vous alerter. En cas de problèmes avec le package d’une application critique pour l'entreprise, personne ne pourra alors vous aider. De plus, vous ne pouvez pas être sûr de sa compatibilité avec des composants plus modernes ou que des vulnérabilités ne se sont pas développées au fil du temps. Il faut donc privilégier une librairie avec un flux régulier de commits, vérifiez la liste des issues ouvertes et des pull-requests. Ce n’est pas toujours un mauvais signe, mais des trous importants dans les étapes de progression d’un projet très actif doivent vous faire vous interroger.
Le niveau de popularité d’un package et un rythme de maintenance régulier peuvent donner quelques indicateurs de réassurance, mais il faut également se demander si une librairie introduit plus de risque dans votre application. Il n'est pas toujours facile de savoir si une librairie contient des vulnérabilités ou même du code malveillant. Très souvent, les développeurs ont le choix entre différentes librairies et doivent bien évidemment privilégier celle qui présente le moins de risques, et s'assurer qu'ils utilisent la version la moins vulnérable, qui n’est pas forcément la plus récente. Il faut consulter des bases de données bien à jour et maintenues pour rechercher ces vulnérabilités, et idéalement, automatiser ces vérifications.
Mais le risque ne s’arrête pas aux aspects de sécurité. Chaque composant open source est accompagné d'une licence décrivant la manière dont il peut être utilisé. Et les entreprises qui ne respectent pas ces exigences de conformité doivent payer des amendes. Les développeurs doivent donc rechercher le nom et le type de licence sous laquelle le logiciel a été publié et s'assurer que leur propre application ou les politiques de leur entreprise ne les exposent pas à un risque de non-conformité.
Enfin, il faut s’attarder sur la force de la communauté d’utilisateurs de la librairie. Pour la plupart des projets open source, une petite équipe centrale est responsable de l'écriture et de la maintenance du code. Mais la communauté d'utilisateurs joue également un rôle essentiel pour faire avancer le projet en demandant des fonctionnalités, en signalant les bugs et en donnant son avis sur la feuille de route. Une librairie avec une communauté forte a plus de chances d'être saine et dynamique, car elle introduira et améliorera ses fonctionnalités et ses performances au fur et à mesure. Une communauté forte et vivante aura également plus de chances de produire des outils qui rendront l’utilisation de la librairie plus facile, et vous simplifieront la vie. Vérifiez la progression du nombre de contributeurs pour conforter votre confiance dans le package.
Avec ce degré de rigueur dans la sélection des librairies open source, il est plus facile de coder en ayant confiance dans les éléments fondamentaux d'une application pour fournir un support solide et sécurisé. Cela entraîne des efforts supplémentaires, mais il existe des outils en ligne très fonctionnels qui peuvent fournir les informations nécessaires rapidement.