How would you audit who still holds publish rights across your organization's public packages?

Publish rights are the most quietly accumulating privilege in an engineering organization. Nothing expires. A co-maintainer added five years ago for one merged pull request still holds the right to push a version of a package your build installs, and no system will ever bring it to your attention. An audit is the only thing that finds it. ## Step 1 - the inventory is the hard part There is no single place that lists "everything we publish". Each ecosystem carries its own owner model and they do not agree with each other: a scope with organization roles on npm, per-project owner and maintainer roles on PyPI, a Maven Central namespace tied to an account and a verified domain, crate owners including team owners on crates.io. Nothing joins them. So the inventory is built, not queried. Start from three sources and reconcile them: - what your repositories publish, since release configuration names the destination; - what each registry says your organization *and your individual people* own, including personal accounts of current employees; - what your own builds resolve internally, which surfaces names nobody remembers owning. The output is a list of namespaces with a named human accountable for each. Half the value of the exercise is discovering the packages that appear on nobody's list. ## Step 2 - enumerate principals, not just people For each namespace, two lists matter, and registries store them separately: - **humans** with owner or publish rights; - **machine credentials** - publishing tokens, automation accounts, release identities. The critical subtlety: **removing a person does not invalidate a token they created.** On several registries a publishing token is an independent credential that keeps working after its creator has been removed from the package or has left. An offboarding process that deletes accounts and calls it finished can leave live publishing credentials behind. Tokens have to be enumerated and rotated deliberately, as their own step. ## Step 3 - join against reality and cut For every human, ask two questions: is this person still here, and do they still need this? The second one is the question people skip. Rights granted for a reason that has ended - a migration, a single fix, a team you have left - should go by default. The bar for keeping a right is a current need, not a past contribution. In an open-source project the same rule applies with more courtesy: notify the dormant maintainer, offer triage or review access instead, and remove the publish right anyway. Publishing rights are not a thank-you note. For machine credentials, ask what each one can reach. A token that can publish every package in a scope should be replaced by one scoped to a single package, and better still by a short-lived credential issued to a specific release job instead of a long-lived secret sitting in a settings page. ## Step 4 - make the result durable A one-off audit decays back to where it started within a year. Three things keep it alive: - **a cadence** - annually at minimum, and always on a departure or a team change; - **a narrow default** - the smallest set of identities that can publish, so that "who could have published this version" has a short answer; - **a dated record** of what the rights were and what you revoked, which is what lets you answer a question about a release from six months ago. ## What this is really protecting The asset here is not customer data; it is **the answer to "was this release legitimate?"**. Every extra dormant principal widens the set of accounts an attacker can compromise in order to publish under your name, and at the same time destroys your ability to attribute a release when something goes wrong. A shared account is the extreme case: it makes every publish unattributable by construction, so the investigation starts with nothing. ## The senior signal Interviewers listen for three things here: that you build an inventory rather than assume one exists, that you know credentials survive the removal of their owner, and that you treat the review as recurring with a narrow default rather than as a one-time cleanup. A candidate who answers "offboarding removes their access" has described a process that misses the two cases that matter most - the dormant external co-maintainer, and the token.