Quelle est la meilleure pratique pour gérer les RP traitant des vulnérabilités de sécurité dans les dépôts publics?

Comment un projet open source avec un référentiel public doit-il gérer au mieux les demandes de tirage (PR) qui corrigent des vulnérabilités de sécurité signalées de manière sécurisée mais pas encore divulguées publiquement?

Je suis impliqué dans un projet open source avec plusieurs centaines de contributeurs. Nous publions des avis de sécurité et des vulnérabilités plusieurs fois par an dans le cadre d'une version mensuelle régulièrement planifiée. Nous ne publions pas d'informations sur les vulnérabilités avant d'avoir rendu disponible la version corrigée. Nous sommes en mesure de gérer en toute sécurité les problèmes de sécurité dans notre système de gestion de projet (JIRA). Mais nous n'avons pas de bon processus pour masquer les PR qui corrigent les failles de sécurité lors de leur soumission à GitHub. Nous souhaitons que les utilisateurs puissent trouver ces correctifs avant leur publication et créer des exploits Zero Day.

Nous avons envisagé d'utiliser des dépôts privés qui génèrent le référentiel principal, mais une grande partie de notre flux de travail de révision et d'assurance qualité se produit actuellement sur les RP. Si nous déplacions le flux de travail vers une équipe de sécurité uniquement repo privé, cela réduirait la fenêtre lorsque le correctif est public jusqu'aux heures nécessaires pour générer les tarballs et les publier sur sourceforge, ce qui serait une grande amélioration. Nous devons également éviter de fusionner les RP dans notre version bêta publique.

Avant d'aller dans cette direction, j'aimerais savoir quelle est la meilleure pratique pour gérer les correctifs de correction de bogues de sécurité pré-version dans les projets open source avec open repos? Si le problème peut être mieux résolu en utilisant une plate-forme différente de GitHub, je dois mentionner que nous évaluons la migration vers GitLab.

— Joe Murray
source

Je ne sais pas s'il existe une meilleure pratique mise en place. GitLab est essentiellement un GitHub privé. Il n'est pas facile d'équilibrer les préoccupations des solutions open source et de sécurité. Combien de vos correctifs de sécurité proviennent de personnes n'appartenant pas à votre équipe de sécurité?

— Berin Loritsch

La plupart des problèmes sont signalés par d'autres, mais probablement moins d'un cinquième des correctifs proviennent de personnes ne faisant pas partie de l'équipe de sécurité.

— Joe Murray

À mon avis, si vous avez besoin qu'une partie de votre processus soit privée, cela devrait être fait en dehors de GitHub (parce que GH est public); après que cette partie spécifique soit terminée et que tout le monde ait révisé son code; vous pouvez créer un PR sur GH qui sera fusionné aussi rapidement que possible, juste pour «revenir» au processus officiel. Vous pouvez utiliser un autre outil pour gérer ces exceptions dans le processus.

— Emerson Cardoso

Une divulgation immédiate et complète (c'est-à-dire une divulgation publique sans délai) est une chose parfaitement légitime à faire.

— Miles Rout

Cette question semble supposer que, tant que le problème de sécurité n'est pas divulgué par l'équipe, il est inconnu du monde. Ce n'est tout simplement pas vrai; tout problème de sécurité découvert doit être supposé être connu par quelqu'un avec de mauvaises intentions quelque part. Maintenant, si vous supposez que quelqu'un d'autre connaît déjà le problème et pourrait l'exploiter, vous ne pouvez plus reporter la publication du correctif jusqu'à votre version mensuelle régulière. Vous devez libérer dès que possible. Cela signifie qu'il n'y a aucun problème à suivre le flux PR régulier. Juste PR contre la dernière branche de publication, fusion, balise, libération.

— Jory Geerts

Le protocole pour cela est de décider des facteurs de risque de montrer publiquement les vulnérabilités. Pour tout ce qui concerne la sécurité, ces relations publiques doivent être dans un référentiel privé que seule votre équipe de sécurité peut voir. Cela s'applique quelle que soit la plate-forme que vous utilisez pour produire et exécuter les demandes de tirage.

— Lloyd Moore
source