La stratégie de sécurité open source d’Astral

• Astral, qui développe des outils comme Ruff, uv et ty utilisés par des développeurs du monde entier, fait de la sécurité et de la fiabilité de tous ses produits une valeur centrale
• Face à la récente hausse des attaques de la chaîne d’approvisionnement, l’entreprise a publié ses méthodes internes pour renforcer la sécurité sur l’ensemble du processus de build, de déploiement et de release
• Dans son CI/CD basé sur GitHub Actions, elle applique une protection multicouche avec épinglage par hash, privilèges minimaux et séparation des secrets
• Au stade de la release, elle garantit l’intégrité de la distribution avec Trusted Publishing, les attestations Sigstore et les Immutable Releases
• À travers cette approche, Astral vise à élever le niveau de sécurité de l’ensemble de l’écosystème open source et à construire un dispositif de défense durable

---

L’approche d’Astral en matière de sécurité open source

• Astral développe des outils comme Ruff, uv et ty, utilisés par des millions de développeurs dans le monde, et fait de leur sécurité et fiabilité une valeur fondamentale
• Alors que les attaques de la chaîne d’approvisionnement se multiplient, comme l’ont montré les piratages récents de Trivy et LiteLLM, Astral a publié ses techniques internes pour garantir la sécurité de ses outils ainsi que de ses processus de build et de déploiement
• L’entreprise partage ainsi des bonnes pratiques de sécurité utiles aux utilisateurs, aux mainteneurs open source et aux développeurs de systèmes CI/CD

Sécurité du CI/CD

• Astral automatise le développement et le déploiement via des workflows CI/CD étendus fondés sur GitHub Actions, qu’elle considère comme un composant clé de sa sécurité
  • Les builds et les tests sont ainsi exécutés dans un environnement contrôlé et observable, et non en local
• Consciente que les paramètres de sécurité par défaut de GitHub Actions sont faibles, elle applique les renforcements suivants
  • interdiction totale des triggers dangereux comme pull_request_target et workflow_run
  • épinglage de toutes les actions sur un hash de commit (SHA) précis, avec vérification croisée pour détecter les impostor commits
  • usage combiné de zizmor pour les audits unpinned-uses et impostor-commit, ainsi que des politiques GitHub
  • épinglage par hash de l’ensemble du graphe de dépendances, y compris les actions indirectes qu’il n’est pas possible d’épingler directement
• L’épinglage par hash ne suffisant pas à lui seul, Astral procède à des revues manuelles pour détecter les failles d’immuabilité et, si nécessaire, travaille avec les projets amont pour les corriger
  • Exemple : mapper les URL de téléchargement de binaires à leurs hashes pour les intégrer de manière immuable
• Les permissions des workflows sont limitées en lecture seule par défaut, et seuls les privilèges minimaux nécessaires sont accordés à chaque job
• Les GitHub Secrets sont gérés comme des variables d’environnement de déploiement séparées par environnement, afin que les tâches de test et de lint n’aient pas accès aux secrets de release
• Comme outils auxiliaires, Astral utilise zizmor (analyse statique) et pinact (épinglage automatique par hash)

Sécurité des dépôts et de l’organisation

• Astral réduit au minimum le nombre de comptes disposant de privilèges administrateur dans l’organisation, et la plupart des membres n’ont des droits de lecture/écriture que sur les dépôts nécessaires
• Tous les membres doivent utiliser une authentification à deux facteurs (2FA) forte, avec au minimum un niveau TOTP
  • Si GitHub n’autorise plus que les méthodes résistantes au phishing (WebAuthn, Passkeys), la transition sera immédiate
• Des règles de protection des branches sont appliquées à l’échelle de toute l’organisation
  • sur la branche main, les force push sont interdits et toutes les modifications doivent passer par des PR
  • la création de certains motifs de branches comme advisory-* ou internal-* est interdite
• Des règles de protection des tags garantissent qu’un tag ne peut être créé qu’après le succès du déploiement d’une release
  • modification et suppression des tags interdites, releases possibles uniquement depuis la branche main
• Même les administrateurs des dépôts ne peuvent pas contourner les règles de protection : elles sont imposées au niveau de l’organisation
• Astral publie cet ensemble de règles sous forme de gist afin que d’autres projets puissent s’en inspirer

Automatisation

• Avec GitHub Actions, certaines tâches comme laisser un commentaire sur une PR tierce ne peuvent pas être effectuées en toute sécurité
• Pour cela, Astral utilise la GitHub App astral-sh-bot afin de traiter certains événements en dehors d’Actions, de manière sécurisée
  • La GitHub App reçoit les mêmes données d’événement, mais s’exécute dans un environnement où le code et les données sont séparés
