A condition where two layers or packages try to place different content at the same filesystem path. In Lambda, the later extraction wins, which can replace a legitimate file or executable. Path collisions are security relevant because they can redirect execution without changing the visible function configuration.
Expanded Definition
Path collision is a packaging and deployment issue that occurs when multiple artifacts in a runtime or build pipeline target the same filesystem location. In serverless and containerised environments, the winner is often determined by extraction order, build order, or layer precedence, not by an explicit security decision. That makes the condition operationally dangerous because the visible configuration can remain unchanged while the actual file content or executable path has been replaced.
In cloud and identity-adjacent systems, the risk is highest when build artefacts, dependencies, and runtime layers are assembled from separate sources without strict path validation. Path collision is related to supply chain integrity, but it is not the same as generic dependency risk. The concern is not merely that unwanted code exists, but that two legitimate packages can overwrite one another at a shared location. NIST control families for configuration management and system integrity provide the closest governance lens here, including the expectations described in NIST SP 800-53 Rev 5 Security and Privacy Controls.
The most common misapplication is treating path collision as a harmless packaging quirk, which occurs when teams assume extraction order cannot alter executable behaviour.
Examples and Use Cases
Implementing path collision controls rigorously often introduces stricter build constraints, requiring organisations to weigh deployment convenience against deterministic file placement.
- A Lambda layer includes a shared library at the same path as a library bundled in the function package, and the later extraction silently replaces the intended version.
- Two internal packages install scripts or binaries to the same directory during CI/CD, causing one release artifact to override another without an obvious build failure.
- A container image combines a base image and an application layer that both write to the same executable path, changing which file is actually invoked at runtime.
- An attacker with limited influence over a supply chain component introduces a colliding file so that a benign-looking path resolves to altered content after deployment.
- Security teams detect a path collision during artifact inspection and block release because the final runtime state no longer matches the reviewed source package set.
Good practice is to treat each deployment artifact as a deterministic mapping from source to final path, then verify that mapping before release. Teams that document file ownership, enforce unique install locations, and compare build outputs against expected hashes reduce the chance that a silent overwrite becomes an execution issue.
Why It Matters for Security Teams
Path collision matters because it creates a gap between what defenders review and what actually runs. That gap is especially important in cloud workloads, where ephemeral packaging steps can hide the exact moment a file is replaced. For security teams, this is a configuration integrity problem first and a code problem second. The practical risk is that trusted deployment pipelines can be used to swap binaries, redirect imports, or alter helper scripts without changing the top-level service definition.
For identity and NHI-adjacent environments, the same pattern can affect agents, automation jobs, and secrets-handling utilities if their supporting files collide with other bundled content. If a token helper, credential loader, or policy script is overwritten, the resulting behaviour can undermine access control assumptions even when IAM settings appear correct. That is why path collision should be reviewed alongside build provenance, artifact integrity, and runtime verification. Organisationally, it often remains invisible until a deployment behaves unexpectedly, at which point the path layout itself becomes part of incident response.
Organisations typically encounter the impact only after a deployment outage, code-path diversion, or integrity alert, at which point path collision 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 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.IP-1 | Configuration baselines and change control address unintended file replacement. |
| NIST SP 800-53 Rev 5 | CM-2 | Baseline configuration control helps prevent silent overwrite of runtime files. |
| OWASP Non-Human Identity Top 10 | NHI workloads can inherit path collision risk in their packaged helpers and agents. |
Enforce build and deployment baselines so final artifacts match approved configuration.
Related resources from NHI Mgmt Group
- Why do leaked secrets need a different reporting path than ordinary software bugs?
- How should security teams prevent hardcoded secrets from becoming a breach path?
- What breaks when organisations do not map the access path of AI and SaaS integrations?
- How should organisations respond when a privileged SSH certificate path is flawed?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 1, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
