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 compresses the window between compromise and widespread adoption.
Rust’s crates.io has likewise expanded beyond simple package hosting. Crates.io, with the assistance of the Open Source Security Foundation (OpenSSF) and Dirkjan Ochtman, an open source Rust maintainer, proactively added a Security tab pulling RustSec advisories onto crate pages. Crates is piloting real-time malware scanning maintained by named full-time staff rather than an anonymous collective. Yet typosquatting attacks such as the malicious finch-rust crate, which was discovered by Socket and sat on the registry for ten days last December before removal, still demonstrate that even mature registries remain attractive targets. Npm tells much the same story.
Following Shai-Hulud, GitHub announced plans to eliminate classic tokens, shorten publishing token lifetimes, require stronger forms of multi-factor authentication, and accelerate adoption of trusted publishing. The npm CLI now supports minimum package age, allowing organizations to refuse packages published only hours earlier in the hope that malicious releases will already have been detected. GitHub’s Dependabot introduced similar capabilities, while pnpm now detects when a package’s publishing trust weakens between releases. Lockfile enforcement, provenance verification, and disabling install scripts have all become increasingly common defensive defaults in securing these public registries. All are necessary responses, even if subsequent attacks demonstrated that identity alone cannot solve every supply chain problem. As Abby Kearns, CEO of ActiveState, put it earlier this month:
Every consequential open source compromise of the past three months shipped as an authorized release from a publisher developers had every reason to trust.
Viewed individually, these incidents paired with the developments and improvements to their security posture are incremental. Viewed together, they represent something larger. Registries are becoming policy engines as much as distribution systems, and the missing piece is trust.
The Limits of Identity
It’s worth pausing on the idea of trust versus identity. Whereas trusted publishing answers the question “did this artifact come from the pipeline authorized to publish it?” It fails to address the question “is the thing my pipeline built safe to run?” Those are different questions, and the past year keeps demonstrating the distance of the gap separating them. Mini Shai-Hulud compromised packages that carried valid provenance, because the attackers had taken over the CI workflows themselves, meaning the registry’s short-lived credentials were issued, correctly, to a build system that was already hostile. Every identity check passed. The identity being verified was the problem. When the compromise happens upstream of the signing step, provenance does not detect the attack. It launders it, wrapping malicious output in exactly the cryptographic assurances defenders have been trained to look for.
The xz-utils backdoor remains the sharpest illustration of this, and it predates every mechanism in this post. The attacker known as Jia Tan spent years earning maintainer status through legitimate contributions before slipping a backdoor into the build process, and the poisoned release tarballs were created and signed by the malicious actor himself. There was no stolen token to revoke, no phished credential to reset. The signature was authentic because the signer was the attacker. Worse, the malicious build logic lived in the release tarballs in a form that did not appear in the public source repository, so even a diligent reviewer auditing the git history was staring at the wrong artifact. Had trusted publishing existed for xz’s distribution channel, it would have attested, truthfully, that the release came from the project’s authorized release process. That was precisely the problem.
This is why I prefer the word service over feature. Identity is one property of a trust service, and the registries deserve real credit for building it out, because token theft was the attack actually happening at scale and trusted publishing meaningfully raises its cost. But a trust service worthy of the name has to make claims about behavior, not just origin: what an artifact does, whether it changed in ways its history doesn’t explain, whether the humans behind a pipeline are still the humans you think they are. Unfortunately for users, an authorized release from a trusted publisher is what every one of these attacks looked like from the outside. The registries have gotten good at verifying the envelope. The letter inside is another matter, and verifying it is slower, costlier, and much harder to automate.
What Comes Next
Identity and provenance are the properties the public language registries have made real progress on, and they were the obvious place to start a conversation around modern software registries as a trust service because they address the attacks that actually happened. A stolen token is an identity problem. Trusted publishing is an identity answer. But as the xz backdoor and this year’s provenance-carrying worms demonstrate, an authorized release is not the same thing as a safe one.
That gap between attribution and assurance is where a market has formed, which is the subject of the next post in this series: hardened container images and extension marketplaces, where assurance is now something you can buy as a subscription attached to software that is otherwise free. The final post asks what happens when the consumer doing the trusting is not a person at all.
Disclaimer: Microsoft/GitHub is a RedMonk client.
Cover photo by Harrison Keely, “The FAA control tower is the tallest in the United States,” in Hartsfield–Jackson Atlanta International Airport, Wikipedia, Created 3 May 2023.
