pattern·published·1 exhibit

Unsigned Ecosystem Echo

A new ecosystem replaying every lesson the old ones learned. Same registry shape, same provenance gap.

Every ecosystem gets security lessons it had to learn the hard way. npm learned about typosquatting after it happened. PyPI learned about maintainer-account compromise after it happened. Docker Hub learned about mutable tags after they bit. The lessons are public. The fixes, where they exist, are documented. The remediation playbooks are written down in conference talks and postmortems going back years.

A new ecosystem arrives and, with few exceptions, does not read them. The new ecosystem re-produces the same shape: a namespace, a registry, a publish workflow, a trust-by-default consumption model. The same attacks work on the new ecosystem as worked on the old one. Readers watching with a straight face describe the ecosystem's "novel supply chain concerns" that are, in fact, the supply chain concerns the older ecosystem solved (or at least documented) ten years earlier.

Mechanism

The pattern is not about malice or even negligence. It is a specific failure mode in how ecosystems bootstrap. Early in an ecosystem's life, the priority is adoption. The community needs frictionless publish, frictionless install, frictionless sharing. Security controls that slow adoption get deprioritized or deferred. The design decisions that become load-bearing for the ecosystem are the decisions that maximized early growth.

By the time the ecosystem is successful enough to be targeted, the design decisions are locked in. Adding mandatory signing to an already-active registry requires migrating every package, every consumer, every tool. The cost is high; the benefit is retroactive; the political capital to force it is limited. So the ecosystem runs with the same trust posture the older one did in its own early days, and the same attacks work, because the same structural conditions are present.

What makes this specific (rather than generic "young projects have bugs") is the echo: the ecosystem is not discovering new attacks. It is re-experiencing attacks that are documented, analyzed, and demonstrated with existing playbooks elsewhere. An attacker who reads npm history can attack the next JavaScript-shaped package registry with the same techniques. The ecosystem's defenders have to arrive at the same conclusions. The attackers are already there.

This is a pattern-of-patterns: the instances it produces (typosquats, maintainer compromises, unsigned replay, dependency confusion) have their own entries in the taxonomy. Unsigned-ecosystem-echo names the meta-shape, so defenders looking at a new ecosystem know to pre-apply the whole set rather than wait for the first incident in each class.

Exhibits

MCP Servers: The New npm Left-Pad. The Model Context Protocol ecosystem is in its adoption-at-any-cost phase. Package discovery, publish mechanics, consumption defaults are being built with the familiar priorities of frictionless adoption. Typosquatting variants of official packages, shared credentials across the install chain, no enforced signing, lockfile-adjacent consumption patterns. The post catalogs the specific attacks that already work against MCP and names each one as a direct echo of an attack documented on npm between 2016 and 2022. The ecosystem is two to five years behind on its own defensive maturity, against an attacker community that has fully productized the techniques.

Exhibits

Boundaries

Not every young ecosystem is in this pattern. An ecosystem designed from the beginning with lessons-learned baked in (mandatory signing, namespace controls, provenance attestation) does not produce this shape. The pattern specifically describes ecosystems whose early design decisions recapitulate the same trust-by-default shape that older ecosystems failed with.

Not every old ecosystem problem. npm's current issues are the LATE evolution of its own story, not unsigned-ecosystem-echo. The pattern describes a new ecosystem echoing the old one. The older ecosystem's present-day struggles are that ecosystem's own journey, separately labeled.

Not every adoption-first design. Adoption priority without security-lesson transfer is the pattern. Adoption priority with security lessons proactively applied is a different story, and much rarer. The distinction is: did the ecosystem's design team read the postmortems from the predecessor ecosystems they resemble?

Defender playbook

When a new ecosystem reaches meaningful adoption in your organization, run the pattern catalog from the ecosystem it most resembles. For an MCP-shaped ecosystem, that is npm. For a container-image ecosystem, that is Docker Hub. The question is not "what is novel here." The question is "which npm-era attacks work here, right now, against a random install."

Build your own integrity mechanism before the ecosystem provides one. Lockfiles, content-addressed references, allowlists of maintainers, mirror-and-verify workflows. If you wait for the ecosystem to agree on signing, you will be exposed for the interval. The ecosystems that eventually shipped signing did so after years of incidents; planning for another multi-year interval is prudent.

Do not distinguish between maintainer-compromise and ecosystem-level supply-chain attacks. Both are in the attacker's playbook on day one of your ecosystem engagement. Treating the newer ecosystem as if it will take years to be targeted assumes attackers wait for adoption curves. They do not.

Treat the ecosystem's "novel" framing with suspicion. Writeups describing "unique MCP supply chain concerns" or "the first-ever X registry attack" are, more often than not, the same attack that happened to npm in 2018 running against a fresh ecosystem. Reading the advisory against npm CVE history identifies the echo within minutes.

When you adopt something new, allocate defender-hours proportional to ecosystem maturity. A five-year-old ecosystem has a roughly npm-2014 security posture regardless of how the ecosystem markets itself. Budget defense at that maturity level, not at the age-of-your-dependency level.

Kinship

Maintainer Account Compromise. Frequent instance within the echo. Unsigned-ecosystem-echo produces recurring maintainer-account compromises as one of its first visible symptoms, because the ecosystem's account-based publish model arrived before the defensive controls around it.

Mutable Reference As Immutable. Another frequent instance. New ecosystems tend to default to name-based references (tags, versions, aliases) because content-based ones are operationally harder. The pattern inherits from the older ecosystem without the mitigations older ecosystems now apply.

Trust Inversion. Structural cousin. Unsigned-ecosystem-echo is a trust-inversion environment: every consumer extends trust to publish mechanisms that have not earned it yet, and the consequences are the same shape as any trust-inversion incident, just with less of the defensive scaffolding that older ecosystems eventually built.

A new registry is not a new problem. A new registry is an old problem with a new logo.