Nous consommons tous énormément de composants Open Source :
Depuis quelques années, le poids de l'Open Source dans les produits est en constante augmentation et on estime que 96% des logiciels actuels contiennent de l'Open Source.
En parallèle, la même étude indique que 84% des logiciels embarquent au moins une vulnérabilité.
En clair, nous consommons toujours plus de contenus produits par des tiers, le plus souvent sans relation contractuelle forte, engagement de réponses ou support. Nous nous reposons implicitement sur la vigilance de la communauté.
Que cela soit volontaire comme avec la tentative de hack via XZ ou par erreur, avec l’exposition des clés de dépôts Python, les risques sont bien réels avec des impacts qui peuvent être majeurs.
Il convient aujourd’hui d’abandonner une certaine innocence et regarder froidement tout composant que nous nous apprêtons à faire rentrer dans l’usine logicielle, avec 7 clés de lecture :
Cette analyse devrait être faite systématiquement pour tout contenu Open Source amené à tourner sur vos systèmes.
Attention à certaines licences comme GPL qui sont dites contaminantes et peuvent vous exposer à devoir publier le code source de vos produits.
Plus un projet est populaire, plus il est suivi et utilisé, c’est un signe qui ne trompe pas et une garantie qu’il y aura du monde pour suivre l’activité de développement, proposer des contributions ou remonter des problèmes. Donc plus d’acteurs dans la communauté.
Quelques exemples de projets dont la popularité va de pair avec l’utilisation.
2 indicateurs à suivre, Fork et Star, ici sur Kubernetes
Le Fork, c’est une copie du projet, sur le compte d’une personne ou d’une organisation, que ce soit pour contribuer ou en avoir une sauvegarde.
Le Star, c’est un marque page, pour une personne ou organisation, avec un compteur sur le projet, indéniablement le signe de la popularité du projet auprès des utilisateurs de la solution qui héberge le projet, ici GitHub..
L’activité sur un projet est un bon indicateur de son état de santé et cela permet de se faire une bonne idée de la dynamique. Un projet actif est un projet sur lequel les problèmes de sécurité auront le plus de chances d’être détectés et corrigés rapidement.
Nous trouvons ces informations sur le projet dans l’onglet Insight sur GitHub (ex: Trivy) et le menu Analyze chez GitLab (ex: Antora).
Prenons l’exemple de Trivy, hébergé chez GitHub, en essayant d’avoir une vue sur 30 jours chaque fois que possible.
Le projet a une bonne dynamique avec 56 demandes d’ajouts de code (Pull Requests) acceptées, 29 en attentes, 29 problèmes réglés et 23 nouveaux. Nous voyons aussi qu’il y a 20 contributeurs sur cette période, ce qui est un bon signal pour la contribution.
Nous pouvons suivre sur cet onglet le flux de développement et voir ce qui se passe semaine par semaine. Sur ce projet, nous constatons qu’il y une activité qui est majoritairement faite en semaine, donc lorsque les membres du projet sont actifs.
Cet onglet permet d’avoir une idée du rythme de développement et détecter des activités inhabituelles. Ici tout est régulier, les pics montrant des ajouts/suppressions de code, autrement dit du refactoring, ce qui est sain et souhaitable dans tout logiciel.
Il faut aussi avoir un regard sur l’activité des contributeurs et tout particulièrement si le projet en possède peu.
L’affaire XZ a démontré que certains acteurs cherchent à introduire des charges dangereuses au sein même d’un projet en devenant contributeurs.
La détection d’activités ou contenus anormaux se faisant par les contributeurs, plus nombreux ils sont, meilleures sont les chances de détection d’anomalies.
Outre le nombre de contributeurs, il faut regarder leur activité sur le projet, nous voyons ici qu’il y a 2 contributeurs majeurs sur la durée, un automate de mise à jour (dependabot), et 1 contributeur moins actif, une répartition des tâches courante.
Si votre domaine d’activité est ultra sensible, vous serez probablement amené(e) à creuser plus avant l’identité des personnes derrière les profils pour vous assurer que les contributions ne proviennent pas de pays identifiés comme dangereux ou hostiles.
Intéressons nous ensuite au processus d’acceptation du code entrant, via la mécanique de Pull Request (GitHub).
Premier exemple, une Pull Request produite par un des contributeurs actifs et validée par le second. Nous avons aussi une description claire qui donne le pourquoi.
Deuxième exemple, une Pull Request en attente de validation, via la mécanique des propriétaires de code (Code Owners), certains contributeurs ont été identifiés comme validateurs.
Le processus de validation du projet rassure, il y a des propriétaires identifiés dont la validation est obligatoire, avec une revue de code systématique.
Il faudra être vigilant sur les projets qui n’ont pas cette mécanique de validation, transparente, via Pull/Merge Requests.
La communauté d’utilisateurs est aussi un facteur qui va améliorer la confiance. Plus il y a d’utilisateurs, plus il y a de regards sur le projet, et de profils différents, Dev, Ops voire SecOps.
Ce sont les utilisateurs qui remontent les problèmes, les demandes d’améliorations ou d’ajouts de fonctionnalités, et créent une dynamique positive.
Là aussi, nous pouvons obtenir ses informations directement sur le projet, sur l’onglet Issues de GitHub ou GitLab.
Voici ce que nous pouvons voir sur GitLab pour le projet Antora
Le projet est bien actif, 1005 demandes clôturées, 131 ouvertes.
Les demandes sont traitées par plusieurs contributeurs :
Certaines demandes donnent lieu à des Merge Requests, liées à la demande.
Nous pouvons parler ici de transparence de bout en bout.
Il est important de suivre la vie du projet, pour rester informé(e) et anticiper les actions.
Liste de diffusion des annonces de la fondation Apache
Trivy via le réseau X
La partie documentaire est aussi un point d’attention à avoir.
Une documentation de qualité va guider l’utilisateur sur le bon emploi de la librairie, framework ou outil, tout au long de son cycle de vie, des premières évaluations à la mise en production et lors des montées de versions, toutes les conditions pour bien faire les choses.
Ces informations vont permettre une utilisation dans des conditions nominales, de stabilité mais aussi de sécurité.
Prenons comme exemple la documentation Docker, il y a une partie dédiée à la sécurité Docker avec un ensemble de pratiques et attentions à avoir.
La présence de documentation liée à la sécurité est un bon révélateur de l’attention du projet sur cet aspect.
Lorsque nous faisons son marché dans les projets Open Source, pour l'outillage de l’usine logicielle, nous allons trouver plusieurs cas de figure qui viendront chacun avec un niveau de support différent
Le projet d’une ou plusieurs personnes est par définition le plus risqué, car il est la plupart du temps mis à disposition à titre bénévole et sans aucune garantie.
Ce projet peut aboutir à la création d’une entreprise, voire être repris par une communauté ou fondation, mais dans sa phase initiale, il sera le plus risqué, tant sur la pérennité que sur le contenu.
Il conviendra d'être tout particulièrement attentif(ve) au processus de contribution mais aussi à la fabrication des livrables projet. Il faudra notamment s’assurer de la présence d’outils de tests de qualité et de détection de vulnérabilités dans la chaîne de fabrication.
Le projet porté par une organisation communautaire, comme Debian, offre plus de garanties car il s’appuie sur un nombre plus important de contributeurs, donc plus d'attention et de mainteneurs, c’est une réduction des risques sur la pérennité.
Nous trouvons des personnes en charge des corrections de failles de sécurité, et ce dès qu’elles leur ont été rendues communiquées.
De même, il y a souvent des usines de production des contenus.
Les fondations traditionnelles, comme Apache ou Eclipse, s'appuient sur des communautés de contributeurs et ont des statuts juridiques et le soutien d’acteurs majeurs.
Les fondations portent le projet dans le sens où elles vont garder un projet actif tant qu’il a des contributeurs volontaires pour le maintenir.
C’est souvent une approche où la communauté prime, la fondation s’assurant que l’ensemble des contributeurs puissent avoir droit au chapitre.
Via la communauté, nous avons une garantie de pérennité et des décisions transparentes.
Nous trouvons aussi des profils dédiés à la sécurité et des usines de fabrications des contenus avec des standards de qualité et sécurité importants.
Nous trouvons en Open Source énormément de projets qui sont financés par des entreprises, avec des modes de rémunération qui vont dépendre de leur activité.
Sur ce type de projet, nous pouvons avoir une vaste palette de services offerts par l’entreprise :
Nous rentre là dans une approche plus traditionnelle, avec l’ensemble des garanties offertes dans une offre commerciale, qui peuvent aller jusqu’au dédommagement en cas de sinistre.
Choisir un projet Open Source doit être un choix raisonné avec une étude préalable sur la dynamique, les contributeurs et la communauté.
Si le projet est utilisé dans des parties sensibles ou critiques de vos solutions, il faudra porter une attention supplémentaire et continue car rien n’est immuable dans un projet communautaire.
Les contributeurs peuvent partir, la communauté se réduire, l’activité de maintenance et surveillance par les pairs se réduire. Les critères de choix d’un moment peuvent ne plus l’être quelques mois ou années plus tard.
En règle générale, un projet activement maintenu donnera plus de garanties de stabilité, qualité et sécurité.
Retenir des projets avec suffisamment d’ancienneté c’est s’assurer d’avoir la masse critique de contributeurs et d’utilisateurs, rester prudent avec les projets émergents même avec du potentiel et attendre qu’ils prennent un peu de maturité.
Un corollaire implicite est que plus on utilisera de composants externes Open Source, plus l’activité de suivi desdits projets sera importante. Une raison de plus pour garder ce chiffre sous contrôle.