Fewer keys under the doormat: why trusted publishing matters for Open VSX

mikael.barbero@eclipse-foundation.org (Mikaël Barbero) — Fri, 09 Oct 2026 10:30:00 +0200

Every software registry eventually learns the same lesson: the most valuable thing in a publishing pipeline is not the code. It is the credential that lets someone ship it.

For most of its history, publishing an extension to the Open VSX Registry from CI has meant creating a personal access token and storing it as a secret in a pipeline. That token is a key left under the doormat. It works at any time, from anywhere, for whoever finds it, and it keeps working until someone notices it should not.

Trusted publishing is now available on Open VSX. Tamas Cservenak has already written a practical guide to setting it up. This post is about something else: why we think it matters, which threats it addresses, which ones it deliberately leaves to other controls, and where it fits in the way we approach the security of the registry.

The publishing credential is the prize

Extensions are not passive content. Once installed, an extension runs with the privileges of the developer who installed it. It can read source code, environment variables, SSH keys and cloud credentials, and it increasingly sits next to AI agents acting on the developer’s behalf. Open VSX now delivers hundreds of millions of extension downloads a month to AI-native IDEs, cloud development environments and VS Code-compatible tools, and most of those editors update extensions automatically.

At that scale, publishing security is not just a concern for individual extension maintainers. It is a responsibility to the broader developer ecosystem.

Put those facts together and the attacker’s calculus is simple. Someone holding a valid publishing credential does not need to find a vulnerability in the registry, or persuade anyone to install anything. They publish an update. The registry sees an authenticated upload from a legitimate account, and auto-update does the rest. Attackers rarely need to break in when they can log in.

This is not hypothetical. In October 2025, researchers reported publishing tokens that developers had inadvertently exposed in public repositories, some of them for Open VSX, and some of those tokens were abused in the GlassWorm malware campaign. In January 2026, four long-established extensions received malicious updates pushed through a legitimate publisher’s access. Across the wider ecosystem, the Shai-Hulud family of worms has turned this into a repeatable pattern: steal a token, publish a poisoned release, harvest more tokens from everyone who installs it, repeat. These campaigns feed on long-lived credentials. After the first Shai-Hulud wave, npm retired classic tokens, shortened the lifetime of the rest, and pushed publishers toward trusted publishing for exactly this reason.

Why long-lived tokens are the wrong primitive

Over the past year we have worked hard to make tokens safer. Open VSX tokens now carry a recognisable prefix, introduced with MSRC, so that secret scanners can spot them in public code. Default lifetimes are shorter. Extensions are scanned for embedded secrets before publication, and revocation is faster. These measures help, and they stay in place. But they all manage a risk that trusted publishing lets us remove.

The trouble with a long-lived token is structural, and it shows up along three dimensions.

Time. A token is valid until it expires or is revoked, which in practice means until someone notices it has leaked. The exposure window is measured in weeks or months, and the attacker, not the defender, decides when it starts.

Scope. Few people create the narrowest possible token, because working out the right scope and expiry is tedious. A token meant to publish one extension can often publish everything its owner controls.

Place. A token is only as safe as every place it has ever been copied to: a CI secret store, a laptop’s shell history, a .env file, a chat message to a co-maintainer. Inside CI, a stored secret is typically readable by every step of the job, including third-party actions nobody audited. When something goes wrong, recovery is manual: find every copy, rotate it, and hope none was missed.

None of this is a failure of individual publishers. Security that depends on thousands of maintainers getting secret hygiene right, every time, does not scale. A registry that wants to be trustworthy has to make the safe path the easy one.

From a secret to a relationship

Trusted publishing replaces the shared secret with a declared relationship: this workflow, in this repository, may publish this extension. The registration itself contains no secret at all. It simply records which pipeline the publisher trusts.

At release time, the CI system gives the job a short-lived, cryptographically signed statement of its own identity. The registry verifies that statement against the registration and, if they match, issues a credential that lives for about five minutes and can publish exactly one extension. Nothing long-lived is stored anywhere, so there is nothing to leak into a public repository, nothing for an infostealer to lift from a laptop, and nothing to rotate.

Back to our three dimensions, the blast radius shrinks on every axis: minutes instead of months, one extension instead of a whole namespace, one registered workflow instead of everywhere a token was ever pasted. The recovery story changes too. An attacker who loses access to a compromised pipeline loses the ability to publish, without anyone having to rotate anything.

Cloud infrastructure made this same move years ago, when static access keys gave way to workload identity federation and the principle of no standing privileges. Package registries are now catching up, and Open VSX is part of that shift.

Several design choices in the Open VSX implementation reflect lessons other registries learned the hard way. The registry resolves repository and owner names to their immutable numeric identifiers when a registration is created, so a repository that is deleted and re-created under the same name by someone else simply stops matching. A registration is removed automatically when its creator stops being an owner of the namespace, so access does not quietly outlive the person who granted it. Error responses are deliberately uniform, so the token exchange cannot be used to probe which extensions have a trusted publisher. The project documentation covers these and other details.

