Supply Chain Lateral Movement

The use of legitimate access obtained from one trusted tool to reach another system in the delivery chain. Instead of exploiting one host directly, the attacker follows authorised relationships between build, security, and deployment tools until broader compromise is achieved.

Expanded Definition

Supply chain lateral movement is a tradecraft pattern in which an attacker does not start by breaking into the final target directly. Instead, they pivot through trusted relationships inside the delivery chain, such as source control, CI/CD, build runners, package registries, signing services, deployment automation, and observability tooling. In NHI security, this matters because the path is often enabled by legitimate service identities, tokens, or API keys that were granted broad machine-to-machine reach. The pattern overlaps with supply chain compromise, but it is narrower: the emphasis is on moving sideways across authorised tool-to-tool trust, not merely planting malicious code.

Usage in the industry is still evolving. Some teams describe this as supply chain compromise, while others reserve lateral movement for post-compromise propagation. In practice, both views are useful, because the defender must understand how one trusted credential can unlock adjacent systems. The OWASP Non-Human Identity Top 10 frames this as an identity and secrets problem as much as a code integrity problem, especially when service accounts have persistent permissions across environments. The most common misapplication is treating it as a pure malware issue, which occurs when defenders ignore how trusted automation and over-scoped NHI credentials let the attacker keep moving without triggering host-based alerts.

Examples and Use Cases

Implementing detection and containment for supply chain lateral movement often introduces operational friction, requiring organisations to balance delivery speed against tighter identity controls and more selective trust relationships.

• A compromised GitHub Action token is used to read package publish credentials, then the attacker pivots into the artifact repository and injects a backdoored release.
• A CI/CD runner with access to cloud deployment roles becomes the bridge from a build compromise into production infrastructure, especially when long-lived secrets remain available on the runner.
• An attacker abuses a trusted security scanner integration to enumerate internal endpoints and then accesses adjacent systems through the scanner’s privileged API scope, a pattern reflected in cases such as the Reviewdog GitHub Action supply chain attack.
• A malicious or compromised dependency manager reaches package signing infrastructure after first obtaining a narrow but valid automation credential, similar to the techniques discussed in the MITRE ATT&CK Enterprise Matrix.
• An attacker uses one leaked secret from a code repository to reach adjacent collaboration or release systems, then expands access through linked service accounts, as seen in the 52 NHI Breaches Analysis.

For defenders, the practical question is not whether the first compromise occurred in code, build, or deployment. It is whether the trusted handoff between tools was designed to stop one credential from becoming a chain of system-wide access.

Why It Matters in NHI Security

Supply chain lateral movement is dangerous because it turns legitimate automation into an attack path. When service identities, tokens, and certificates are reused across multiple stages of delivery, the attacker does not need to defeat each environment separately. One successful pivot can expose source code, signing keys, deployment credentials, and downstream customer systems. This is why NHI governance must treat trust boundaries as access boundaries, not just network boundaries. The associated risks are amplified by secret sprawl, because leaked credentials often remain valid long enough to be reused elsewhere.

NHIMG research shows that only 44% of developers follow security best practices for secrets management, which helps explain why lateral movement through delivery tooling persists even in mature environments. The State of Secrets in AppSec also found that the average time to remediate a leaked secret is 27 days, a delay that gives attackers ample time to move between trusted systems. Defenders should connect this term to identity scoping, secret rotation, and segmentation of pipeline privileges. Organisations typically encounter the operational cost of this pattern only after a build, release, or signing system has been abused, at which point supply chain lateral movement becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• How should security teams reduce lateral movement risk after a fast exploit chain succeeds?
• Why do static tokens increase lateral movement risk in software supply chains?
• Which controls matter most when a lateral movement chain begins?
• What is supply chain amplification in Agentic AI security?