Map

Open Source Security at Astral

Sources ↳ show in map Markdown

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