La bonne santé de Jenkins ne cache pas des enjeux de sécurité
L’usage croissant du serveur d’automatisation des pipelines CI/CD entraîne des défis importants pour la communauté et les éditeurs en matière de sécurité. Il semble toutefois protégé des changements de licences qui affectent les utilisateurs de CentOS et de Terraform.
L’adoption de Jenkins, douze ans d’âge, est au plus haut. Selon la CD Foundation, une filiale de la fondation Linux, l’utilisation des pipelines CI/CD propulsés par le serveur d’automatisation a grimpé de 79 % entre juin 2021 et juin 2023. La CI Foundation a comptabilisé plus de 27,1 millions de jobs par mois en juin 2021, contre plus de 48,6 millions en juin de cette année.
L’ensemble des charges de travail liées à Jenkins ont crû de 45 % selon la même méthode de calcul, de 50,7 millions à 73,7 millions de workloads.
Selon les estimations de Datanyze, Jenkins détiendrait 44 % de parts de marché du secteur de la CI/CD. La CI Foundation s’appuie sur cette estimation pour extrapoler le nombre de personnes qui utilisent le serveur d’automatisation. Le cabinet Evans Data évalue qu’il y a environ 25 millions de développeurs dans le monde. En croisant ces deux indicateurs, il y aurait donc 11 millions de développeurs qui exploiteraient Jenkins pour animer leurs flux d’intégration continue.
Si la méthodologie peut être interrogée, la fondation corrèle ces données avec 200 témoignages récoltés entre 2020 et 2021 auprès d’éditeurs et des fournisseurs (IBM, Cloudbees, Dell, Finastra, Thales, etc.), mais également de grands groupes, dont Roche et Novartis, ainsi que des laboratoires de recherche universitaires, par exemple le CERN.
« Si l’on évoque moins l’approche DevOps qu’auparavant, cela ne veut pas dire que les technologies ont été déployées du jour au lendemain au sein des entreprises », remarque Sacha Labourey, Chief Strategy Officer et cofondateur de CloudBees.
« Ce que l’on observe, c’est simplement la maturité de l’adoption [de Jenkins]. Plus d’applications, plus d’équipes, plus de tests dépendent de la technologie », note-t-il.
Le nombre de pipelines grandirait afin de couvrir les exigences des entreprises en matière de tests et d’analyses de sécurité.
Aux États-Unis, ces exigences ont augmenté en réponse à l’Executive Order publié par l’Administration Biden en mai 2021. Ce décret a instauré la nécessité de mettre en place des Software Bills of Materials (SBOM) dans le but de tracer les dépendances des systèmes et d’en assurer les mises à jour et les sécurisations.
« Quand l’on met en place un SBOM, il convient de tracer automatiquement les dépendances, donc ça nous amène à l’intégration continue », avance Sacha Labourey.
C’est l’une des raisons parmi d’autres qui expliqueraient la popularité grandissante de la technologie. Le Chief Strategy Officer n’écarte pas le fait que la pluralité des plug-ins Jenkins, plus de 1 800 au total, engendre une certaine complexité. En contrepartie, il est conseillé de subdiviser les contrôleurs associés aux plug-ins et donc – potentiellement – d’augmenter le nombre de pipelines.
Renforcer la sécurité de Jenkins
Évidemment, la sécurisation même de Jenkins interroge CloudBees, les contributeurs principaux et les membres de la communauté.
« La communauté travaille à l’intégration [de Jenkins] avec des projets open source tiers. Il y a de plus en plus d’intégrations avec les scanners de sécurité, dont les outils SCA. Il y a également des discussions sur la manière de verrouiller les builds afin de contrôler ce qui est émis et ce qui est consommé », énumère Sacha Labourey.
« Nous avons aussi des réflexions en interne, chez CloudBees, sur la manière de sécuriser ces environnements », ajoute-t-il.
La communauté Jenkins veut par ailleurs renforcer la fiabilité des processus de publication de mises à jour, de vérification des accès et de maintien des dépôts de code liés aux projets. « On se souvient tous de l’affaire SolarWinds et de ces impacts sur l’industrie IT. C’est la crainte de tout éditeur d’outils CI ».
Comme Jenkins anime une bonne partie des chaînes CI/CD, « si les builds Jenkins sont infectées, une bonne partie des logiciels qui passent dans les mailles de Jenkins sont potentiellement vulnérables », note le CSO. « Jenkins est une infrastructure essentielle et critique ».
« Jenkins est une infrastructure essentielle et critique ».
Sacha LaboureyCofondateur et Chief Strategy Officer, CloudBees
Outre l’intégration avec des outils de scan de sécurité, la CD Foundation a créé un groupe d’intérêts spécifique à la sécurisation de la chaîne logistique logicielle et a engagé des discussions avec l’OpenSSF, selon Sacha Labourey.
Malgré les difficultés liées à la sécurité des projets open source, ils seraient de plus en plus appréciés.
De manière générale, Faith Degirmenci, directeur général de la Continuous Delivery Foundation, observe « une tendance à l’adoption de l’open source par les grandes organisations ». « Les leaders des secteurs financiers, industriels et les fabricants de semiconducteurs, autrefois réticents à adopter l’open source, le font désormais publiquement », déclare-t-il dans un communiqué de presse.
« De plus en plus, les entreprises découvrent que les logiciels open source, tels que Jenkins, accélèrent l’innovation et permettent d’acquérir un avantage concurrentiel ».
Pourtant, le monde de l’open source est soumis aux problématiques de financement et de gestion de licences.
S’il y a bien des tentatives de récupérer les utilisateurs des versions open source de Jenkins, le projet est a priori protégé des desiderata d’un éditeur. Il est sous l’ombrelle de la CD Foundation et de la Linux Foundation. Celles-ci listent plus de 2 600 dépôts GitHub liés à Jenkins et 1 million de lignes de code contribuées par 600 personnes actives soutenues ou embauchées par des acteurs comme Atlassian, AWS, CloudBees, Fastly, GitHub, IBM, JFrog, Sentry, Datadog, AWS, DigitalOcean, Discourse ou encore PagerDuty.
Au-delà de Jenkins, le modèle open source de nouveau remis en question
Ce n’est pas le cas de projets comme CentOS mené par Red Hat ou Terraform, par HashiCorp, deux projets qui ont provoqué des remous importants au sein des communautés open source et IT.
Sacha Labourey, qui évolue depuis près de vingt ans dans le monde de « l’open source professionnel », perçoit là une évolution de plus des modèles économiques liés à l’open source.
« Cela a commencé par des offres de consultance, de formation et de support. Puis, Red Hat a lancé des modèles de souscription à partir de 2000-2001. En 2005-2006, on a commencé à voir les premiers projets open core. Ils étaient considérés comme une absurdité par certains puristes, mais c’est devenu le modèle de facto », raconte-t-il. « Puis, l’on a commencé à voir les modèles open core pour lesquels la marque et les copyrights étaient possédés par une société ».
Selon Sacha Labourey, cette approche de l’open core s’est imposée comme le « nouveau normal ».
« Si vous vouliez récolter des fonds en tant qu’éditeur et que vous n’aviez pas un modèle open core qui vous permet d’assurer la propriété de l’IP et de la marque, votre démarche était considérée comme absurde économiquement par les investisseurs ».
Ce n’est ni la première ni la dernière fois qu’un éditeur « de philosophie open source » décide de changer son modèle commercial. En 2018, MongoDB a fait le choix de créer et d’adopter la licence SSPL. Cette Licence a été adoptée quelques années plus tard par Elastic pour la même raison : éviter de se faire cannibaliser par les géants du cloud.
« Il y a eu un effet David contre Goliath, ils [MongoDB et Elastic] devaient se battre contre AWS, ce qui a généré une sorte d’acceptation », note Sacha Labourey.
Pour autant, le dirigeant constate que ce fut l’occasion pour ces entreprises de tester la propension de la communauté et des autres éditeurs à créer des forks viables.
« Plus la solution est mature, plus le risque qu’un fork soit mis en œuvre est grand : trouver trois personnes pour maintenir une base de code, c’est simple », théorise le Chief Strategy Officer. « En revanche, quand un leader charismatique propose des innovations tous les six mois, il est possible de forker, mais quid de l’avenir du projet ? ». MongoDB et Elastic ont mis en avant une licence propriétaire qui garantit des propriétés proches des principes de l’Open Source Initiative. HashiCorp, lui, serait allé un cran plus loin.
« La question est de savoir : jusqu’où trop loin on peut aller ?».
Sacha LaboureyCofondateur et Chief Strategy Officer, CloudBees
« MongoDB et Elastic tentent de restreindre certains cas d’usage. La grande nouveauté, c’est que HashiCorp adopte une approche axée sur le business : ils [les dirigeants d’HashiCorp] se gardent le droit d’estimer si oui ou non une solution entre en compétition avec la leur et d’invoquer une sanction en conséquence ».
En conséquence, pour Sacha Labourey, Terraform étant « relativement mature », le fork proposé par OpenTF représente un risque important, « et ce, sans que les fournisseurs cloud s’y soient mis ».
« La question est de savoir : “jusqu’où trop loin peut-on aller ?”. Nous sommes peut-être en train de le découvrir », indique le CSO.
