Pourquoi la gouvernance de l’open source est essentielle à la sécurité

Qu’est-ce que la gouvernance de l’open source ?

La gouvernance de l’open source désigne les règles et les pratiques reconnues qui encadrent un projet open source. Selon OpenSource.com, pour définir les directives de gouvernance, il faut répondre aux questions suivantes : 

• Quels rôles les contributeurs peuvent-ils jouer dans le projet ?

• Quelles qualifications, responsabilités, prérogatives et quel pouvoir sont associés à chaque rôle ?

• Comment les personnes sont-elles affectées à des rôles (et en sont-elles retirées) ?

• Comment les définitions des rôles peuvent-elles être modifiées ?

• Quelles sont les politiques et procédures collectives du projet ?

Une fois les rôles au sein du projet définis, généralement en fonction des activités de chaque développeur, la gouvernance du projet open source peut être mise en place.

6 modèles de gouvernance différents

La définition des règles d’un projet open source et l’attribution des rôles constituent son modèle de gouvernance. Selon Red Hat, il existe six modèles de gouvernance.

1. Do-ocratie : ce modèle de gouvernance part du principe que les développeurs qui font le travail doivent aussi prendre les décisions. L’évaluation par les pairs joue donc un rôle important dans la gouvernance. Ce modèle peut toutefois être difficile pour les développeurs qui ont besoin d’un accompagnement plus poussé.

2. Fondateur-dirigeant : ce modèle de gouvernance open source est le plus souvent utilisé pour les nouveaux projets ou ceux qui ne comptent que quelques contributeurs. Dans ce modèle logiciel, la gouvernance est clairement définie et revient généralement à la personne à l’origine du projet ou à l’équipe de développement initiale. Malheureusement, ce modèle peut mener à une forme de dictature open source, où le fondateur-dirigeant impose sa gouvernance pendant tout le cycle de vie du logiciel.

3. Conseil ou comité auto-désigné : ce modèle de gouvernance des logiciels open source crée un comité de direction chargé de superviser les étapes de développement du projet. Son inconvénient : ce comité peut exclure les autres membres de l’équipe et ne pas tenir compte de leur avis ni de leur participation.

4. Électoral : ce modèle permet à la communauté de choisir sa gouvernance par le biais d’élections. Il est populaire pour les projets bénéficiant d’une forte participation communautaire, avec plusieurs développeurs aux compétences et aux rôles similaires. C’est le modèle le plus équitable en matière de prise de décision, mais il peut aussi ajouter des niveaux de responsabilité et de distraction, ainsi que susciter des conflits internes lorsque les membres de la communauté se disputent les postes de direction.

5. Soutenu par une entreprise : dans ce modèle de gouvernance logicielle, des entreprises ou des secteurs d’activité prennent en charge la distribution du logiciel dans le cadre de licences open source. Cela leur permet de contrôler le développement logiciel, mais limite aussi les contributions externes, pourtant caractéristiques des projets open source.

6. Soutenu par une fondation : ce modèle est géré par un organisme à but non lucratif, et la gouvernance est souvent strictement contrôlée par une structure unique. Cela s’explique par les exigences liées au statut de ces organismes.

Comment formaliser les rôles de direction

Les projets logiciels open source sont conçus pour favoriser la collaboration, mais la gouvernance leur donne une orientation. Les responsables guident le projet, veillent au respect des délais et à l’application des politiques et directives.

Chaque modèle de gouvernance a ses propres processus pour choisir les responsables :

• Do-ocratie : le leadership se construit par l’action. Plus les contributions d’un développeur à un projet sont acceptées, plus son influence au sein de la communauté du projet grandit.

• Fondateur-dirigeant : les personnes à l’origine du projet en prennent le plus souvent naturellement la direction.

• Auto-désignation : dans les projets open source plus matures et de longue durée, la documentation décrivant les processus de gouvernance est souvent déjà disponible. Il revient au développeur de prendre l’initiative de comprendre comment ses contributions peuvent lui ouvrir la voie à des rôles de direction.

• Électoral : un processus électoral prévoit des procédures clairement définies pour déterminer comment et quand les élections ont lieu, ainsi que les postes concernés. Les résultats des élections sont facilement consultables dans la documentation en ligne du projet. Les candidats se sont généralement forgé une réputation au sein de la communauté avant de briguer un poste de direction.

• Soutenu par une entreprise : la gouvernance relève de l’entreprise à l’origine du projet, et les responsables entretiennent donc un lien avec elle.

• Soutenu par une fondation : la gouvernance relève directement de la fondation ou d’un conseil auto-désigné.

