# Open Source Security at Astral

Astral (the company behind Ruff, uv, and ty) documents their full [[supply-chain-security]] posture: how they lock down GitHub Actions, protect releases, manage dependencies, and handle the social side of open source security. The post is unusually concrete — not principles but specific controls, tools, and configurations that other projects can copy.

## CI/CD: assume GitHub Actions is hostile

GitHub Actions has poor security defaults. The Ultralytics, tj-actions, and Nx compromises all exploited well-known weaknesses. Astral's response is defense in depth across every layer.

**Ban dangerous triggers.** `pull_request_target` and `workflow_run` are forbidden organization-wide. Both expose privileged credentials to code paths that can be influenced by external contributors. For tasks that seem to need these triggers (like commenting on external PRs), Astral uses a custom GitHub App instead.

**Pin actions to commit SHAs.** Mutable tags mean an upstream compromise can silently change what code runs in your workflows. Astral pins every action to a full-length commit hash, enforced by GitHub policy and audited with zizmor's `unpinned-uses` and `impostor-commit` checks. pinact automates the pinning.

But hash-pinning has a gap: the pinned action's code might itself download a latest binary without verification. Astral works with upstreams to embed cryptographic hashes mapping download URLs to specific binaries, closing the mutability chain.

**Minimal permissions.** Every workflow starts with `permissions: {}` and broadens only per-job. Organization defaults are read-only.

**Secret isolation.** No org-level or repo-level secrets. Everything lives in deployment environments with environment-specific secrets, limiting blast radius if one environment is compromised.

## Releases: eliminate long-lived credentials

The release pipeline is where a compromised account causes the most damage — it's the path to shipping malicious code to users.

**Trusted Publishing** replaces long-lived registry tokens for PyPI, crates.io, and NPM. The registry trusts the CI identity (via OIDC) rather than a stored secret. No token to steal.

**Sigstore attestations** create cryptographic links between built artifacts and the workflow that produced them. Users can verify that a binary was actually built by Astral's CI, not by an attacker who pushed a tag.

**Immutable releases** prevent modifying artifacts after publication. The Trivy attack used tag force-pushing to replace a legitimate release with a compromised one — immutable releases block this vector.

**No release caching.** Build caches during releases are disabled to prevent cache poisoning attacks.

**Multi-person approval.** Release environment activation requires sign-off from another privileged org member. For large repos like uv with many release jobs, a `release-gate` environment with deployment protection rules mediates the approval without requiring it per-job.

**Tag protection.** Release tags can't be created until the release deployment succeeds, and become immutable once created. Attackers can't bypass the pipeline by creating a tag directly.

## Dependencies: cooldowns and relationships

**Dependency cooldowns** are the most interesting practice here. Astral deliberately delays updating after a new upstream release, because the window right after release is when temporarily compromised versions are most dangerous. Renovate supports per-group cooldown configuration — relaxed for first-party dependencies, strict for third-party. uv itself has built-in cooldown support.

Beyond tooling, Astral maintains social relationships with upstream maintainers, contributes security fixes to their CI/CD (e.g., apache/opendal-reqsign), and participates in the Python Packaging Authority and Python Security Response Team. The argument is that supply chain security is partly a social problem — knowing your upstreams and helping them helps you.

New dependencies are added conservatively. Binary blob dependencies are avoided. Unnecessary features are disabled at the dependency level. The OSS Fund provides financial support to upstream projects.

## GitHub Apps as a security boundary

When CI/CD can't safely handle a task (like interacting with external PRs), Astral offloads to astral-sh-bot, a custom GitHub App. The App receives the same webhook data as Actions but runs in a separate environment that doesn't mix code execution with credential access. This is defense in depth, not a silver bullet — the App's code is still vulnerable to injection attacks if written carelessly.

## See also

- [[supply-chain-security]] — the broader concept
- [[hazmat]] — a different approach to constraining tool behavior (sandboxing AI agents on macOS)
- [[if-ai-writes-your-code-why-use-python]] — Mitchem cites the OpenAI/Astral acquisition (March 19, 2026) as part of the corporate-acquisition pattern around Rust-cored Python/JS tooling; uv is reported to save Codex ~1M minutes of compute per week