Modern Software Registries are a Trust Service – console.log()
You are using an outdated browser. Please upgrade your browser to improve your experience.
Skip to Content
A modern software registry is increasingly a trust service. Public registries like npm and PyPI provide identity, provenance, discovery, policy, short-lived signing, and reputation. They were built as open catalogs: anyone can publish, names are first come first served, and trust is something the consumer infers after the fact from download counts, stars, GitHub activity, and whether the maintainer seems reputable. But that model of treating trust as somebody else’s department, which held for most of software history, has shifted in the agentic era.
Last year, I asked whether npm was enough. Today, the more interesting story isn’t npm itself, but rather the convergence happening across public software registries writ large: ecosystems that evolved independently are building the same trust machinery, for the same reasons, at the same time. Today, public registries are no longer simply catalogs of reusable artifacts—packages, libraries, extensions, or containers—identified by stable names and versions. Historically, the decision to depend on one happened outside the registry, in the mind of a developer evaluating documentation such as a README. But this approach is no longer sufficient. Over three posts I will trace this shift across npm, PyPI, RubyGems, crates.io, OpenVSX, NuGet, Docker Hub, as well as MCP and future A2A registries, to consider why trust is now the domain of registries and what that signifies.
I decided to split this argument into three parts because the public registry landscape in 2026 is capacious and nuanced. This first post stays with the language registries, and it makes two moves. First, it surveys a year of supply chain attacks and the remarkably uniform response: trusted publishing, short-lived credentials, and provenance are becoming table stakes across every major ecosystem. Second, it asks what that progress does and does not buy, because identity turns out to be the property registries can verify and not the one users often need most. The second post takes a step back to container images and to extension registries, including OpenVSX and Microsoft’s Visual Studio Marketplace, because that is where trust stops being a feature and starts being a product you buy. The third looks to the future. As artifacts are increasingly designed to be consumed by machines rather than humans, why is it more important than ever for registries to be a trust service, and are MCP and A2A positioned to accommodate this new reality?
Registries are Under Attack
It seems like npm, the default package manager for JavaScript and the Node.js runtime environment, is perpetually in the news these days, and over the past year almost invariably in relation to security. In late August 2025, attackers stole an Nx publishing token and pushed malicious releases in the s1ngularity campaign. Shai-Hulud became the first self-replicating worm to spread through npm by stealing maintainer credentials and poisoning hundreds of packages. The sequel, Shai-Hulud 2.0, spread through projects from Zapier, PostHog, and Postman before reaching tens of thousands of GitHub repositories. Then came the Axios maintainer compromise, followed by Mini Shai-Hulud, which became the first coordinated campaign to target both npm and PyPI. While no two incidents were identical, the overall pattern indicates that software registries are now strategic infrastructure and also prime vectors for attack.
In response to these and similar compromises, trusted publishing has become table stakes. PyPI introduced OIDC-based trusted publishing in 2023, RubyGems followed later that year, and npm, NuGet, and crates.io have since adopted similar approaches. Rather than relying on long-lived API tokens sitting inside CI systems waiting to be stolen, registries increasingly issue short-lived credentials tied to verified build pipelines. The ecosystems arrived at nearly the same answer because they are responding to the same pressures.
PyPI illustrates the trend particularly well. By the end of 2025, more than 20% of PyPI’s file uploads came through trusted publishers and 17% carried an attestation. As Bernát Gábor, Senior Software Engineer at Bloomberg and Python Guild leader, explains, the team also built out a quarantine system that freezes a suspicious project instead of nuking it, processing over 2,000 malware reports in 2025 with two-thirds handled inside four hours. PyPI expanded its trust and safety features by adding archival status for unmaintained packages and enabling phishing detection.
Attacks against PyPI haven’t stopped, of course. The LiteLLM compromise remained available for only a few hours before removal yet still accumulated more than 119,000 downloads because automated systems faithfully installed the latest available version. Speed matters, but automation...