What Astral's Security Playbook Reveals About the Power of SBOMs
Ritesh Noronha
Most software teams cannot copy Astral's security program. They do not have the same maintainer time, institutional knowledge, or bespoke tooling. What they can do is make more of their supply chain visible, measurable, and enforceable.
That is what stood out to us in Astral's breakdown of how they secure Ruff, uv, and ty. In our read, a majority of the practices they describe either depend on supply chain metadata directly or become more auditable when paired with SBOMs, attestations, VEX, and related artifacts.
We would not over-claim the precision of that estimate. The point is not whether the exact number is 55% or 65%. The point is that a large share of Astral's playbook becomes easier to operationalize once the artifact, its contents, and its provenance are machine-readable.
Here's a compact way to think about that split:
Category | Example from Astral's post | SBOM-related impact |
|---|---|---|
Dependency inventory | Conservative dependency choices, update hygiene | Directly supported by SBOMs and dependency metadata |
Vulnerability handling | Cross-project impact analysis, triage | Strengthened by SBOM correlation and VEX |
Release provenance | Sigstore attestations, checksums, Trusted Publishing | Strengthened by pairing artifacts with SBOMs and attestations |
Build transparency | Action pinning, pipeline hardening | Partially supported through build metadata such as CycloneDX formulation |
Organizational controls | 2FA, admin restrictions, two-person approval | Outside SBOM scope |
Dependency Visibility: The Foundation
The most SBOM-native section of Astral's post covers dependency security. They describe using Dependabot and Renovate for updates, maintaining social connections with upstream maintainers, being conservative about adding new dependencies, and even financially supporting projects they depend on through their OSS Fund.
All of this starts with a fundamental question: what do you actually depend on?
An SBOM can answer this, if it's generated with enough coverage. A well-produced CycloneDX or SPDX document for uv doesn't just list direct Cargo dependencies — it can capture transitive dependencies, vendored libraries, build tools, and platform-specific components that manual auditing tends to miss. In practice, that makes it possible to:
Track dependency count trends across releases (are you actually reducing your attack surface?)
Flag components that introduce binary blobs or pull in excessive transitive dependencies
Identify orphaned or unmaintained upstream projects before they become liabilities
Prioritize which upstream projects deserve financial support based on actual criticality in your dependency tree
What Astral does through institutional knowledge and social connections, SBOMs can make more repeatable and auditable — especially important as organizations scale beyond a single team's ability to maintain mental models of their supply chain.
Dependency Cooldowns: A Policy SBOMs Can Enforce
One of the more interesting practices Astral describes is dependency cooldowns — deliberately delaying adoption of new dependency versions to avoid the window when temporarily compromised packages are most dangerous. They note that Renovate, Dependabot, and uv itself all support cooldowns.
This is a risk management policy that SBOMs can help make enforceable. A supply chain platform can pull recent release metadata directly from package managers — PyPI, crates.io, npm, and others — and define policies that flag or block components adopted too soon after publication. Rather than relying only on Renovate or Dependabot configurations that can drift or be overridden, this creates a continuous, auditable enforcement layer: if a component in your SBOM was published 12 hours ago and your cooldown policy requires 72 hours, the policy can catch it as long as the component and version are captured and the release metadata is available.
Release Integrity: Where SBOMs and Attestations Converge
Astral's release security section describes Sigstore attestations, immutable releases, Trusted Publishing, and checksums embedded in their standalone installer. These are all mechanisms for establishing that an artifact is authentic — that it came from a known build process and hasn't been tampered with.
SBOMs fit naturally into this chain. In practice, the artifact is typically the subject of the attestation, while the SBOM is attached or referenced as the signed statement about that artifact. Done well, this answers three questions simultaneously:
What's in this artifact? (the SBOM's component inventory)
Where did it come from? (the attestation's builder identity and workflow reference)
Has it been tampered with? (the cryptographic signature binding the two)
Astral already generates Sigstore attestations for their binary and Docker releases. Pairing these with SBOMs would let downstream consumers verify not just that they got a legitimate build of uv, but also inspect what went into that build. This is particularly relevant for users in regulated industries where provenance documentation isn't optional.
CI/CD as a Supply Chain: The Build SBOM
Some of Astral's most involved security work targets their CI/CD pipelines — hash-pinning GitHub Actions, manually reviewing actions for mutable decisions, isolating secrets in deployment environments, banning dangerous workflow triggers. These are labor-intensive, high-skill tasks.
CycloneDX introduced formulation in version 1.5 and has continued to expand it since, giving the format a way to describe build pipelines as structured data — the tools, actions, environments, and configurations involved in producing an artifact. This is still early-stage in the ecosystem, but the direction is clear: build processes themselves are supply chain components and should be inventoried as such.
An SBOM that includes formulation data could eventually make parts of Astral's CI/CD hardening more auditable by downstream consumers, where tooling supports it. Instead of relying entirely on a project's narrative, consumers could inspect structured build metadata alongside other supply chain artifacts. This also creates accountability: if your build SBOM shows an unpinned action, its quality and trustworthiness should drop accordingly.
Vulnerability Management at Dependency Depth
Astral describes maintaining social connections with projects like the Python Security Response Team and PyPA to share vulnerability intelligence across project boundaries — for example, when a report against pip also affects uv.
This is a social process solving a data problem. With SBOMs, vulnerability correlation across projects becomes much more systematic. If both pip and uv share a common component, and that component has a CVE, an SBOM-aware vulnerability platform can flag both projects simultaneously. That doesn't replace mailing lists, trust relationships, or coordinated disclosure, but it does reduce how much depends on them.
This kind of workflow depends on good correlation across NVD, OSV, and vendor advisories using identifiers like PURLs and CPEs, plus careful handling of the hard edge cases — distro backport false positives, vendored forks with non-standard versioning, and weak CPE coverage for embedded or niche components — that make naive vulnerability matching unreliable.
VEX (Vulnerability Exploitability eXchange) adds another layer here. When Astral determines that a CVE in a dependency doesn't actually affect uv because the vulnerable code path isn't reachable, that assessment can be captured as a VEX statement attached to the SBOM. This turns a one-time triage decision into a reusable, machine-readable artifact that every downstream consumer benefits from.
What SBOMs Don't Cover — And Why That's the Point
This is where the "not a silver bullet" honesty matters. In our analysis, a substantial share of Astral's security posture falls squarely outside SBOM territory:
Organizational controls — Enforcing 2FA, limiting admin privileges, banning admins from bypassing protections. These are identity and access management problems.
CI/CD trigger policies — Banning
pull_request_targetandworkflow_runorg-wide. This is platform governance.Two-person approval for releases — A human process control that no document format can replace.
No caching in release builds — A build policy decision.
GitHub App isolation — An architectural pattern for separating privileged operations from CI/CD.
SBOMs don't pretend to solve these problems, and anyone who tells you otherwise is selling something. The right mental model is layers: organizational controls ensure the process is secure, SBOMs document the contents, attestations authenticate claims about artifacts, and vulnerability management evaluates whether those contents are safe. Each layer reinforces the others. No single layer is sufficient. But without the SBOM layer, the other layers say less about what is actually inside the artifact you're securing.
The Bigger Picture: A Large Share Is Still Material
What makes Astral's post impressive is also what makes it sobering: the sheer amount of manual effort, institutional knowledge, and bespoke tooling required to secure a well-resourced open source project. Most projects do not have the resources to replicate this.
SBOMs won't get you to 100%. Nothing will. Security is layers, and anyone promising a silver bullet is ignoring the share that still requires human judgment, organizational discipline, and platform-level controls.
But the portion that SBOMs touch — dependency visibility, vulnerability correlation, release provenance, cooldown enforcement, build auditability, VEX-driven triage — represents the part of supply chain security that can be automated, measured, and continuously monitored rather than relying on heroic individual effort. And for the vast majority of projects that can't match Astral's investment, that is often the difference between having a security posture and having a hope.
SBOMs are not a silver bullet. They're the foundation that makes everything else verifiable.