Open Source Security at Astral

Astral builds tools that millions of developers around the world depend on and trust.

That trust includes confidence in our security posture: developers reasonably expect that our tools (and the processes that build, test, and release them) are secure. The rise of supply chain attacks, typified by the recent Trivy and LiteLLM hacks, has developers questioning whether they can trust their tools.

To that end, we want to share some of the techniques we use to secure our tools in the hope that they're useful to:

• Our users, who want to understand what we do to keep their systems secure;
• Other maintainers, projects, and companies, who may benefit from some of the techniques we use;
• Developers of CI/CD systems, so that projects do not need to follow non-obvious paths or avoid useful features to maintain secure and robust processes.

We sustain our development velocity on Ruff, uv, and ty through extensive CI/CD workflows that run on GitHub Actions. Without these workflows we would struggle to review, test, and release our tools at the pace and to the degree of confidence that we demand. Our CI/CD workflows are also a critical part of our security posture, in that they allow us to keep critical development and release processes away from local developer machines and inside of controlled, observable environments.

GitHub Actions is a logical choice for us because of its tight first-party integration with GitHub, along with its mature support for contributor workflows: anybody who wants to contribute can validate that their pull request is correct with the same processes we use ourselves.

Unfortunately, there's a flipside to this: GitHub Actions has poor security defaults, and security compromises like those of Ultralytics, tj-actions, and Nx all began with well-trodden weaknesses like pwn requests.

Here are some of the things we do to secure our CI/CD processes:

• We forbid many of GitHub's most dangerous and insecure triggers, such as pull_request_target and workflow_run, across our entire GitHub organization. These triggers are almost impossible to use securely and attackers keep finding ways to abuse them, so we simply don't allow them. Our experience with these triggers is that many projects think that they need them, but the overwhelming majority of their usages are better off being replaced with a less privileged trigger (such as pull_request) or removed entirely.
• We require all actions to be pinned to specific commits (rather than tags or branches, which are mutable). Additionally, we cross-check these commits to ensure they match an actual released repository state and are not impostor commits. We do this in two ways: first with zizmor's unpinned-uses and impostor-commit audits, and again with GitHub's own "require actions to be pinned to a full-length commit SHA" policy.
• We limit our workflow and job permissions in multiple places: we default to read-only permissions at the organization level, and we additionally start every workflow with permissions: {} and only broaden beyond that on a job-by-job basis.
• We isolate our GitHub Actions secrets, wherever possible: instead of using organization- or repository-level secrets, we use deployment environments and environment-specific secrets. This allows us to further limit the blast radius of a potential compromise.

Beyond our CI/CD processes, we also take a number of steps to limit both the likelihood and the impact of account and repository compromises within the Astral organization:

• We limit the number of accounts with admin- and other highly-privileged roles, with most organization members only having read and write access to the repositories they need to work on.
• We enforce strong 2FA methods for all members of the Astral organization, beyond GitHub's default of requiring any 2FA method. In effect, this requires all Astral organization members to have a 2FA method that's no weaker than TOTP.
• We impose branch protection rules on an org-wide basis: changes to main cannot be force-pushed and must always go through a pull request.
• We impose tag protection rules that prevent release tags from being created until a release deployment succeeds, with the release deployment itself being gated on a manual approval by at least one other team member. We also prevent the updating or deletion of tags, making them effectively immutable once created.
• Finally, we ban repository admins from bypassing all of the above protections. All of our protections are enforced at the organization level, meaning that an attacker who manages to compromise an account that has admin access to a specific repository still won't be able to disable our controls.