La stratégie de sécurité open source complète dévoilée par Astral, créateur de Ruff et uv
(astral.sh)Astral développe des outils dont dépendent des millions de développeurs dans le monde (Ruff, uv, ty) et, à la suite récente des attaques contre la chaîne d’approvisionnement visant Trivy et LiteLLM, a dévoilé ses pratiques de sécurité. Le public visé se divise en trois catégories : les utilisateurs, les autres mainteneurs open source et les développeurs de systèmes CI/CD.
1. Sécurité CI/CD
Les paramètres de sécurité par défaut de GitHub Actions sont fragiles, et les compromissions d’Ultralytics, de tj-actions et de Nx proviennent toutes de déclencheurs risqués comme pull_request_target. La réponse d’Astral est la suivante :
Interdiction totale des déclencheurs dangereux
Les déclencheurs comme pull_request_target et workflow_run, quasiment impossibles à utiliser de manière sûre, sont interdits à l’échelle de toute l’organisation. La plupart des projets pensent avoir besoin de ces déclencheurs, mais dans les faits, un déclencheur pull_request aux permissions plus limitées ou de simples logs de workflow suffisent dans la majorité des cas.
Épinglage des hash de commit des actions (hash pinning)
Au lieu d’utiliser des tags ou des branches (modifiables), Astral épingle les actions à un SHA de commit précis et vérifie de façon croisée que ce commit correspond bien à l’état réel de la release, afin d’éviter les « imposter commits ». Astral combine zizmor et la politique native de GitHub, et applique cet épinglage des hash à toutes les actions imbriquées appelées indirectement.
Principe du moindre privilège
Au niveau de l’organisation, les permissions par défaut sont définies en lecture seule, et tous les workflows commencent par permissions: {} avant d’ajouter uniquement les permissions nécessaires au niveau des jobs. Les secrets, eux aussi, sont isolés par environnement de déploiement plutôt qu’au niveau de l’organisation ou du dépôt, afin qu’un job de test ne puisse pas accéder aux secrets de release.
2. Sécurité des dépôts et de l’organisation
Le nombre d’administrateurs et de comptes à privilèges élevés est réduit au minimum, et la plupart des membres de l’organisation n’ont que des droits de lecture/écriture sur les dépôts dont ils ont besoin. La 2FA exige au minimum un TOTP, plus robuste que le réglage par défaut de GitHub (quelle que soit la méthode), et Astral prévoit à terme de renforcer cela en n’autorisant que WebAuthn et les passkeys.
La branche main est protégée contre les force push et exige des pull requests, tandis que des règles de protection imposent que les tags de release ne puissent être créés qu’après le succès du déploiement. Surtout, ces règles sont imposées au niveau de l’organisation pour que même les administrateurs du dépôt ne puissent pas les contourner.
3. Automatisation (via GitHub App)
Les tâches qu’il n’est pas possible d’effectuer de manière sûre dans GitHub Actions, comme laisser un commentaire sur une PR tierce, sont séparées dans la GitHub App astral-sh-bot. Astral souligne toutefois qu’une GitHub App n’est pas exempte de vulnérabilités et que, lorsqu’il faut exécuter du code non fiable, il faut impérativement utiliser le déclencheur pull_request.
4. Sécurité des releases
Pour PyPI, crates.io et NPM, Astral utilise Trusted Publishing afin de publier sans identifiants de longue durée, et joint aux binaires ainsi qu’aux images Docker des attestations basées sur Sigstore pour fournir un lien cryptographique entre les artefacts de release et les workflows.
Astral utilise la fonctionnalité de releases immuables (immutable releases) de GitHub pour empêcher toute altération a posteriori des builds publiés, et interdit l’utilisation du cache pendant les builds de release afin de bloquer les attaques de type cache poisoning.
Le processus de release lui-même est aussi protégé à double tour : l’activation de l’environnement de release nécessite l’approbation manuelle d’au moins un autre membre autorisé de l’organisation. Autrement dit, pour produire une release malveillante, il faudrait compromettre simultanément deux comptes protégés par une 2FA forte.
5. Sécurité des dépendances
Astral s’appuie sur Dependabot et Renovate pour gérer les mises à jour de dépendances et les alertes sur les vulnérabilités connues, tout en appliquant une politique de « cooldown » qui évite de mettre à jour immédiatement après une nouvelle release. L’objectif est de minimiser l’impact de dépendances compromises temporairement. Cette fonctionnalité est intégrée à uv.
Astral entretient des liens avec des projets et groupes de travail voisins comme la Python Packaging Authority (PyPA) et la Python Security Response Team afin de partager l’information, par exemple lorsqu’un problème signalé à pip peut aussi affecter uv. L’ajout de nouvelles dépendances est abordé avec prudence, les dépendances contenant des blobs binaires sont évitées, et les fonctionnalités inutiles sont désactivées.
Astral poursuit aussi ses contributions financières via OSS Fund pour soutenir la durabilité des projets dont il dépend.
Résumé des recommandations clés
Astral met en avant quatre principes majeurs : reconnaître les limites de la CI/CD et renoncer sans hésiter aux tâches qui ne peuvent pas être sécurisées, ou les isoler dans une GitHub App ; supprimer autant que possible les identifiants de longue durée et les isoler au périmètre minimal ; renforcer le processus de release avec des environnements de déploiement, des validations et des tags immuables ; et surveiller en continu l’état de santé de l’ensemble de l’arbre des dépendances.
Enseignements
Du point de vue de quelqu’un impliqué de près dans PyPI et la sécurité de la chaîne d’approvisionnement, ce texte dépasse le simple guide de sécurité : il montre concrètement comment concevoir l’architecture de confiance de tout l’écosystème open source. En particulier, Trusted Publishing, la politique de cooldown et le processus de release à double approbation constituent des références utiles pour tout projet open source d’une certaine envergure.
Texte original : Astral Blog, 2026.04.08
Aucun commentaire pour le moment.