Tous les contributeurs au projet devraient pouvoir assumer un rôle de gouvernance s’ils le souhaitent, mais le développeur doit d’abord rejoindre le projet. Pour cela, les développeurs intéressés peuvent s’abonner à la liste de diffusion du projet, accessible sur GitHub et sur les sites officiels du projet.

Une fois qu’ils commencent à contribuer à un projet, ils doivent suivre leurs contributions. Des outils comme le journal des contributions open source permettent de le faire. Le suivi des contributions fournit une preuve du travail accompli aux personnes qui souhaitent accéder à des postes de direction dans la gouvernance open source.

Les rôles au sein de la gouvernance open source

Les contributeurs à des projets occupent des rôles officiels dans la gouvernance des logiciels open source. Parmi les plus reconnus :

Responsable de maintenance : il peut s’agir d’une personne qui a écrit une grande partie du code du projet open source, qui a rédigé sa documentation ou même qui en est un fervent défenseur. Cette personne se sent responsable de l’orientation générale du projet et fait le nécessaire pour l’améliorer.

Contributeur : toute personne qui contribue au projet, que ce soit en commentant des problèmes ou en écrivant du code. Dès lors qu’elle apporte quelque chose de valeur au projet, elle joue un rôle de contributeur.

Commetteur : personne disposant de droits de commit spécifiques et ayant fait preuve d’un engagement profond et continu envers le projet.

4 façons de protéger votre projet open source

Les logiciels open source attirent par leur accessibilité à toute personne souhaitant s’impliquer. Mais le fait que tout le monde puisse contribuer représente aussi le principal risque des projets open source. La gouvernance open source consiste notamment à protéger le projet contre les menaces. Voici quelques mesures pour prévenir les risques :

1. Établissez des politiques de sécurité pour le projet, notamment en ce qui concerne la supervision des utilisateurs et des contributeurs ou la documentation du projet. Une personne occupant un rôle de direction doit être habilitée à faire appliquer ces politiques. Les responsables de maintenance sont tout indiqués pour ce rôle.

2. Testez, suivez et corrigez les vulnérabilités. Les outils d’analyse de la composition logicielle (SCA) permettent aux développeurs d’analyser et de gérer les composants open source d’un logiciel. Ils servent notamment à vérifier les licences et à évaluer les risques liés aux vulnérabilités. 

3. Limitez les personnes autorisées à créer des demandes de tirage (pull requests) et évaluez celles-ci avant d’agir. Vous pouvez également analyser ces demandes à l’aide d’outils SCA ou d’outils de test de sécurité des applications statique (SAST) afin de détecter les vulnérabilités.

4. Vérifiez les antécédents des contributeurs avant de les intégrer à un projet et ne donnez accès qu’aux utilisateurs de confiance.

Quand mettre en place une gouvernance

La gouvernance doit être mise en place le plus tôt possible dans tout projet open source. Plus la documentation est rédigée tôt, plus il est facile de définir les attentes et les objectifs. Une gouvernance précoce permet également de définir clairement les rôles. Si le projet est soutenu par une entreprise ou une fondation, les discussions doivent avoir lieu en interne avant son lancement, afin que les processus soient clairs et qu’une voie à suivre soit établie.

Contributions des entreprises et modèles de gouvernance

Les logiciels open source sont utilisés par de nombreux utilisateurs différents. Les entreprises ayant chacune leurs propres besoins, leurs contributions peuvent modifier la portée du logiciel. Certaines peuvent également affecter des développeurs rémunérés à la contribution de certains projets.

Ces contributions doivent être traitées comme toutes les autres. La gouvernance reste fondée sur la valeur des contributions et le niveau d’implication.

Bien démarrer avec la gouvernance open source

Plus de 90 % des logiciels propriétaires utilisent des composants open source. La gouvernance open source devrait donc être une priorité pour les services informatiques et les équipes de direction de toute entreprise qui publie du code en open source. Les politiques de gouvernance open source, les rôles des contributeurs et ceux des responsables doivent être clairement définis et communiqués. Toutes les personnes impliquées dans le développement de logiciels open source doivent connaître leur rôle dans le projet.

Les politiques de gouvernance open source apportent des solutions aux problèmes susceptibles de survenir, des risques de sécurité aux risques opérationnels. Une gouvernance insuffisante peut ralentir le cycle de développement logiciel, retarder les mises en production ou nécessiter des corrections après le lancement du produit.

La mise en place de modèles de gouvernance permet de traiter les problèmes juridiques potentiels. Par exemple, la politique de gouvernance de l’organisation devrait prévoir un outil SCA pour identifier les vulnérabilités potentielles et les problèmes de licence dans les dépendances. Snyk Open Source vous permet de visualiser les packages open source que vous utilisez, ainsi que de gérer la conformité des licences et les dépendances.