Historically, registries answered a simple question: “Can I download this package?” Today’s tooling increasingly asks a different question: “Should I and how?”
In the first post in this series, Modern Software Registries are a Trust Service, I traced how npm, PyPI, RubyGems, crates.io, and NuGet all converged on the same response to a year of supply chain attacks, issuing short-lived credentials tied to verified build pipelines rather than trusting long-lived tokens sitting in CI. My conclusion there was that registries are becoming policy engines as much as distribution systems.
This post is about what happens when somebody works out how to charge for that. My argument begins by looking at hardened container images, where the trust-service model is furthest along. I then trace the same model in extension registries, where the Eclipse Foundation now sells an SLA on Open VSX and Microsoft’s Visual Studio Marketplace restricts extension use to Microsoft products. I argue the pattern across these markets is the same: the artifact is free, assurance is the product.
Hardened Container Images
Earlier this year I wrote that the hardened image boom prices trust in. Buying a Docker Hardened Image, Red Hat Hardened Image, or a Chainguard subscription isn’t just about the software. Wolfi is open source, distroless is open source, and nothing stops a sufficiently stubborn platform team from assembling a minimal base themselves. What the subscription buys is an SBOM enumerating what’s inside, cryptographic provenance following SLSA and usually signed with Sigstore Cosign, and a maintenance promise that somebody rebuilds and republishes the image when an upstream CVE lands.
When I surveyed that market, I noted that the maintenance promise goes beyond what the standards bodies prescribe. Chainguard’s CVE remediation commitment is now a contractual legal document, seven calendar days for critical severity and fourteen for everything else, and in April the company added a one-day SLA for anything on CISA’s KEV catalog, reasoning that half of known-exploited vulnerabilities are weaponized within two days of disclosure. In December 2025 Docker made its entire Hardened Images catalog free, but the enterprise tier’s headline feature is a service-level agreement that critical CVEs will be remediated in under seven days, with same-day fixes on the roadmap. An SLA is the one property of a trust service that cannot be forked, mirrored, or copied out of a public repo.
The timing here is not incidental either. Hardened images took off in the same window that NIST formally moved to a prioritized enrichment model, leaving thousands of 2025 vulnerabilities without a CVSS score, effectively punching a hole in the pipeline everyone’s scanners depended on. KEV commitments in commercial SLAs are a response to NIST’s move to prioritize enrichment and organize the government’s own vulnerability infrastructure around the KEV catalog. When the federal government stops supplying reliable reputation data, somebody has to sell it back to you. Reputation becomes a product, delivered through the registry and the service-level agreement tracks the collapse of the public triage pipeline in real time, selling back precisely the assurance the commons stopped providing.
Extension Registries and Marketplaces
Language registries distribute code your application calls; container registries distribute the environment your application runs inside; but extension registries distribute code that runs inside the tool you write everything else with. All three have become policy engines, but Open VSX and Microsoft’s Visual Studio Marketplace have unprecedented access to a user’s source, credentials, and shell because the extensions they distribute inherit the permissions of the editor itself.
The security ramifications of this access have spurred Microsoft to invest seriously in Visual Studio Marketplace trust properties. It signs every extension at publication and verifies that signature at install time, rescans packages after publishing because scanner databases lag new malware patterns, runs incoming packages through sandboxed dynamic analysis, and blocks publication outright when it detects leaked secrets.
The Eclipse Foundation, for its part, stood up a security researcher recognition program and has been tightening namespace verification in Open VSX, an extension marketplace for “VS Code-compatible editors, AI coding tools, cloud IDEs, and developer platforms.” The rationale for this move was prompted after Koi Security disclosed that VS Code forks including Cursor, Windsurf, and Google Antigravity were recommending extensions by name that did not exist in Open VSX, leaving those namespaces unclaimed and squattable (more on that in the 3rd post in this series). In April 2026, the Eclipse Foundation also launched the Open VSX Managed Registry, offering commercial adopters a 99.95% uptime SLA, service credits, and defined support tiers, while remaining free for individual developers and open source projects.
In today’s security landscape, all of these strategies are very much needed. Wiz found a pattern of credential leakage among extension publishers. In May 2026, a trojanized build of Nx Console, an extension with 2.2 million installs and a verified publisher badge, using credentials harvested from an earlier compromise of the TanStack npm packages, was live for roughly eleven minutes on the Visual Studio Marketplace and about thirty six on Open VSX. The payload harvested credentials from disk and memory, one of the machines it landed on belonged to a GitHub employee, and roughly 3,800 internal GitHub repositories were exfiltrated. The incident was assigned CVE-2026-48027. Open VSX has also experienced its own supply chain attack, most notably GlassWorm, illustrating that extension registries now face many of the same security pressures now familiar to language package ecosystems.
Several points are worth sitting with from within the domain of extension registries and marketplaces.
First, automated refreshes have become standard across every major extension ecosystem. There is no resolution step to inspect, no lockfile to pin, and no install command to think twice about before a different program is running on your machine.
Second, we have a Meh-trics problem. Microsoft’s telemetry reported 28 installs while Nx’s own analytics put activations near 6,000 because the two systems count different things and auto-update may not register as an install at all. Reputation data is only as good as what it actually measures.
Third, attackers are not evading provenance systems, but using them. The malicious Nx payload shipped with full Sigstore integration, including Fulcio certificate issuance and SLSA provenance generation. This is the same lesson I drew from Mini Shai-Hulud compromising packages that carried valid OIDC-signed provenance, and further evidence around the limits of identity. Provenance answers where an artifact came from, but cannot answer whether you should run it. A verified badge, a high install count, and an official marketplace are trust signals, and in this attack every one of them worked exactly as designed while pointing at malware.
The fourth point I want to draw out is the role of AI-native development environments including Cursor, Windsurf, Google Antigravity, and Trae in all this. Microsoft’s Visual Studio Marketplace has restricted extension use to Microsoft products since 2020, but for years that restriction lived only in the terms of use. In April 2025 it became technical with version 1.24.5 of the C/C++ extension checking its host environment and refusing to run in anything that wasn’t an official Microsoft build, which broke VSCodium and Cursor and prompted at least one developer to write to the FTC alleging self-preferencing. Cursor had reportedly been running a reverse proxy to mask its requests to Microsoft’s marketplace endpoints.
OpenAI’s acquisition of Ona (formerly Gitpod), alongside Astral, suggests that model vendors increasingly view developer infrastructure itself as strategically important. After all, OpenVSX was created by Miro Spönemann and others at TypeFox, the German firm that also spun out Gitpod (now Ona). It is no accident that the plumbing of software registries is being absorbed into the model labs.
What Comes Next
Docker, Chainguard, and the Eclipse Foundation are all in the business of selling assurance now so it’s worthwhile to look closely at which assurance they sell. Uptime percentages and remediation clocks are the properties that can be measured, audited, and written into a contract, which is exactly why they were the first to be priced. A vendor can only commit to what it controls, and what these vendors control is their own build pipeline and their own infrastructure.
The properties that remain unpriced are the ones that would require judging what an artifact does rather than verifying where it came from, and as in the first post, that is where the difficulty lives. The assurance market is denominated in days. The attacks are denominated in minutes. Nobody sells a service-level agreement promising to notice within eleven minutes that an authorized publisher has turned hostile, because nobody can.
Today, assurance covers the failures a vendor can be held accountable for, and the residue, the actual decision about whether a given artifact should be allowed to run, stays with the consumer. That residue is being handed back at the precise moment when the consumer has stopped being a person. Which is where the final post in this series goes: MCP, A2A, and what it means to build registries for consumers who are not people.
Disclaimer: The Eclipse Foundation, Microsoft/GitHub, Docker, Google, Red Hat, AWS, and Chainguard are RedMonk clients.
New control tower (photographed in April 2018) by Gregory Varnum. Wikipedia.
.jpg){kind=link}