GitHub Enterprise a changé la façon dont les équipes d'ingénierie collaborent.
C'est rapide, distribué, et profondément intégré dans la façon 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 discrètement quelque chose qui était auparavant gratuit dans un monde sur site, isolé du réseau — la certitude que notre code et nos secrets sont complètement protégés de l'extérieur.

Lorsque tout vivait sur 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 descendre dans le couloir pour débrancher une si nécessaire.
Maintenant, notre propriété intellectuelle la plus précieuse — le code source — vit dans une plate-forme partagée, toujours connectée.
Cela n'est pas intrinsèquement dangereux, mais cela exige un type de discipline différent.

La Nouvelle Réalité : Grande Collaboration, Certitude Évanescente

GitHub est une plate-forme incroyable, mais cela s'accompagne d'un modèle de responsabilité partagée :
GitHub sécurise le service ; nous sommes responsables de tout ce qui s'y connecte — personnes, dispositifs et tokens.

Et ce sont les tokens qui me tiennent éveillé la nuit.

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

Le schéma est cohérent : les attaquants n'ont pas besoin de pénétrer dans GitHub.
Ils volent quelque chose qui est déjà de confiance — un Token d'Accès Personnel, une clé SSH, un certificat 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 un certificat volé.

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

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

Avant le cloud, les organisations soucieuses de la sécurité ont résolu ce problème en isolant les systèmes critiques.
Si vos serveurs Git ou CI/CD n'étaient pas accessibles depuis Internet, les identifiants volés étaient pratiquement inutiles.
Le compromis, bien sûr, était l'agilité. Le travail à distance, l'accès des sous-traitants ou les builds automatisés sont devenus compliqués.

Mais l'isolement nous a enseigné une leçon durable :
il ne s'agit pas seulement de savoir qui est autorisé — il s'agit de l'endroit et de la manière dont 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 cessé de demander :

“Ce dispositif est-il de confiance ?”
“Est-il conforme à notre baseline de sécurité ?”
“Ce token devrait-il même être valide depuis ici ?”

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

Penser en Termes de Zero Trust

Le Zero Trust n'est pas un slogan marketing — c'est un changement de mentalité.
Cela signifie traiter chaque demande, chaque dispositif, chaque certificat comme potentiellement compromis jusqu'à preuve du contraire.
Appliqué au développement logiciel, cela signifie aucun dispositif, token ou utilisateur n'obtient un accès au code source à moins qu'il ne réussisse à passer à la fois la vérification d'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 continuellement à ces deux questions pour GitHub et les environnements CI/CD, sans interrompre 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 qui elle dit être.
Nous vérifions que la machine qu'elle utilise est sécurisée et conforme.
Et nous laissons GitHub et les autres plates-formes appliquer cette décision nativement — à travers leurs listes d'autorisation de dispositifs 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 en utilisant un code PIN à usage unique envoyé à son compte email.
Cette étape de PIN n'est pas cosmétique — c'est la différence entre un attaquant réutilisant un token volé et un utilisateur réel se connectant depuis un compte vérifié.
À moins que l'attaquant ne compromette également l'email de l'utilisateur (qui est déjà fortement protégé par MFA et politiques d'entreprise), l'appareil ne figure jamais sur la liste d'accès.

2. Vérifier la Posture des Dispositifs en Continu

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 rapportent leur posture :
version du système d'exploitation, statut de cryptage, présence d'EDR, pare-feu, niveaux de patch, et autres signaux.
Si une machine sort de la politique — par exemple, si l'antivirus est désactivé ou qu'un patch du noyau est manquant — EDAMAME l retire automatiquement de la liste blanche des dispositifs.
L'accès s'arrête jusqu'à ce que cela soit corrigé.

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

3. Étendre à Tous les Environnements

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

Lorsque quelqu'un utilise l'application mobile GitHub, EDAMAME vérifie que son téléphone respecte les normes de posture d'entreprise avant de l'ajouter à la liste blanche.
Pour CI/CD, notre CLI et l'intégration GitHub Action s'exécutent à l'intérieur du pipeline, vérifiant l'intégrité de l'exécuteur de build avant qu'il ne puisse récupérer le code ou les secrets.
De cette façon, l'environnement CI devient partie des mêmes limites de Zero Trust que les ordinateurs portables des développeurs.

