La sécurité, l’autre priorité de GitHub

Une résidentialité des données encore perfectibles

À commencer par la problématique de la résidentialité des données. GitHub Enterprise Cloud offre en disponibilité générale l’option de stocker les données en Union européenne sur des instances multitenant Azure. L’éditeur promet d’offrir la même option pour d’autres régions. Cela comprend les dépôts, l’ensemble des contenus crées par les utilisateurs, les espaces de stockage blob sous-jacent, les adresses IP, mails, les pseudos, les noms et prénoms des utilisateurs, les logs liés à GitHub Actions, et les données nécessaires à la reprise après désastre. Dans ses communiqués, GitHub ne précise pas où sont précisément situées ces régions cloud européennes. Il faut se rendre dans ses politiques de confidentialité pour découvrir qu’une région est déployée en France. L’entreprise ne précise donc pas s’il considère sa région cloud Azure en Suisse comme faisant partie de l’UE.

Les données de télémétrie d’identification des usagers, les informations de facturation, les données et les logs de GitHub Copilot sont transférés « en dehors de la région » choisie, c’est-à-dire aux États-Unis. Les transferts sont protégés par des flux TLS.

Outre un mécanisme de protection des données des clients cloud, GitHub vante dans sa documentation cette option comme un argument supplémentaire pour migrer de GitHub Enterprise Server vers Enterprise Cloud.

Renforcer les pouvoirs (et les devoirs) des administrateurs

Toujours dans le domaine de la sécurité, les clients Enterprise peuvent utiliser les fournisseurs SSO et SCIM de leurs choix.

L’éditeur ajoute également des contrôles pour limiter les « bypass » de push de code effectués par des développeurs souhaitant accélérer le passage des tests unitaires. En corrélation avec l’outil de scan de secrets, il s’agit d’éviter systématiquement le dévoilement de secrets, des tokens ou de mots de passe, par la mise en place d’un cycle de révision contrôlé par des utilisateurs désignés par les administrateurs. « Les personnes occupant ces rôles et équipes pourront contourner elles-mêmes la protection de push et agiront en tant qu’examinateurs pour toute demande de contournement soumise par un autre contributeur. Les demandes peuvent être approuvées ou refusées, ce qui détermine si la livraison peut être effectuée dans le dépôt », explique GitHub dans sa documentation.

Il y a aussi un moyen pour « blacklister » des changements spécifiques, par exemple l’usage d’un runner Actions, le changement de noms de fichiers ou de limiter leur taille. Cette fonctionnalité est accessible pour les clients ayant souscrit à Advanced Security.

Par ailleurs, ces clients-là bénéficient de l’amélioration de Secret Scanning qui indique désormais quand un secret détecté dans un dépôt privé a fuité dans un dépôt public. L’outil a de surcroît le droit à des patterns génériques pour détecter des clés et des ingestions liées à Bearer, MongoDB, PostgreSQL, MySQL ainsi qu’aux protocoles PGP, OpenSSH, RSA.

En outre, il est possible d’appliquer des configurations de sécurité pour des fonctions comme le scan de code, de secrets et de vulnérabilités à des groupes de dépôts. Quant à la gestion des exclusions du contenu généré par Copilot – oui, GitHub fournit les épées et les boucliers – elle est maintenant centralisée au plus haut niveau d’administration.

Pour tous les clients Enterprise cette fois-ci, une fonction de contrôle des clés de déploiement est désormais activée par défaut. Ces clés SSH « sont souvent utilisés par des intégrations avec des serveurs externes pour accéder à un dépôt sans utiliser de compte GitHub personnel ». Problème, il était plus difficile de tracer leur utilisation et il ne dispose pas d’une date d’expiration. Les contrôles permettent de mettre une politique de gestion afin de décider qui peut créer ces clés, interdire leur création et appliquer une règle au niveau de l’organisation. L’éditeur recommande toutefois d’utiliser GitHub Apps pour une supervision plus fine de leur usage.

En parlant de date d’expiration, une fonction en préversion permet aux administrateurs de limiter la durée de vie d’un token d’accès personnel (Personal acess token, PAT) entre 1 et 366 jours. Par défaut, ce paramètre est réglé sur 366 jours dans les comptes entreprise.

Des runners GitHub Actions sous ARM64 largement disponibles en 2025

Voilà pour les quelques fonctionnalités de sécurité lancées par GitHub entre la fin du mois de septembre et ce 31 octobre. Du côté de son service d’exécution de pipelines CI/CD Actions, l’éditeur fournit les mêmes capacités de contrôle d’exécution des runners à tous ses utilisateurs, même ceux qui ne paient pas. Pour les entreprises, une API doit permettre de récolter la télémétrie nécessaire à l’identification des jobs prompts aux erreurs ou trop lents à s’exécuter. En préversion publique, un tableau de bord doit faciliter le suivi de la consommation des API REST.

Enfin, GitHub élargit les tests de ses runners ARM64 (sous Ubuntu 24.04) à tous ses usagers. L’éditeur avait déjà réalisé des tests en désossant des Mac Mini M1 pour les transférer leurs entrailles vers des serveurs et envisageait de s’équiper en serveurs Ampere. Ces instances, dont la filiale de Microsoft promet qu’ils réduisent les coûts d’exécution des jobs CI/CD, seront en disponibilité générale au début de l’année 2025.