Above all, the implementation follows the OpenSSF guidance Trusted Publishers for All Package Repositories rather than a bespoke design. That is a strategic choice. Trusted publishing was pioneered by PyPI with Trail of Bits in 2023, and has since been adopted by npm, RubyGems, NuGet, crates.io and pub.dev. At the time, Trail of Bits predicted it would become as foundational to packaging security as two-factor authentication. Following the shared model means Open VSX publishers, many of whom also ship to npm, meet a mechanism they already understand, with guarantees that have been scrutinised across several ecosystems. Supply chain security improves faster when registries converge on well-reviewed patterns instead of each inventing its own.

What trusted publishing does not do

Being precise about the limits of a security control is part of deploying it responsibly. Trusted publishing has two limits worth stating plainly.

It is authentication, not endorsement. As William Woodruff, one of its original designers, argued in You shouldn’t trust Trusted Publishing, the “trust” in the name is machine-to-machine trust between a CI workflow and a registry. It says nothing about whether an extension is safe, well-written or well-intentioned. Anyone can register a workflow, including someone publishing malware under their own name.

The small marker next to “Published by” on an Open VSX extension page should be read in that light. It is a provenance record: this version arrived through the publisher’s registered workflow rather than through a personal token. That is useful, mostly as a consistency signal. In one of this year’s npm incidents, the telltale sign of compromise was a malicious release published with a personal token when the project normally released through its CI identity. Our own 2025 audit treated sudden changes in publishing behaviour as an indicator of compromise for the same reason. But the marker is not a safety rating, and we do not intend it as one. Every upload still goes through pre-publication checks, however it was authenticated.

It moves the trust boundary; it does not remove it. Whoever can modify or trigger the registered workflow can publish. 2026 has shown attackers adapting accordingly. In May, the TanStack compromise chained a dangerous pull_request_target trigger, GitHub Actions cache poisoning and the extraction of an OIDC token from runner memory, and used them to publish malicious npm packages through the project’s own release pipeline, complete with valid provenance. According to one analysis, the project’s trust configuration covered the repository as a whole rather than a specific protected branch and workflow.

The lesson is not that trusted publishing failed. It raised the attacker’s cost from “find a token” to “compromise a pipeline”, and the pipeline is now where defence has to concentrate. On Open VSX, a registration is bound to a specific workflow file but, as in most implementations, not to a branch: any ref that runs that workflow is trusted. That is why we strongly recommend pinning a deployment environment with required reviewers and branch restrictions, so that a merged pull request or a stray commit cannot ship a release on its own. Pinning actions to commit SHAs, keeping default token permissions read-only, and avoiding triggers that run untrusted code with privileges now carry the weight that the stored token used to. The Eclipse Foundation Security Team’s guidance on hardening GitHub Actions is a good place to start.

One layer in a deliberate strategy

Trusted publishing answers one specific question: who is allowed to publish? It sits within a layered model in which each control covers a different stage of an extension’s life.

Who can publish: verified namespaces, a signed publisher agreement, and now short-lived, narrowly scoped credentials tied to a declared pipeline.
What gets published: pre-publication checks for impersonation, embedded secrets and known malicious patterns, with suspicious uploads held for review rather than released.
What can change afterwards: immutable versions, so a published version can never be silently replaced.
Who can watch: the Registry Changes Feed, an append-only record of publications, deactivations and removals that independent monitors and mirrors can follow.
How we respond: fast token revocation, coordinated disclosure, and transparent advisories when something goes wrong.

The common thread is a shift from reacting to reports toward removing opportunities. We would rather take away what attackers want than become very good at noticing when they have taken it.

Publishing security is also a question of choice and control. Today, trusted publishing on Open VSX supports GitHub Actions. GitLab support comes next, and it is designed so that any GitLab instance, including self-hosted ones, can be configured as an identity provider. For a vendor-neutral registry, it matters that the root of publishing trust is not tied to a single platform, and that organisations can anchor it in infrastructure they control.

Make the switch to trusted publishing

If you publish to Open VSX from CI, please migrate. In practice, that means four things.

Register your workflow as a trusted publisher and switch your release job to trusted publishing, following Tamas’s guide. The very first version of a new extension still needs a token; every release after that does not.
Delete the stored token from your CI secrets and revoke it. A token left in the pipeline keeps working and takes precedence, which means you have not actually switched.
Pin a deployment environment with required reviewers, so that publishing requires a deliberate human decision.
Treat the workflow file as security-critical code: protect it, review changes to it, and harden what runs inside it.

Securing critical infrastructure takes a community

This work was made possible by Alpha-Omega, which has supported the Eclipse Foundation’s security program since 2022 and has backed the hardening of the Open VSX Registry, from pre-publication checks to infrastructure and now trusted publishing. Support of this kind is what allows a non-profit foundation to move beyond responding to incidents and toward systematically removing the conditions that make them possible. Thank you.

Thanks also to Tamas Cservenak, Thomas Neidhart and the Open VSX contributors who designed and shipped this feature, and to those whose groundwork we build on: the PyPI and Trail of Bits teams who pioneered trusted publishing, and the OpenSSF Securing Software Repositories Working Group, whose guidance gives every registry a common blueprint.

Open VSX exists so that the developer tooling ecosystem does not have to depend on a single vendor’s marketplace. That independence is only worth something if the registry deserves the trust placed in it. Every long-lived token we help retire is one less key under the doormat.

Supply-Chain on Opera Omnia