Both. The software supply chain side covers provenance, dependency trust and runtime execution, while the identity side covers who or what is allowed to publish, promote and consume packages. Teams need controls for package identity, build integrity and non-human workflows that install software without human review.
Why registry abuse belongs to both supply chain security and identity governance
Registry abuse sits at the point where software provenance and access authority meet. A package registry can be a distribution channel for tainted code, but it is also a place where publish rights, promotion paths, token scope and approval workflows determine who can change what reaches consumers. Treating it as only one problem leaves a real control gap.
Supply chain controls answer whether the artifact is trustworthy, reproducible and traceable from source to consumer. Identity governance controls answer whether the actor, token or automation that published it was authorised, whether access was excessive, and whether the workflow should have required human review or stronger segmentation.
That split matters because registry abuse rarely needs a single failure. Attackers or negligent insiders often combine weak package provenance with weak publishing governance: stolen tokens, overbroad CI credentials, compromised maintainer accounts or auto-publish flows can turn a routine release path into a silent distribution channel. The question is not which domain owns the registry, but which risks each domain is supposed to stop.
What each control plane is responsible for
On the supply chain side, the core concern is integrity. Teams need to know where a package came from, whether the build was tampered with, whether the published artifact matches the intended source, and whether consumers can verify that trust chain. Frameworks and controls for build provenance, signed artifacts and dependency integrity are the right lens for those checks. The right comparison is whether the artifact can be trusted, not merely whether the publisher had access.
On the identity side, the core concern is authority. Registry publishing, package promotion and consumption often happen through service accounts, automation tokens and CI/CD workflows, so the governance question becomes: who can publish, under what conditions, with which secrets, and with what level of privilege. That is where least privilege, short-lived credentials, approval gates and recertification reduce the chance that an abused token can ship malicious or unreviewed software.
Teams should also separate consumer trust from publisher trust. A package can be technically signed and still be dangerous if the signer or publishing workflow was compromised. Likewise, a human-approved change can still be unsafe if the registry permits token reuse, hidden promotion paths or uncontrolled machine-to-machine publishing. Good registry defence therefore requires both artifact-level verification and actor-level governance.
How teams should judge the right control mix
Start by asking which failure would hurt you most: bad code entering the registry, or the wrong actor being able to publish it. If the answer is “both,” then the registry needs a dual control model, with software supply chain checks on one side and identity governance on the other. That usually means provenance checks, build attestations and dependency policy, plus scoped registry roles, token hygiene, approval workflows and periodic access review.
For automated pipelines, the key decision is whether non-human workflows are allowed to publish without a separate trust boundary. If they are, then the workflow itself becomes a high-value identity that must be inventoried, limited and monitored like any other privileged actor. Teams should verify that package publish credentials cannot be reused broadly, that rotation is enforced, and that promotion between environments is not just an API call with a long-lived secret.
Where registry abuse is a known concern, identity and supply chain controls should converge at the same checkpoint: only trusted build outputs from trusted publishing identities should reach production registries. That is the practical line between “we built it” and “we can trust it.”
Risk and Threat Considerations
Registry abuse becomes dangerous when trust in the package is separated from trust in the publisher. An attacker who steals a publish token, compromises a maintainer account, or abuses a CI credential can inject malicious code into a path that defenders may assume is routine and low risk.
Failure mechanism: Weak provenance controls allow a tampered artifact to look legitimate, while weak identity governance lets an overprivileged human or machine identity publish or promote it without meaningful challenge.
Impact: Consumers may install malicious, altered or unreviewed packages at scale, creating code execution risk, dependency poisoning and downstream compromise across build and runtime environments.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and SLSA set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Registry abuse often depends on stolen or long-lived publish tokens. |
| IA-9 — Service Identification and Authentication | CI/CD and registry automation often publishes through non-human identities. | |
| AC-6 — Least Privilege | Registry publishing and promotion should be limited to the minimum necessary authority. | |
| Recommendation — Enforce lifecycle controls for registry tokens and revoke compromised credentials immediately. Require strong authentication for automated publishing identities and scope their access tightly. Restrict registry publish and promotion rights to the minimum set of trusted identities. | ||
| SLSA | Supply-chain Levels for Software Artifacts | Registry abuse directly implicates build provenance and artifact integrity. |
| Recommendation — Adopt stronger provenance and attestation requirements before packages are promoted. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Registry automation and service identities can become overly powerful publishing actors. |
| Recommendation — Reduce registry-related non-human privileges to the minimum required for publishing. | ||
Practitioner Guidance
What to prioritise: Treat registry publishing as a privileged operation. Separate the integrity question from the authorisation question, then require both to pass before a package is trusted downstream.
What to verify: Confirm who can publish, which tokens or service identities can promote artifacts, whether those credentials are scoped to one registry or one environment, and whether offboarding or rotation actually revokes registry access.
What good looks like: A package reaches consumers only after a trusted build, a verifiable artifact lineage and a narrowly authorised publishing path all align. If any one of those is missing, the registry is still exposed.
Practitioner takeaway: Registry abuse is not an either-or choice between supply chain and identity governance; the strongest programmes treat package trust and publish authority as separate controls that must both be true.
Related resources from NHI Mgmt Group
- How do security teams connect software supply chain controls to identity governance?
- Should security teams treat IDE extensions and agent helpers as part of software supply chain governance?
- How do security teams know if software supply chain governance is working?
- Which control should teams prioritise first in software supply chain governance?