Un Scénario du Monde Réel

Considérons à nouveau le scénario Shai-Hulud.
Un attaquant vole un token GitHub d'un ordinateur portable infecté.
Ils essaient de l'utiliser depuis leur propre machine.

Ils échouent immédiatement.

Pourquoi ? Parce que ce token n'est pas suffisant.
Pour accéder au dépôt, ils auraient également besoin de :

Utiliser un dispositif sur la liste blanche adminérée par EDAMAME, et
S'authentifier par le biais de l'email professionnel du développeur pour recevoir un code PIN à usage unique.

Sans les deux, les contrôles natifs de GitHub — mis à jour dynamiquement par EDAMAME — bloquent simplement la demande.
Même s'ils parviennent à cloner l'environnement du développeur, le manque d'authentification par email vérifiée et l'inadéquation de la posture du dispositif annuleraient immédiatement l'accès.

C'est ce que nous entendons par « goulot virtuel ».
Il ne s'agit pas d'isolement ; il s'agit de vérification continue.

L'Expérience des Développeurs a de l'Importance

La sécurité qui interrompt le travail ne dure pas.
Nous avons appris tôt que les développeurs trouveront un moyen de contourner la friction.
C'est pourquoi EDAMAME fonctionne en mode rapport — il vérifie la posture et guide les développeurs pour résoudre les problèmes, mais ne prend pas le contrôle de leurs appareils.

Nous avons constaté que cette approche suscite réellement la sensibilisation.
Lorsque les développeurs voient un message du type “Votre pare-feu local n est pas activé — cliquez ici pour corriger”, ils réagissent immédiatement.
C'est la sécurité comme collaboration, pas application.

Travailler aux Côtés d'Autres Solutions

Nous ne croyons pas aux solutions miracles.
Le Zero Trust est un système de systèmes.
Notre travail complète des outils comme :

Aembit (aembit.io) pour l'identité machine-à-machine,
Gestionnaires de secrets comme GitGuardian et Doppler, et
Plates-formes ZTNA et Accès Conditionnel comme Azure Entra ou Google Context-Aware Access.

Nous nous intégrons à eux, alimentons leurs données de posture des dispositifs, et les laissons faire ce qu'ils font déjà le mieux.
Ensemble, ils créent un écosystème où les identités humaines et machine sont continuellement vérifiées.

Pourquoi la Conformité Suit Naturellement

Lorsque vous mettez en œuvre le Zero Trust à cette profondeur, la conformité cesse d'être une réflexion après coup.
La vérification continue des dispositifs et la liaison d'identité soutiennent directement les exigences de SOC 2, ISO 27001, PCI-DSS, HIPAA, et NIS2 pour l'accès logique et le développement sécurisé.

Les conversations d'audit deviennent beaucoup plus simples lorsque vous pouvez montrer des preuves en direct :
“Voici la liste des dispositifs conformes actuellement autorisés à accéder à notre code source.”
Plus besoin de captures d'écran ou de révisions manuelles — le système lui-même est la preuve.

Ce que Nous avons Appris

Au cours des dernières années, nous avons constaté que la sécurité dans le développement logiciel moderne ne concerne pas le choix entre agilité et contrôle.
Il s'agit de concevoir des systèmes qui s'adaptent à la même vitesse que vos ingénieurs.

Les systèmes isolés nous ont donné confiance grâce à l'isolement.
Le Zero Trust nous donne confiance grâce à la vérification.
C'est le changement de mentalité dont nous avons besoin si nous voulons continuer à construire de manière ouverte — en toute sécurité.

En savoir plus sur le modèle de Zero Trust que nous appliquons au code source et aux environnements CI/CD sur https://www.edamame.tech et https://github.com/edamametechnologies.
Ou consultez notre guide GitHub pour l'intégration du contrôle d'accès : github.com/edamametechnologies/integrations/wiki/Setting-Up-GitHub-for-Access-Control-Integration.

Frank Lyonnet

Partagez ce post