La faille des jetons : Pourquoi même les solutions de confiance des appareils les plus récentes manquent toujours une lacune critique dans le SDLC.

Les IdPs modernes et les produits de confiance des dispositifs—JumpCloud, Okta/Microsoft Entra, 1Password Gestion d’Accès Étendu (Kolide)—ont poussé le Zero‑Trust bien au-delà du périmètre. Ils vérifient qui vous êtes, vérifient quel appareil vous utilisez, puis vous donnent un feu vert pour vous connecter.

Mais dès qu'un développeur échanger le UI web pour un git clone, cette confiance s'effondre. Les propres docs de GitHub sont clairs :

“Après avoir autorisé un jeton d'accès personnel ou une clé SSH, le jeton ou la clé restera autorisé jusqu'à sa révocation.” GitHub DocsGitHub Docs

Cette unique phrase explique pourquoi les adversaires ciblent les serveurs de construction et les ordinateurs portables des développeurs, et non les pages de connexion. Ci-dessous, nous examinons comment les meilleures solutions de confiance des dispositifs d'aujourd'hui laissent encore cette faille de jeton largement ouverte — et comment EDAMAME la comble sans perturber le flux des développeurs.

1. Comment fonctionne la confiance des dispositifs aujourd'hui (et où elle s'arrête)

Conclusion : Les trois catégories excellent au moment de la connexion ; aucune ne vérifie l'appareil chaque fois que le code bouge.

2. La réalité du jeton GitHub

GitHub SSO vous force à “Configurer SSO” lorsque vous créez un jeton d'accès personnel ou ajoutez une clé SSH — mais seulement une fois. Après cela :

• Le jeton d'accès personnel/la clé est valide depuis n'importe quelle IP, sur n'importe quelle machine, jusqu'à son expiration ou si vous la révoquez manuellement.

• Aucun défi MFA, aucune inspection des dispositifs, et surtout aucun contexte IdP à chaque utilisation.

• Le même modèle s'applique aux jetons de déploiement de GitLab et à de nombreux secrets CI.

Les attaquants le savent. Ils hameçonnent ou exfiltrent les jetons des développeurs, les déposent sur un VPS jetable, et siphonnent le code sans être détectés.

3. Pourquoi 1Password/Kolide & amis ratent encore le coche

JumpCloud & Okta/Microsoft Entra

Ces plateformes émettent un certificat de dispositif et le vérifient pendant que le navigateur communique avec l'IdP. Une fois que Git utilise HTTPS+PAT ou SSH sur le port 22, l'IdP est hors du chemin.

1Password Gestion d'Accès Étendu (Kolide)

L'agent de Kolide impose la conformité et peut bloquer l'écran de connexion Okta sur un ordinateur portable non conforme Kolide, 1password.com. Excellente expérience utilisateur, mais toujours lié à la même fenêtre SSO web. Lorsque votre runner CI réutilise le PAT d'hier soir, Kolide n'est pas invoqué.

Résultat

Peu importe combien la technologie de confiance des dispositifs est nouvelle, si elle se trouve uniquement lors du SSO, elle ne peut pas arrêter :

• Un jeton d'accès personnel divulgué dans les logs CI

• Un ingénieur copiant son ~/.ssh/id_ed25519 sur un bureau personnel

• Des recherches de code malveillantes depuis un ordinateur portable infecté mais auparavant conforme

4. La couche EDAMAME : Confiance des dispositifs après le jeton

EDAMAME s'intègre sur l'hôte Git lui-même :

1. Liste d'IP dynamique autorisée

   • Interagit avec les API de GitHub Enterprise (et GitLab).

   • Ajoute l'IP publique d'un dispositif uniquement s'il vient de passer un scan de posture en temps réel (niveau de patch, AV, pare-feu, intégrité OS).

   • Supprime l'IP au moment où la posture échoue.

2. Application des règles conscientes des jetons

   • GitHub/GitLab évaluent la liste autorisée avant de toucher aux informations d'identification.

   • Un jeton d'accès personnel ou une clé SSH provenant d'une IP non autorisée retourne un HTTP 403 — neutralisant instantanément les secrets divulgués.

3. Amical pour BYOD, pas de gros MDM

   • Agent léger en lecture seule ou script sans agent rapporte la posture.

   • Les contractuels sur du matériel personnel peuvent rejoindre sans prise de contrôle complète de l'appareil.

5. Matrice de capacité (Zoom avant)

6. Flux du monde réel

1. Le développeur se connecte à GitHub → JumpCloud/Okta/1Password vérifient l'identité & l'appareil.

2. Le développeur crée un PAT pour CI → GitHub demande une fois pour SSO ; le PAT vit maintenant pour toujours. GitHub Docs

3. Le PAT fuit vers le VPS attaquant → L'IdP ne voit jamais le trafic.

4. EDAMAME actif ?

   • IP VPS non sur la liste autorisée → GitHub refuse.

   • L'ordinateur portable compromis sort de la conformité → EDAMAME supprime son IP ; le prochain git push échoue jusqu'à ce que ce soit corrigé.

7. Points à retenir pour les équipes de sécurité et DevOps

• La confiance des dispositifs lors de la connexion ≠ confiance des dispositifs pour les opérations Git.

• Tous les principaux IdP/MDM—JumpCloud, Okta/Entra, 1Password EAM/Kolide—partagent cette lacune car les informations d'identification Git survivent à la session SSO.

• EDAMAME relie le dernier kilomètre, forçant chaque octet de code à voyager uniquement entre des points de terminaison sécurisés et conformes—même dans des emplois CI sans interface, même avec des clés à longue durée de vie.

• Déployez EDAMAME aux côtés de vos solutions existantes IdP et dispositifs ; vous ne les remplacez pas, vous les renforcez.

Fermez la faille des tokens—transformez la rhétorique du Zero‑Trust en réalité dans le SDLC.