Pensez à activer les versions immuables sur GitHub pour éviter les problèmes de sécurité

Vous saviez qu’en ce moment, les
attaques sur la supply chain
faisaient des ravages ? En effet, les attaquants exploitent régulièrement la possibilité de modifier des tags existants pour injecter du code malveillant dans les pipelines CI/CD.

Mais heureusement, GitHub a enfin sorti LA fonctionnalité qui peut empêcher ce carnage : les
Immutable Releases
et je pense que c’est le genre de truc que tous les développeurs devraient activer illico sur leurs repos. Je vais vous expliquer pourquoi.

En fait, une fois que vous publiez une release avec cette option activée, plus personne ne peut toucher ni aux assets ni au tag associé. C’est comme si vous mettiez votre release dans un coffre-fort dont vous jetez la clé. Même vous, en tant que mainteneur, vous ne pouvez plus modifier les binaires ou déplacer le tag vers un autre commit.

D’après la documentation officielle
, chaque release immuable génère automatiquement une attestation cryptographique. Cette attestation contient le SHA du commit, le tag et la liste des assets. Vos utilisateurs peuvent vérifier l’intégrité de ce qu’ils téléchargent en s’assurant que cela correspond exactement à ce que vous avez publié.

Pour activer cette option merveilleuse, c’est dans les settings de votre repo ou de votre organisation. Une fois activé, toutes les nouvelles releases deviennent alors automatiquement immuables. Les anciennes releases restent toutefois modifiables (pour éviter de casser vos workflows existants), mais bon, c’est mieux de migrer progressivement.

Attention quand même, il y a quelques pièges à éviter. Premièrement, vous ne pouvez plus ajouter d’assets après publication. Donc si votre CI upload les binaires après avoir créé la release, il faut inverser : Créez d’abord une draft release, uploadez les assets, puis publiez. Deuxièmement, si vous supprimez une release immuable, vous ne pourrez JAMAIS réutiliser le même tag. C’est définitif.

Pour les projets qui utilisent des tags de version majeure style v1 qu’ils mettent à jour régulièrement (coucou GitHub Actions), pas de panique. Vous pouvez continuer à utiliser cette pratique pour les tags qui ne sont pas associés à des releases. L’immuabilité ne s’applique qu’aux releases publiées, pas aux tags simples.

Les équipes de sécurité recommandent
d’ailleurs d’activer cette fonctionnalité sur tous les repos qui publient du code versionné. C’est particulièrement critique pour les bibliothèques open source, les GitHub Actions, et tout ce qui est consommé par d’autres projets. En gros, si votre code finit dans la supply chain de quelqu’un d’autre, vous leur devez cette protection.

Le truc cool aussi, c’est que ça protège contre les erreurs humaines. Combien de fois j’ai vu des mainteneurs qui écrasaient accidentellement une release avec la mauvaise version ? Ou qui supprimaient un asset critique par erreur ? Avec les Immutable Releases, ces accidents appartiennent au passé.

Pour les entreprises, c’est un argument de vente en or. Ça permet de garantir à vos clients que vos releases ne peuvent pas être altérées après publication, c’est un niveau de confiance supplémentaire surtout dans des secteurs régulés où la traçabilité est cruciale.

Bref, GitHub est en train de déployer progressivement cette fonctionnalité en public preview. Pour l’instant, il faut l’activer manuellement pour chaque repo, mais ils travaillent sur une API pour permettre l’activation en masse. D’ici là, prenez donc 2 minutes pour l’activer sur vos projets critiques.

Voilà, après les dégâts causés par les attaques de type tag hijacking ces dernières années, ne pas activer les Immutable Releases sur vos repos publics, c’est comme laisser votre porte d’entrée grande ouverte avant de partir en vacances. Vous pouvez le faire, mais ne venez pas pleurer si ça tourne mal.