A dependency just added a co-maintainer whose account is six weeks old — what does that signal actually tell you?

## Why this is the only visible event The human layer of the supply chain is mostly invisible to a consumer. You cannot see a stolen laptop, a phished session or two years of trust-building on a project you have never heard of. What you *can* sometimes see is a change to the **maintainer set**: a new co-maintainer, a namespace or group identifier transferred to a different owner, a first release published by an identity that has never published before, a new signing key. That is the coarse, cheap signal, and it is the one worth wiring into your process — not because it detects an attack, but because it marks the moment the trust basis behind a dependency changed. ## Sorting the signals by forgeability **Cheap and therefore near-worthless on its own:** - Account age. It costs nothing to create an account and wait. An attacker running a two-year plan is not inconvenienced by a one-year threshold. - Contribution history and activity graphs. Volume is trivially generated across projects nobody reads; a busy-looking history is a purchase, not an achievement. - Profile completeness: photo, biography, links, followers. All self-asserted, all cheap, and social proof can be manufactured by the same accounts that manufacture pressure on a maintainer. - Issue and discussion presence. Useful-looking participation is exactly what the long-game path produces on purpose. **Expensive, because it lives in a system the attacker does not own:** - The registry's publication record: which identity published each historical version, and when that changed. - Signing-key history: whether releases have been signed by the same key over a long period, and whether a new key appeared without explanation. - Ownership and namespace records: whether the package sits under an organisation with several owners or under one personal account, and whether ownership was transferred. - Corroboration across independent systems: the same identity being the publisher of record over years, referenced from places the attacker cannot edit. The division is the lesson: **evidence is worth what it costs the attacker to fake.** Everything on the first list costs patience; everything on the second costs access to somebody else's infrastructure. ## The inherited package case The sharpest version of this is a package handed over rather than co-maintained. A utility library's original author, after years of unanswered issues, gives the namespace to the one stranger who volunteered. What survives the handover: the package name, its download count, its reputation, its position in every lockfile and manifest in the world, and every pin already recorded against it. What changes completely: who may publish under that name, whose key signs, and what release process runs. For a consumer this is a substitution at the trust anchor with no version bump to announce it. Your dependency edge still points at the same coordinates, so nothing in your tooling notices — and the *next* release under that name is authorised by an entirely different party than the releases you originally evaluated. This is also why audit trails matter here: if you cannot say who published each version you consumed, you cannot later reason about which of your artifacts predate the handover. ## What to actually do with the signal 1. **Treat it as a trigger, not a verdict.** A new co-maintainer is not evidence of an attack — it is how healthy projects survive. Reacting by removing the dependency is usually wrong, and moving to an obscure fork trades a known risk for an unknown one. 2. **Freeze rather than flee.** Hold the pinned version you have already been running. You are not obliged to move at upstream's pace. 3. **Extend the soak on the next release.** Let time and other consumers pass over the new publisher's first release before you ingest it. Time is the cheapest control you have against a payload that must eventually execute somewhere. 4. **Review the change, not the person.** For a dependency that matters to you, read the diff of the first release under the new publisher. Judging the human by their profile is judging exactly the artifact the attacker controls. 5. **Record the publisher of record.** Keep, per consumed version, who published it. That is what lets you scope the blast radius later, and it is why verification is worth keeping even though it cannot prevent this class. 6. **Rank by exposure, not by alarm.** Maintainer changes happen constantly across a large dependency graph. Spend the scrutiny where the dependency is load-bearing or executes at install or build time, and let the rest ride on the soak period. ## The failure modes to avoid The naive version of this control is a rule like "reject any package whose maintainers changed in the last ninety days" or "require every maintainer account to be a year old." Both generate constant noise on healthy projects, both are trivially outwaited, and both push teams toward ignoring the alert entirely — which costs you the one genuine signal the human layer offers. The mature version is quieter: notice the change, slow down, and put human attention on the diff of what actually ships.