A compromise where the attacker publishes a malicious package version directly to a package registry without changing the upstream source repository. The published artifact becomes the threat vehicle, so repository review alone is insufficient. Defences must compare lockfiles, inspect tarballs, and monitor runtime behaviour after dependency resolution.
Expanded Definition
A registry-only supply chain attack targets the distribution layer of software rather than the source code history. The attacker publishes a malicious package version to a public or private registry, while the upstream repository may remain unchanged, unsigned, or apparently benign. That distinction matters because many review processes still assume the repository is the source of truth, even though package managers ultimately install the artifact pulled from the registry. In supply chain security, this is a distribution integrity problem, not just a code review problem, and it aligns closely with controls discussed in NIST SP 800-53 Rev 5 Security and Privacy Controls around configuration integrity and software provenance.
Definitions in the industry are still evolving around whether registry-only compromise includes namespace hijacking, maintainer account takeover, or purely malicious republishing. NHIMG treats the term narrowly: the package in the registry is the threat vehicle, regardless of whether the source repo was altered. The most common misapplication is assuming upstream repository review is sufficient, which occurs when teams do not verify the registry artifact, lockfile resolution, or package metadata before deployment.
Examples and Use Cases
Implementing defences against registry-only attacks rigorously often introduces release friction, requiring organisations to weigh faster dependency adoption against stronger artifact verification and approval steps.
- A developer installs a dependency from a registry after a maintainer account is compromised, and the malicious version is consumed by CI before anyone notices the source repository remains unchanged.
- A package name is similar to a popular library, and the attacker publishes a poisoned version to a registry so automated dependency resolution pulls the wrong artifact into the build.
- A private internal registry mirrors external packages, but the sync process fails to validate signatures or checksums, allowing a tampered artifact to propagate downstream.
- A security team detects suspicious runtime behaviour only after deployment, forcing a rollback and forensic comparison between the lockfile, tarball contents, and the resolved dependency graph.
- During incident response, analysts correlate package publishing activity with indicators in CISA cyber threat advisories and validate whether the malicious artifact was introduced through registry distribution rather than source control.
For software teams that support AI-enabled applications or agentic tooling, registry abuse can also become an identity and secrets problem when a dependency is granted access to tokens, service credentials, or build-time credentials. That is why package integrity checks and dependency hygiene are increasingly discussed alongside OWASP Non-Human Identity Top 10 guidance, especially where automation accounts and machine credentials can be abused through a compromised package path.
Why It Matters for Security Teams
Registry-only supply chain attacks matter because they exploit the gap between code provenance and artifact provenance. Security teams that only trust source repositories can miss the actual object that enters build pipelines, container images, and production deployments. The operational impact can include poisoned dependencies, credential theft, hidden remote execution, and difficult-to-trace lateral movement through trusted software channels. This is especially serious in environments that depend on package registries, artifact stores, and automated CI/CD pipelines, where one malicious publish can propagate quickly across teams and services.
For identity-heavy environments, the risk extends to non-human identities and automation credentials. A malicious package may inherit permissions from build agents, deployment bots, or service accounts, which is why NHIs must be treated as enforceable trust boundaries rather than background infrastructure. Threat reporting from Anthropic — first AI-orchestrated cyber espionage campaign report shows how attacker tradecraft increasingly combines automation, tooling abuse, and rapid operational chaining, while broader trend analysis in the ENISA Threat Landscape reinforces the need for resilient supply chain controls. Organisations typically encounter the full impact only after a build has already been promoted or a credential has been exposed, at which point registry provenance becomes operationally unavoidable to address.
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 and MITRE ATLAS address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.DS | Covers data and software integrity protections relevant to poisoned registry artifacts. |
| NIST SP 800-53 Rev 5 | SI-7 | System and information integrity controls address malicious code and tampering in supply chains. |
| OWASP Non-Human Identity Top 10 | Registry compromise often abuses non-human identities used by build and release automation. | |
| NIST AI RMF | AI RMF applies when agentic or AI-assisted pipelines consume compromised package artifacts. | |
| MITRE ATLAS | Adversarial ML frameworks help when registry abuse targets AI toolchains or model dependencies. |
Inventory automation identities and restrict their registry publish and install privileges.
Related resources from NHI Mgmt Group
- Why do exposed model registry tokens create supply-chain risk?
- Who is accountable when a package token is abused in a supply-chain attack?
- How should security teams handle exposed developer secrets after a supply chain attack?
- What breaks when a supplier account is compromised in a supply chain attack?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 26, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