• Cela ne signifie pas pour autant que l’App supprime les identifiants sensibles
  • Des vulnérabilités comme les SQLi ou les injections de prompt peuvent exister ; il faut donc la développer avec le même niveau d’exigence de sécurité qu’un logiciel classique
  • L’usage d’une GitHub App ne signifie pas automatiquement que l’exécution de code non fiable est sûre
• L’approche par GitHub App est avantageuse sur le plan de la sécurité, mais elle accroît la complexité
  • il faut développer et héberger l’App, ce qui peut représenter une charge pour les développeurs individuels ou les petits projets
  • le framework Python Gidgethub simplifie ce développement
• Astral prévoit de publier astral-sh-bot en open source et recommande comme ressource la documentation de Mariatta

Sécurité des releases

• Les outils d’Astral sont distribués non seulement via GitHub, mais aussi sur PyPI, Homebrew et sous forme d’images Docker, entre autres canaux
• Pour prévenir les attaques de la chaîne d’approvisionnement, les mesures suivantes sont mises en œuvre
  • utilisation de Trusted Publishing pour supprimer les identifiants de registre
  • création d’attestations basées sur Sigstore afin de garantir le lien cryptographique entre les artefacts de build et les workflows
    • recours à la fonction Immutable Releases de GitHub pour empêcher toute modification après publication
    • désactivation du cache de build afin d’éviter les attaques par empoisonnement du cache
    • isolement du processus de release dans un environnement de déploiement dédié
    • activation de l’environnement de release soumise à l’approbation d’un autre membre de l’équipe, pour éviter qu’un seul compte compromis ne permette une release malveillante
    • maintien d’une approbation à plusieurs niveaux avec l’environnement release-gate et un relais d’approbation basé sur une GitHub App
    • les tags ne peuvent être créés qu’après le succès de la release
    • le standalone installer vérifie l’intégrité des binaires grâce à des checksums intégrés
    • après la release, les mises à jour de la documentation, des manifests de version et des hooks pre-commit sont effectuées via un compte bot dédié et des PAT finement cloisonnés
    • ajout prévu à l’avenir de la signature de code pour macOS et Windows

Sécurité des dépendances

• Astral utilise Dependabot et Renovate pour gérer les mises à jour de dépendances et les alertes de vulnérabilité
• Une période de cooldown retarde les mises à jour juste après une nouvelle release afin de réduire le risque d’attaques temporaires sur la chaîne d’approvisionnement
  • Renovate prend en charge des cooldowns par groupe, avec un assouplissement pour les dépendances internes
• Astral mène une collaboration continue et des contributions de sécurité auprès de projets amont importants
  • Exemple : contribution au renforcement de la sécurité CI/CD de apache/opendal-reqsign
• L’entreprise collabore avec la Python Packaging Authority et la Python Security Response Team pour partager des informations de sécurité
• L’ajout de nouvelles dépendances est examiné avec prudence, avec un effort continu pour supprimer celles qui sont inutiles
  • en particulier, évitement des dépendances contenant des blobs binaires et désactivation des fonctionnalités superflues
• Via l’OSS Fund, Astral apporte un soutien financier à des projets open source essentiels

Conclusion et enseignements clés

• La sécurité open source est un ensemble de problèmes à la fois techniques et sociaux, qui exige une réponse continue
• Principes clés mis en avant par Astral
  • reconnaître les limites du CI/CD et, quand c’est inévitable, utiliser une isolation externe comme les GitHub Apps
  • supprimer et minimiser les identifiants de longue durée, en s’appuyant sur Trusted Publishing et l’authentification OIDC
  • renforcer le processus de release avec des règles d’approbation, de tags et de branches, ainsi qu’avec Immutable Releases
  • garder une conscience active des dépendances et renforcer aussi la sécurité des projets amont grâce aux outils et à la coopération
• Astral continuera d’évaluer et d’améliorer ces techniques, avec une évolution de son dispositif de défense au rythme des changements dans les méthodes des attaquants

Résumé des notes

• La PEP 740 de PyPI autorise l’envoi d’attestations, mais elle n’est pas encore compatible avec l’implémentation actuelle de Trusted Publishing chez Astral, donc son adoption est en attente
• Les checksums dans les scripts d’installation ont une efficacité limitée lors d’une exécution directe via curl ... | bash, mais ils sont utiles lorsqu’ils sont vendorisés dans un pipeline CI/CD