Une utilisation sécuritaire de l’open source en développement sur mesure

Pour mieux comprendre ce qu’est un projet open-source, imaginez une liste de lecture de vos chansons favorites que vous auriez créée sur l’une des nombreuses plateformes disponibles. Vous jouez cette liste de lecture en soirée…

• Tout le monde peut l’écouter (utiliser);
• La liste est accessible et on peut s’y abonner (voir);
• Un ami, Jean-Philippe, suggère d’ajouter un des morceaux d’un groupe peu connu dont il est adepte à la liste de lecture (modifier);
• Une autre amie, Camille, demande à l’utiliser lors de sa prochaine soirée (distribuer).

Développé de manière collaborative, l’usage de l’open source dans les projets numériques témoigne d’un fort état d’esprit communautaire. La qualité de l’open source repose sur des principes clés :

• La contribution continue : les développeur.euse.s ne font pas que se servir; chaque jour, ils et elles travaillent sur les projets disponibles, et les rendent accessibles à tous à leur tour.
• La validation et l’examen par les pairs : les projets open source sont toujours ouverts à l’amélioration, soutenus par la contribution de chaque développeur.euse qui les vérifie et les améliore.
• L’autonomie et la confiance : les éléments mis à disposition en open source sont fiables et déjà testés au quotidien. Il n’existe aucune dépendance vis-à-vis d’une entreprise qui aurait ses propres intérêts; les projets reposent sur des principes de transparence. La communauté se suffit à elle-même et est capable de faire progresser le développement technologique chaque jour.

La plus grande communauté open source évolue notamment sur GitHub, une plateforme reconnue pour la qualité de ses contributeurs et pour son nombre de contributions. De réels liens se créent entre contributeurs au quotidien, à travers des discussions virtuelles ou des rencontres lors d’évènements clés.

Les logiciels libres sont exposés aux mêmes risques que les applications développées par les entreprises, et souvent les solutions d’entreprises utilisent des dépendances en code source libre.

C’est l’une des raisons d’être de l’approche DevSecOps, qui permet de mitiger ces risques le plus rapidement possible.

Avant toute utilisation de projet en open source, nos expert.e.s analysent sa source, son nombre de contributions et l’activité du groupe de contributeurs – puisqu’un progiciel est rarement issu d’une personne individuelle.

Lorsqu’un code est mis à disposition en open-source, il est crucial qu’une licence de libre diffusion lui soit rattachée et que celle-ci stipule son type. Cette licence est accessible dans un fichier placé dans le dossier racine du projet. Elle permet donc d’identifier la source du projet. Mais elle permet aussi d’agir convenablement aux yeux de la loi : en effet, sans licence, le code sera protégé par un droit d’auteur par défaut. Tout auteur mal intentionné pourrait donc contester l’usage de son code « open source » et aurait légalement raison.

Il peut arriver que certains contributeurs abandonnent leurs projets. Un projet qui n’est plus à jour présente de forts risques de contenir des vulnérabilités et des bibliothèques désuètes.

L’outil Dependabot de GitHub peut mettre à jour certaines composantes du projet si celui-ci est configuré sur un dépôt de code. Avant d’utiliser un projet open source, on doit vérifier la date de la dernière mise à jour ou chercher s’il existe des vulnérabilités dans ce projet.

Le Top 10 OWASP (Open Web Application Security Project [Projet sur la sécurité des applications Web libres]) est la référence en matière de cybersécurité. Ce classement compile des données sur les vulnérabilités les plus exploitées des systèmes : il est important que chaque développeur.euse ait connaissance de ces risques afin de les repérer et de les corriger.

Il est recommandé d’automatiser votre projet le plus possible : construction automatique, tests automatisés, examens de sécurité, revue des licences, déploiements, vérification de code haché… Faites confiance aux automatisations, tout en effectuant des vérifications continues. En effet, une mauvaise configuration d’un de ces éléments pourrait causer une attaque à la chaîne d’approvisionnement ou encore une attaque « à la source d’eau » (water hole attack).

Dans nos pratiques DevSecOps chez nventive, nous utilisons l’outil Snyk. Celui-ci permet aux développeur.euse.s de scanner le code source, les dépendances, les conteneurs et l’infrastructure en tant que code (IaC) pour cibler et corriger ces vulnérabilités le plus rapidement possible.

Le processus de validation par les pairs pour approuver l’utilisation du code open-source renforce également la sécurité de l’utilisation du projet open-source.

Bien entendu, l’automatisation n’a de sens que si le déploiement de la correction d’une vulnérabilité est exécuté rapidement.

Utiliser des projets en open source possède deux principaux avantages : d’abord, ceci représente un gain de productivité important pour chaque développeur.euse. Ensuite, la qualité ayant déjà été mise à l’épreuve et s’étant démarquée, c’est une solution viable qui fait économiser du temps et croître la qualité de projet en projet.