An install-time supply chain attack uses software distribution mechanisms, rather than application logic, to execute malicious code. The attacker benefits from trust in packages and package managers, then targets secrets or systems that the install process can reach.
Expanded Definition
An install-time supply chain attack exploits the trust placed in software installation workflows, package registries, build scripts, dependency resolvers, or container image pulls. The attacker does not need to change the product’s core business logic; instead, malicious code is introduced when software is fetched, unpacked, compiled, or initialised. In practice, this can affect open source packages, private dependency mirrors, CI/CD pipelines, and even installer hooks that run with elevated privileges.
What makes this term distinct is that the compromise happens at the point of acquisition or installation, not after the application is already running normally. That makes it especially relevant to identity and secrets exposure, because install processes often inherit developer credentials, API tokens, SSH material, or cloud access needed for provisioning. Guidance on supply chain risk is still evolving across toolchains, but the security objective is consistent: reduce trust in the install path and verify what is being executed. NIST control families such as configuration management and system integrity provide a useful baseline, and package integrity practices are reinforced across the broader ecosystem by resources like the NIST SP 800-53 Rev 5 Security and Privacy Controls.
The most common misapplication is assuming a signed package alone is safe, which occurs when teams trust signatures without validating the publisher, transitive dependencies, or install scripts.
Examples and Use Cases
Implementing install-time safeguards rigorously often introduces workflow friction, requiring organisations to weigh developer velocity against stronger verification, tighter approvals, and more deterministic builds.
- A malicious dependency runs a post-install script that exfiltrates environment variables, including CI secrets and cloud tokens, during package installation.
- A compromised registry serves a trojanised version of a popular library, and the installer pulls it automatically because the version constraint is too broad.
- A build pipeline installs a package from a mirror that was not integrity-checked, letting injected code execute before test or release stages begin.
- A container image includes a setup step that fetches remote content at install time, creating a hidden execution path that bypasses normal application review.
- An AI coding assistant suggests a dependency that looks legitimate, but the install script behaves like a dropper when the package manager resolves it in CI.
Frameworks and advisories from CISA cyber threat advisories and the MITRE ATT&CK Enterprise Matrix are useful for mapping how adversaries use trusted execution paths, even though the attack surface is broader than any single technique catalog.
Why It Matters for Security Teams
Install-time attacks matter because they collapse the boundary between software procurement and execution. If a package manager, installer, or bootstrap script can reach production credentials, then compromise during installation can become a direct route into cloud accounts, build infrastructure, or downstream customer environments. For NHI governance, this is a major issue: service accounts, automation tokens, and agentic workflows often exist precisely to let software install, update, or deploy other software. The OWASP Non-Human Identity Top 10 is relevant here because install paths frequently touch machine identities that are over-permissioned, long-lived, or insufficiently monitored.
Security teams need to treat install-time trust as a control point, not a convenience. That means constraining scripts, pinning versions, verifying provenance where possible, and ensuring install-only credentials cannot later be reused for broader access. It also means watching for adversary tradecraft that blends software compromise with identity theft and hands-on-keyboard persistence, as highlighted in the Anthropic, first AI-orchestrated cyber espionage campaign report and the ENISA Threat Landscape.
Organisations typically encounter the full impact only after a build agent, developer workstation, or deployment pipeline has already been abused, at which point install-time supply chain attack containment 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 SP 800-53 Rev 5, NIST AI RMF and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.DS-6 | Protects integrity of software and firmware during acquisition and deployment. |
| NIST SP 800-53 Rev 5 | SI-7 | Supports software, firmware, and information integrity checks for install paths. |
| OWASP Non-Human Identity Top 10 | Covers machine identities and secrets often exposed during install-time compromise. | |
| NIST AI RMF | Applies when AI tools or agents participate in software installation workflows. | |
| NIST SP 800-63 | AAL2 | Relevant where install workflows depend on stronger authenticator assurance. |
Assess install-time AI-assisted workflows for provenance, misuse, and accountability.
Related resources from NHI Mgmt Group
- How should teams respond when a supply chain attack reaches GitHub and cloud secrets at the same time?
- How should security teams handle a supply-chain malware event that runs during npm install?
- 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?
