GitHub Enterprise a changé la façon dont les équipes d'ingénierie collaborent.
C'est rapide, distribué et profondément intégré à la manière dont nous construisons et expédions des logiciels aujourd'hui.
Mais alors que de plus en plus d'organisations migrent vers le cloud, nous perdons en silence quelque chose qui était autrefois gratuit dans un monde sur site, isolé — la certitude que notre code et nos secrets sont complètement protégés de l'extérieur.

Lorsque tout se trouvait dans un serveur Git local ou un centre de données que nous contrôlions, le périmètre de sécurité était clair.
Nous savions exactement quelles machines pouvaient communiquer avec la source, et nous pouvions nous rendre dans le couloir pour débrancher l'une d'elles si nécessaire.
Maintenant, notre propriété intellectuelle la plus précieuse — le code source — vit dans une plateforme partagée et toujours connectée.
Ce n'est pas intrinsèquement dangereux, mais cela exige un type de discipline différent.

La Nouvelle Réalité : Grande Collaboration, Certitude Disparue

GitHub est une incroyable plateforme, mais avec elle vient un modèle de responsabilité partagée :
GitHub sécurise le service ; nous sommes responsables de tout ce qui y est connecté — personnes, dispositifs et jetons.

Et ce sont les jetons qui m'empêchent de dormir la nuit.

Nous avons tous vu les gros titres.
En 2024, un seul jeton GitHub volé a donné aux attaquants accès à plus de 5 000 dépôts privés du New York Times (Cloud Security Alliance).
Le ver de chaîne d'approvisionnement Shai-Hulud s'est répandu via des paquets npm, exfiltrant des jetons et des secrets depuis les machines des développeurs (Unit42 Research).
Et lorsque le compte GitHub de Toptal a été compromis, les attaquants ont utilisé cet accès pour injecter du code malveillant et effacer les machines des développeurs (The Hacker News).

Le schéma est constant : les attaquants n'ont pas besoin de pirater GitHub.
Ils volent quelque chose qui est déjà de confiance — un jeton d'accès personnel, une clé SSH, une credential CI — et l'utilisent de n'importe où.
La plupart des systèmes d'identité ne peuvent pas faire la différence entre un utilisateur légitime et un imposteur utilisant une credential volée.

C'est la menace moderne de la chaîne d'approvisionnement en une phrase.

Pourquoi les Systèmes Isolés Nous Apprennent Encore Quelque Chose

Avant le cloud, les organisations soucieuses de la sécurité résolvaient cela en isolant les systèmes critiques.
Si vos serveurs Git ou CI/CD n'étaient pas accessibles depuis Internet, les credentials volées étaient pratiquement inutiles.
Le compromis, bien sûr, était l'agilité. Le travail à distance, l'accès des contractants ou les constructions automatisées devenaient compliqués.

Mais l'isolement nous a appris une leçon durable :
ce n'est pas seulement une question de qui est autorisé — c'est une question de où et comment l'accès se produit.

Lorsque nous sommes passés à GitHub Enterprise Cloud, la plupart des équipes ont conservé la discipline de l'identité (SSO, MFA, Okta, Entra, etc.), mais nous avons perdu le contexte.
Nous avons arrêté de demander :

« Cet appareil est-il digne de confiance ? »
« Est-il conforme à notre baseline de sécurité ? »
« Ce jeton doit-il même être valide d'ici ? »

Ces questions définissent le nouveau périmètre.

Pensée en Termes de Zero Trust

Le Zero Trust n'est pas un slogan marketing — c'est un changement de mentalité.
Il signifie traiter chaque demande, chaque appareil, chaque credential comme potentiellement compromis jusqu'à preuve du contraire.
Appliqué à la développement logiciel, cela signifie aucun dispositif, jeton ou utilisateur n'obtient l'accès au code source à moins qu'il ne réussisse à la fois la vérification de l'identité et la vérification de posture.

