alphaspirit - Fotolia

Vulnérabilités : GitHub veut faciliter l’analyse des dépendances

GitHub se penche un peu plus sur la sécurité du code déployé en production depuis ses dépôts. La fonctionnalité de revue des dépendances doit identifier les vulnérabilités avant la finalisation d’un merge.

Universe 2020. GitHub veut toujours et encore « améliorer l’expérience du développeur ». Outre un thème sombre pour protéger les yeux des programmeurs et la disponibilité générale de Discussions, un outil communautaire pour ne pas polluer les threads « issues » réservées à des tâches particulières, la filiale de Microsoft a présenté plusieurs capacités liées à la gestion de la revue de code.

Suite de l'article ci-dessous

Auto-merge des pull requests

La première concerne l’auto-merge des pull requests. « Environ 11 à 15 millions de pull requests sont fusionnées vers une branche principale tous les mois sur GitHub », selon Mario Rodriguez, responsable produit GitHub Enterprise.

« Environ 11 à 15 millions de pull requests sont fusionnées vers une branche principale tous les mois sur GitHub. »
Mario RodriguezResponsable produit GitHub Enterprise

Dans la plupart des cas, les développeurs doivent attendre une revue manuelle avant de voir le code qu’ils ont écrit en « live ».

Actuellement, la phase de révision n’enclenche pas le merge. Il faut « soit vérifier les notifications sur votre téléphone ou constamment rafraîchir la page avant d’entamer le merge », détaille Mario Rodriguez. La fonctionnalité doit accélérer le passage d’une tâche à une autre, et sera disponible dans les semaines qui viennent pour tous les utilisateurs de GitHub ayant activé les branches protégées.

L’auto-merge n’est pas nouveau pour certains habitués du système de gestion de versions. L’on retrouve plusieurs bots, des applications GitHub prévues à cet effet. À titre d’exemple, le spécialiste américain de la data science Palentir propose Bulldozer, son propre instrument open source de merge automatique des pull requests. Preuve que GitHub scrute les efforts de la communauté.

À l’inverse, l’éditeur intègre un garant pour contrôler et inspecter manuellement des objets de code avant l’activation d’un script GitHub Actions pour déployer les flux dans certains environnements. Par ailleurs, il introduit un outil de visualisation pour superviser les worfklows Actions en temps réel.

Des dépendances à passer au peigne fin

L’arrivée de la fonctionnalité « Dependency review », elle, doit compléter les efforts du groupe en matière de sécurité. Lors de GitHub Satellite, en mai dernier, Code Scanning avait été officialisé avant d’être porté en disponibilité générale, à la fin du mois de septembre 2020. Dans la même veine, Dependency Review doit identifier les dépendances d’un dépôt et les possibles vulnérabilités y résidant. L’outil prend en charge les paquets Maven, npm, PIP, RubyGems, Yarn et les CLI .Net (pour les langages C#, C++, F#, VB, Java, Scala, JavaScript, Python, Ruby et PHP).

Dans l’interface, les développeurs ont maintenant accès en bêta à un graphe des dépendances. Il est ensuite possible d’obtenir des alertes en cas de détection d’une anomalie. GitHub a décidé d’intégrer cette alarme prédictive au moment de la pull request, avant l’introduction d’une de nouvelles lignes de code dans un environnement. Selon Mario Rodriguez, cela complémente les capacités de Code Scanning et Secret Scanning, des outils propulsés par CodeQL.

« Dans un ou deux ans, vous pouvez envisager que nous allons nous rapprocher encore plus de l’IDE afin de signaler les erreurs aux développeurs au moment d’écrire leur code, ou de leur proposer des schémas d’autocomplétion pour éviter les vulnérabilités, à la manière d’un correcteur orthographique », envisage Mario Rodriguez. Cette direction de GitHub n’est pas surprenante quand on se rappelle que l’invité de marque lors de l’événement Satellite n’était autre que Ponicode, une startup française spécialisée dans le test unitaire automatisé de code JavaScript.

GitHub Actions arrive (enfin) sur site

Les entreprises, elles, pourront accéder à GitHub Enterprise Server 3.0 (GHES) dès le 16 décembre. Cette version inclut Actions, Packages, Code Scanning, le support sur smartphone et la bêta de Secret Scanning. Autant de capacités que les sociétés ne pouvaient pas utiliser depuis leur serveur. À noter que Code Scanning et Secret Scanning sont gratuits pour les dépôts publics, mais les clients de GitHub Enterprise doivent souscrire à GitHub Advanced Security pour en profiter.

« Il s’agit de la plus grosse mise à jour depuis 36 mois. »
Mario RodriguezResponsable produit GitHub Enterprise

« Il s’agit de la plus grosse mise à jour depuis 36 mois » vante Mario Rodriguez. « Nous apportons la couche DevOps qui manquait dans les produits Server on premise ». Cela n’impacte pas la tarification de GHES, assure-t-il.

Enfin, les entreprises peuvent financer des projets open source par le biais du programme GitHub Sponsors. Cette initiative similaire à Patreon ou Tipee était auparavant uniquement accessible aux particuliers. AWS, Daimler, New Relic, Microsoft, Indeed ou encore SubStack ont déjà versé de l’argent à certains mainteneurs. Ce système de parrainage mensuel n’engrange aucuns frais pour le donateur ou son neveu (hormis la TVA) pendant la phase bêta. Par la suite, GitHub s’attribuera une commission de 10 % sur les sponsors auprès des entreprises. Pour l’instant, Sponsors est accessible dans trente pays, dont la France.

Pour approfondir sur Open Source

Close