# Open Source Security at Astral

# Open Source Security at Astral

**Author:** Astral (makers of Ruff, uv, ty)
**Date:** 2026 (approximate)
**Source:** https://astral.sh/blog/open-source-security-at-astral

## CI/CD Security

GitHub Actions has poor security defaults. Compromises affecting Ultralytics, tj-actions, and Nx exploited well-known weaknesses like pwn requests.

### Key Protections

- Forbid `pull_request_target` and `workflow_run` triggers organization-wide
- Pin all actions to specific commit hashes, not mutable tags
- Use zizmor (static analysis) and pinact (automatic pinning)
- Start workflows with `permissions: {}`, broaden job-by-job
- Use deployment environments and environment-specific secrets instead of org/repo-level secrets

Hash-pinning alone isn't sufficient — it ensures action immutability but not that the immutable code avoids mutable operations like downloading latest binary versions. Work with upstreams to embed cryptographic hashes for downloads.

## Repository and Organizational Security

- Limited admin accounts; most members read/write only
- Strong 2FA (TOTP or stronger), plan to enforce WebAuthn
- Org-wide branch protection: no force-push to main, require PRs
- Forbidden branch patterns (advisory-*, internal-*) prevent premature security disclosure
- Release tags immutable once created, can't be created until release deployments succeed
- All protections at org level — repo admins can't disable

## GitHub Apps over Dangerous Triggers

astral-sh-bot (GitHub App) replaces `pull_request_target` for tasks like commenting on external PRs. Apps receive webhook data with more control and less implicit state. Still vulnerable to SQLi, prompt injection — treat development with rigor.

Apps don't make it safe to run untrusted code; they make unexpected execution harder.

## Release Security

- Trusted Publishing (OIDC) for PyPI, crates.io, NPM — eliminates long-lived registry credentials
- Sigstore attestations on binaries and Docker images
- Immutable releases (GitHub feature) — prevents post-release modification (Trivy attack vector)
- No build caching during releases (cache poisoning prevention)
- Dedicated deployment environments for release processes
- Multi-person approval for release environment activation
- Standalone installer checksums (uv)
- Future: codesigning with developer certificates on macOS/Windows

## Dependency Security

- Dependabot + Renovate for automated updates
- Dependency cooldowns: delay updates after new releases (compromised versions most dangerous right after release)
- Social connections with upstream maintainers, contribute security fixes
- Relationships with Python Packaging Authority and Python Security Response Team
- Conservative dependency addition, eliminate where practical
- Avoid binary blob dependencies
- OSS Fund for financial support of upstream projects