C'est là que nous avons concentré notre travail chez EDAMAME : construire un système qui répond en continu à ces deux questions pour les environnements GitHub et CI/CD, sans perturber les flux de travail des développeurs.

Notre approche est simple en principe :

Nous vérifions que la personne essayant d'accéder au code est réellement celle qu'elle prétend être.
Nous vérifions que la machine qu'elle utilise est sécurisée et conforme.
Et nous laissons GitHub et les autres plateformes appliquer cette décision de manière native — grâce à leurs listes blanches d'appareils et d'IP existantes.

Aucun proxy. Aucun tunnel réseau magique. Juste une orchestration intelligente des contrôles qui existent déjà.

Comment Nous le Faisons en Pratique

1. Lier l'Identité à un Utilisateur Réel

Lorsqu'un développeur rejoint un projet, EDAMAME lie son accès à son identité d'entreprise à l'aide d'un PIN à usage unique envoyé à son compte de messagerie.
Cette étape de PIN n'est pas cosmétique — elle fait la différence entre un attaquant réutilisant un jeton volé et un utilisateur réel se connectant à partir d'un compte vérifié.
À moins que l'attaquant ne compromette également l'e-mail de l'utilisateur (qui est déjà fortement protégé par MFA et les politiques d'entreprise), l'appareil ne figure jamais sur la liste d'accès.

2. Vérification Continue de la Posture des Dispositifs

Chaque ordinateur portable de développeur, chaque exécuteur CI et même chaque appareil mobile qui touche GitHub ou un système CI/CD reporte sa posture :
version du système d'exploitation, statut de chiffrement, présence de l'EDR, pare-feu, niveaux de patchs et autres signaux.
Si une machine sort de la politique — par exemple, si l'antivirus est désactivé ou si un patch de noyau manque — EDAMAME l'enlève automatiquement de la liste blanche des dispositifs.
L'accès est stoppé jusqu'à ce que cela soit réparé.

GitHub Enterprise, Azure Entra ou votre solution ZTNA applique cela en temps réel.
Le résultat : seuls les appareils conformes appartenant à des utilisateurs vérifiés peuvent interagir avec vos dépôts.

3. Extension à Tous les Environnements

Les développeurs travaillent sur toutes les plateformes imaginables :
Windows, macOS, Linux, mobile (iOS/Android), et les exécuteurs CI/CD conteneurisés sur x86 et ARM.
Les mêmes principes s'appliquent partout.

Lorsqu'une personne utilise l'application mobile GitHub, EDAMAME vérifie que son téléphone répond aux normes de posture de l'entreprise avant de l'ajouter à la liste blanche.
Pour le CI/CD, notre CLI et l'intégration GitHub Action fonctionnent dans le pipeline, vérifiant l'intégrité de l'exécuteur de construction avant qu'il ne puisse récupérer du code ou des secrets.
De cette façon, l'environnement CI devient partie intégrante de la même frontière Zero Trust que les ordinateurs portables des développeurs.

Un Scénario Réel

Considérons à nouveau le scénario Shai-Hulud.
Un attaquant vole un jeton GitHub d'un ordinateur portable infecté.
Il essaie de l'utiliser depuis sa propre machine.

Il échoue immédiatement.

Pourquoi ? Parce que ce jeton n'est pas suffisant.
Pour accéder au dépôt, il lui faudrait également :

Utiliser un appareil sur la liste blanche gérée par EDAMAME, et
S'authentifier via l'e-mail professionnel du développeur pour recevoir un PIN à usage unique.

Sans les deux, les contrôles natifs de GitHub — mis à jour dynamiquement par EDAMAME — bloquent simplement la demande.
Même s'il clonait d'une manière ou d'une autre l'environnement du développeur, l'absence d'authentification d'e-mail vérifiée et la posture de l'appareil non correspondante révoqueraient l'accès instantanément.

C'est ce que nous entendons par

Frank Lyonnet

Partagez ce post