The timing was almost too perfect.
Just 48 hours after the LiteLLM supply chain breach scattered malicious code across thousands of developer environments, Astral dropped what amounted to a security confession—or perhaps a manifesto. On April 8, William Woodruff, the company's staff security engineer, published an unusually candid document titled "Open source security at Astral." Not a product announcement. Not a think piece. A working blueprint from the trenches.
Within two days, the post had racked up 356 upvotes on Hacker News and triggered the kind of technical debates that tend to surface when engineers realize they're all vulnerable to the same attacks. The question hanging over the thread: Could any of this actually stop what's coming?
Because something is definitely coming. March 2026 saw several high-profile breaches that rattled the developer tools world. Between March 20 and 22, attackers hijacked the Trivy Actions repository, force-pushing 75 tags to slip an infostealer into CI pipelines. Days later, LiteLLM published compromised releases—caught within approximately 40 minutes, yes, but 40 minutes is a long time when your package manager auto-updates. These weren't isolated incidents. Ultralytics fell in December 2024, tj-actions got exploited in 2025, and the Nx package compromise distributed data-stealing malware to build servers.
Astral, the company behind Ruff and uv, has some skin in this game. Their tools sit in millions of CI pipelines. Attackers are circling. So Woodruff's playbook reads less like guidance and more like field notes from an active conflict.
The Part Where They Just Say No
Most security frameworks hedge. They suggest. They recommend. Astral's approach starts with hard bans, the kind that force uncomfortable architecture decisions but close off entire attack vectors.
First casualty: pull_request_target and workflow_run triggers, banned organization-wide. These are the privileged GitHub Actions contexts that enabled breaches like Ultralytics, where untrusted code suddenly had access to secrets it shouldn't have touched. "If you need something that Actions can do but 'not securely,'" Woodruff writes, Astral moves that logic to a dedicated GitHub App instead. Keep the credentials away from code you don't control.
Then there's action pinning. Every single action must be locked to a full-length commit SHA—not tags, not branch names, nothing mutable. GitHub's organization-level policies enforce this for nested actions. Astral also built its own scanner, zizmor, to catch unpinned dependencies and what the industry has started calling "impostor commits"—fork-reachable SHAs that look legitimate until you realize they aren't from the upstream repository at all.
And that's not the end of it. Even pinned actions get manual review for what Woodruff calls "immutability gaps," cases where the action itself is locked down but still fetches mutable artifacts downstream during execution. It's tedious work. It's also the difference between having a security policy and actually being secure.
Secrets Don't Get to Travel
Permission scoping follows a similar zero-trust logic, though perhaps more ruthlessly than most organizations could stomach. Every workflow defaults to permissions: {} at the org level—essentially read-only. Individual jobs broaden access only when they can justify it, and release credentials live behind environment-scoped deployment gates that require manual approval.
Test jobs don't get release secrets. Lint jobs don't get release secrets. The policy limits blast radius, which matters when—not if—something breaks.
For actual releases, a second privileged organization member has to manually approve before anything ships. Tags can't be created until the deployment succeeds, enforced through GitHub rulesets. Build caches get disabled during releases, because cached artifacts are another mutable component. GitHub's immutable releases feature prevents post-publish tampering, at least in theory.
The Credentials That Aren't There
The most significant shift might be the one users never see: Astral eliminated long-lived credentials entirely. They use Trusted Publishing, the OIDC-based authentication mechanism now supported by PyPI, crates.io, and npm. Instead of API tokens sitting in environment variables—tokens that could leak, get stolen, or accidentally commit to version control—workflows authenticate through short-lived tokens issued directly by GitHub.
Every release also generates Sigstore attestations, cryptographic proof of build provenance. The uv project maintains a public attestations directory on GitHub for anyone who wants to verify what they're running. Code signing for release binaries is actively in development (there's an open pull request as of April 2026), though Woodruff acknowledges some lingering issues around installer integrity when you're still using "curl | sh" patterns from the same host serving the binaries.
Dependencies, With a Side of Paranoia
Third-party dependencies present their own problem, one that doesn't have a clean technical solution. Astral applies what Woodruff describes as "cooldowns"—intentional delays before upgrading packages, giving the broader community time to surface issues first. The company also maintains direct relationships with upstream projects and groups like the Python Security Response Team, and funds open source development through its OSS Fund.
One gap remains unresolved: Astral isn't uploading attestations to PyPI under PEP 740 yet, due to incompatibilities with how Trusted Publishing identities work. The team plans to fix it. No timeline, though.
What Comes Next (and What Doesn't)
Astral plans to open-source astral-sh-bot, the GitHub App currently handling privileged operations like commenting on third-party pull requests without exposing secrets to untrusted workflows. The bot itself still needs hardening against template injection and similar attack vectors—a useful reminder that moving security boundaries just creates new perimeters someone has to defend.
For organizations watching their developers pull tools from PyPI or npm dozens of times a day, often without thinking twice, Astral's framework offers something relatively rare: working examples from a company whose software is already a target. The 102-comment Hacker News thread turned into something like a security workshop, with Woodruff fielding technical questions about threat models, reproducible builds, and edge cases that the documentation didn't cover.
Whether GitHub's default security model can ever be made truly safe remains an open question, one that generates strong opinions on both sides. But for teams shipping open source code today—right now, while attacks are already happening—the framework at least documents what defense looks like when you assume the supply chain is already compromised.
Because maybe it is.
