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

 (astral.sh)
1 points par GN⁺ 24 일 전 | 1 commentaires | Partager sur WhatsApp
  • 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
  • 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

À lire aussi

1 commentaires

 
GN⁺ 24 일 전
Commentaires sur Hacker News

  • On a l'impression qu'il faut passer par beaucoup trop d'étapes pour utiliser le CI de GitHub en toute sécurité.
    Avec une telle architecture, j'ai l'impression qu'il est impossible de l'exploiter de manière vraiment sûre du point de vue sécurité.
    Construire la sécurité de la chaîne d'approvisionnement sur un système qui ne respecte même pas des principes de base comme la séparation des privilèges ou l'isolation semble voué à l'échec.

    • Je pense pareil. J'ai récemment étudié comment exécuter en toute sécurité du code écrit par un agent dans GitHub Actions, et j'ai obtenu des résultats plutôt corrects avec sandbox-action.
      Mais la configuration est tellement délicate que ça ne ressemble pas à une approche scalable. Ce serait bien mieux si les valeurs par défaut étaient plus sûres.
    • Je me demande si quelqu'un a déjà vu un système de build alternatif valable à la place de ce CI GitHub si complexe.
      Après avoir tout lu, je me dis que cette complexité est peut-être un problème intrinsèque à ce domaine.
    • En réalité, ce n'est pas différent du problème des registres de paquets en général.
      La plupart ne prennent pas en charge les releases immuables, et même lorsqu'ils le font, ils récupèrent automatiquement les nouvelles versions, ce qui les rend vulnérables aux attaques.
      Pour être vraiment sûr, il faudrait gérer dans son propre registre des dépendances vérifiées avec des versions figées, mais c'est le genre de chose que seul Google peut vraiment se permettre.

  • Le binaire uv de stagex que notre équipe a créé est le seul au monde à être construit avec un bootstrap intégral depuis les sources et des artefacts déterministes multi-signés.
    Il utilise un système de signature sur carte à puce relié à un réseau de confiance vieux de 25 ans et à plus de 5 000 clés.
    Ce qui est frustrant, c'est de voir que ce sont les bénévoles qui prennent la sécurité de la chaîne d'approvisionnement le plus au sérieux.

    • Le marché a déjà donné sa réponse : les gens veulent la commodité plutôt que la sécurité.
      Même si des outils comme OpenClaw peuvent faire fuiter des clés et des secrets, les utilisateurs continuent de les utiliser.
      Vous essayez de réduire la surface d'attaque, alors que le marché, lui, l'élargit.
    • En fait, il n'y a pas vraiment de quoi s'agacer. Vous construisez une distribution Linux reproductible, et des partenaires vendent des services de support autour de cela.
      Sans bénévoles, des projets comme Debian n'existeraient pas non plus. Il faut rivaliser avec de meilleurs résultats plutôt qu'avec des plaintes.
    • (Je suis l'auteur de l'article) Le nombre de clés ou leur ancienneté ne sont pas des mesures de confiance.
      Si, au final, vous fournissez des artefacts construits par un tiers, il n'est pas clair quel est exactement le modèle de menace.
      Tous les builds de uv proviennent d'une résolution verrouillée et fournissent des artefacts signés. La valeur de commits signés avec un autre ensemble d'identités n'est pas évidente.
    • La licence open source elle-même est conçue pour que les entreprises puissent l'utiliser gratuitement.
      OpenAI n'a aucune raison particulière de dépenser de l'argent pour renforcer la sécurité de la chaîne d'approvisionnement.
    • L'acquisition ne date que de quelques semaines ; il aurait été plus étrange qu'OpenAI ait déjà modifié le processus de build.
      Je comprends les critiques techniques, mais à ce moment-là, il me semble excessif d'en faire porter la responsabilité à OpenAI.

  • À noter que le Trusted Publishing de PyPI a été mis en œuvre par William Woodruff avec l'équipe de Trail of Bits.

  • J'aimerais poser une question à l'équipe d'Astral. Comment gérez-vous le fait de dépendre aussi fortement de GitHub malgré tous ces efforts ?
    Que faites-vous si GitHub est compromis ou si un bug modifie vos paramètres ?

    • Nous échangeons aussi directement avec GitHub. Comme il s'agit d'une infrastructure critique, nous surveillons de près les changements de la plateforme.
    • GitHub a vraiment beaucoup de bugs. Il n'est pas rare qu'un workflow échoue simplement en essayant de cloner une branche de son propre dépôt.

  • L'écosystème open source est résilient, mais le sandboxing de code tiers reste insuffisant.
    Chaque fois que j'utilise uv, on met en avant la facilité avec laquelle il permet de gérer plusieurs versions de Python, mais cela signifie aussi qu'il s'exécute directement sur la machine hôte sans isolation, ce qui m'inquiète.

    • J'utilise toujours uv dans Docker. Dans ce cas, c'est plutôt pratique.

  • Le grand problème actuel de la chaîne d'approvisionnement, c'est que beaucoup d'outils et de dépendances sont téléchargés sans vérification de provenance.
    C'est pour cela que je développe asfaload, une solution open source de vérification de fichiers multi-signatures.
    C'est une architecture qui pourrait éviter des incidents comme celui d'axios.

    • N'est-ce pas précisément le but des release attestations ? Voir la documentation associée.
    • L'approche me semble aller dans le bon sens. Cela dit, comme le code ou le produit n'est pas encore public, c'est difficile à évaluer.
    • Je pense qu'au lieu de vérifier un auteur en particulier, il vaudrait mieux examiner tout le code avec des outils d'audit de code automatisés.

  • Même si l'on épingle GitHub Actions sur un SHA de commit, cela reste risqué si l'action va ensuite chercher d'autres dépendances.
    La vraie solution, dans un pipeline CI, c'est de posséder directement le code ou de forker puis maintenir soi-même.

    • L'article en parle aussi. Nous adoptons une approche de defense in depth.
      Nous auditons toutes les actions et, s'il y a des dépendances variables, nous les corrigeons ou les remplaçons (je travaille chez Astral).
    • La sécurité est toujours une affaire de compromis.
      Gérer soi-même toute la stack est ce qu'il y a de plus sûr, mais ce n'est pas réaliste.
      Le verrouillage par hash est une amélioration de sécurité quasiment gratuite.
      Au final, l'important est de bien savoir jusqu'où va la confiance que l'on accorde.
    • De toute façon, dès qu'on utilise des actions tierces, il faut lire et vérifier le code soi-même. Le simple fait de forker ne résout pas le problème.

  • Quand on voit les récents incidents autour de Trivy et litellm, il est clair qu'il faut vraiment des guides de sécurité pour les processus de release.
    Les conseils de cet article sont concrets et directement applicables.
    L'essentiel de la sécurité de la chaîne d'approvisionnement dépend du niveau de sûreté des paramètres par défaut des plateformes dont nous dépendons.

  • C'est un excellent aperçu. Cela pourrait servir de référence utile à d'autres projets open source.

  • Je maintiens repomatic, un CLI Python et outil de workflows réutilisables.
    Il intègre par défaut la plupart des pratiques de sécurité décrites dans cet article.
    L'objectif est de créer un environnement où la sécurité est le choix par défaut.
    Après avoir lu l'article, j'ai ajouté une vérification de la politique d'approbation des PR de forks.
    Plus de détails dans le dépôt GitHub.