A supply-chain tactic where a malicious package, repository, or tool imitates legitimate software closely enough to win trust before execution. It uses naming, version churn, commit activity, and search visibility to make the target accept the software as normal.
Expanded Definition
Software acquisition impersonation is a supply-chain deception pattern in which a malicious package, repository, or developer tool is made to resemble trusted software closely enough that an operator, pipeline, or agent accepts it as legitimate. In NHI and agentic systems, the risk is not only code execution, but the acquisition of trust by an identity-bearing artifact that can be installed, mirrored, or invoked automatically.
The tactic usually depends on visual and behavioural similarity: names that differ by a character, release histories that look active, commit churn that suggests legitimacy, and search results that surface the impersonated artifact before the real one. Industry usage is still evolving, but the practical boundary is clear: the impersonation occurs before execution, during the selection and trust decision. That makes it adjacent to typosquatting, dependency confusion, and malicious open-source publishing, but broader because the target can be any acquisition channel, not just a package registry. Guidance in NIST SP 800-53 Rev 5 Security and Privacy Controls helps organisations frame this as a provenance, integrity, and authorization problem rather than a simple malware problem.
The most common misapplication is treating it as a developer hygiene issue only, which occurs when procurement, CI/CD, and autonomous agents are all allowed to trust acquisition metadata without independent verification.
Examples and Use Cases
Implementing acquisition controls rigorously often introduces friction in build and onboarding workflows, requiring organisations to weigh faster adoption against stronger provenance checks.
- A developer installs a package whose name differs by one character from a popular library, and the malicious version is pulled into a build before review.
- A CI pipeline mirrors a repository that has convincing commit history and release tags, but the upstream owner is an impersonator rather than the legitimate maintainer.
- An AI agent with tool access selects a “recommended” plugin from search results, then executes it because the metadata appears reputable and recent.
- A platform team approves an internal dependency because it matches the expected vendor branding, even though its signing chain and publisher identity are inconsistent.
These patterns are especially relevant where software is consumed automatically and at speed. The NHI Mgmt Group notes that Ultimate Guide to NHIs is a useful reference for understanding why third-party exposure and secret handling amplify supply-chain risk. For implementation context, NIST SP 800-53 Rev 5 Security and Privacy Controls supports requirements around supplier oversight, integrity checks, and controlled system changes. The same logic applies when an agent is the consumer, not a human.
Why It Matters in NHI Security
Software acquisition impersonation matters because NHI environments often trust machines to make rapid accept-or-reject decisions on software, keys, and integrations. Once a malicious artifact is admitted, it can inherit execution paths, access tokens, service-account permissions, and automation reach that were intended for legitimate software. In practice, the harm is amplified when secrets are cached, pipelines are over-permissioned, or agents are allowed to install tools without separate verification.
NHIMG research shows that 92% of organisations expose NHIs to third parties, which makes supplier trust and acquisition integrity a direct security concern rather than a niche risk. This is why identity governance cannot stop at accounts and keys; it must extend to the software that is allowed to obtain, present, or consume those credentials. Controls from NIST SP 800-53 Rev 5 Security and Privacy Controls are relevant because provenance, change control, and supply-chain assurance all shape whether the impersonation succeeds.
Organisations typically encounter the operational impact only after a suspicious package is already executing in CI or an agent has pulled a hostile tool, at which point software acquisition impersonation 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 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Covers secret and trust abuse in non-human identity supply paths. |
| NIST CSF 2.0 | ID.SC-4 | Addresses supplier and third-party risk in the software acquisition chain. |
| NIST Zero Trust (SP 800-207) | SC-7 | Zero Trust requires explicit verification of every access path and source. |
| NIST SP 800-63 | IAL2 | Identity assurance concepts inform trust in publishers and maintainers. |
Treat acquisition sources as untrusted until identity and integrity are verified.
Related resources from NHI Mgmt Group
- What does the Cisco acquisition of Astrix Security mean for NHI tooling?
- Should IAM teams re-evaluate their NHI tooling choices after a major acquisition?
- How should security teams handle exposed secrets in modern software pipelines?
- What is the difference between software supply chain risk and NHI risk?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
