GitHub abandonne SHA-1 : sécuriser vos intégrations

La fin de SHA-1 sur GitHub est effective pour HTTPS depuis le 15 septembre 2026. Pour la plupart des équipes, rien ne change. Le bon réflexe consiste toutefois à identifier les environnements qui s’appuient encore sur une pile TLS ou un magasin de certificats ancien : ce sont eux qui risquent de transformer une dépendance oubliée en blocage de livraison.

Ce que GitHub a réellement changé

GitHub a annoncé la désactivation de SHA-1 pour HTTPS sur github.com et ses CDN partenaires. GitHub Enterprise Server n’est pas concerné par ce changement. Il ne s’agit pas d’une modification des dépôts Git ni d’une demande de remplacer toutes les signatures de commit : le périmètre publié concerne la négociation HTTPS et les certificats qui utilisent encore cet algorithme ancien.

Les navigateurs et systèmes récents utilisent déjà des chaînes compatibles. Le risque se concentre plutôt sur les images de CI conservées longtemps, les appareils d’entreprise peu mis à jour, les proxys TLS interceptants et certains outils embarqués. Une intégration qui fonctionne sur le poste d’un développeur peut donc échouer sur un runner, derrière un proxy ou chez un partenaire.

Préparer une vérification courte et utile

Cette évolution est une bonne occasion de documenter les dépendances réelles autour de vos livraisons. L’objectif n’est pas de lancer un audit cryptographique démesuré, mais de rendre les points de passage critiques explicites et reproductibles.

Cibler les chemins qui publient ou récupèrent du code

1. Lister les exécutants : runners CI, machines de release, serveurs de déploiement, scripts d’installation et postes gérés qui se connectent à GitHub.
2. Vérifier le chemin réseau : repérer les proxys d’entreprise, inspections TLS et magasins de certificats personnalisés. Ils peuvent être la cause d’un échec, même si le client Git est à jour.
3. Tester une action représentative : clone, récupération de dépendance ou publication depuis chaque environnement critique. Conserver le journal d’erreur et la version de l’outil facilite le diagnostic.
4. Mettre à jour avec une sortie contrôlée : remplacer l’image, le système ou le certificat concerné ; puis rejouer le même parcours avant de modifier les règles de sécurité.

Éviter les faux correctifs

Désactiver la vérification des certificats pour « débloquer » une pipeline n’est pas un correctif acceptable : cela masque l’origine du problème et diminue la protection de la chaîne de livraison. De même, un échec HTTPS ne prouve pas immédiatement que SHA-1 est en cause. Il faut d’abord isoler l’environnement, le proxy éventuel et la chaîne de certificats réellement présentée.

Une équipe gagne en fiabilité lorsqu’elle associe chaque automatisation à une image maintenue, une procédure de mise à jour et un test de connectivité simple. Cette routine sert aussi pour d’autres évolutions de plateforme : la sécurité devient un élément observable du produit, plutôt qu’une correction urgente le jour d’une panne.

Une décision à intégrer à la maintenance produit

L’annonce officielle de GitHub confirme que la désactivation est désormais appliquée. Planifiez un contrôle ciblé sur vos environnements de build plutôt que d’attendre un incident : vous saurez quels composants doivent être renouvelés et lesquels sont déjà conformes.