Why do shared data directories increase supply chain risk in ML pipelines?

Shared data directories blur ownership between packages and reuse the same on-disk state across projects. If extraction rules do not bind files to the correct package identity, one archive can populate another package’s namespace. That turns a local download issue into a persistent supply chain problem.

Why This Matters for Security Teams

Shared data directories create a trust boundary problem, not just a file management problem. When multiple ML packages, build jobs, or agentic workflows write into the same path, the directory becomes a cross-package control plane that can be influenced by whatever lands there first. That is especially dangerous when extraction logic assumes the archive itself is trustworthy and does not bind files to package identity at write time.

In supply chain terms, the risk is persistence. A single contaminated download can populate a namespace that later jobs reuse, turning a one-time ingestion issue into a durable compromise. This is why directory reuse belongs in the same conversation as secrets exposure and dependency integrity, as seen in the Guide to the Secret Sprawl Challenge and the CI/CD pipeline exploitation case study. The pattern also aligns with broader control guidance in the OWASP Non-Human Identity Top 10, where unmanaged machine-to-machine trust repeatedly expands blast radius.

In practice, many security teams encounter namespace poisoning only after a package cache or shared workspace has already been reused by multiple pipelines.

How It Works in Practice

In a well-designed ML pipeline, each package or job should write into an isolated staging area, then promote only verified outputs into a controlled location. Shared directories undermine that model because they let unrelated processes co-mingle extracted archives, model artifacts, datasets, and helper files. If the unpacking process accepts relative paths, symlinks, or path traversal without strict validation, one package can place files that another package later imports or executes.

The practical control is simple in principle but easy to miss in implementation: treat every extracted file as untrusted until it is mapped to the correct package identity. That means using per-job sandboxes, immutable caches where possible, content-addressed storage, and explicit ownership checks before promotion. It also means verifying provenance before reuse, not assuming that a filename, directory name, or previous job result is still safe.

• Separate download, extraction, and promotion stages so a failed validation cannot leave residue for later jobs.
• Bind write permissions to a single workload identity rather than a shared service account.
• Reject archives that attempt to escape the intended directory or overwrite existing package-owned files.
• Use short-lived workspaces and delete them after task completion.

For threat modeling, the key lesson is that shared state converts a local integrity issue into a supply chain issue because the next consumer inherits the compromise. That is consistent with the operational patterns documented in the Reviewdog GitHub Action supply chain attack and the secrets exposure trends summarized in The State of Secrets in AppSec. These controls tend to break down in monorepos, shared runners, and long-lived build caches because multiple pipelines can read and write the same filesystem state.

Common Variations and Edge Cases

Tighter isolation often increases build time, storage use, and pipeline complexity, so organisations have to balance speed against contamination risk. That tradeoff becomes more visible in large ML estates where teams want cache reuse for performance but also need deterministic, package-scoped state for security.

There is no universal standard for this yet, but current guidance suggests that the safest pattern is to minimize mutable shared directories and constrain them to read-only artifacts wherever possible. Shared caches may still be acceptable for public, reproducible dependencies if integrity checks are strong, but they are much riskier for private models, generated code, and extraction steps that accept arbitrary archives. The problem is amplified when workflows pull from external registries or transient package mirrors, because provenance becomes harder to prove after the fact.

Two NHIMG cases illustrate why this matters operationally: the LiteLLM PyPI package breach and the Shai Hulud npm malware campaign both show how fast package trust can collapse once attacker-controlled content is allowed into shared workflow state. In mixed-trust environments, shared directories tend to fail when multiple teams reuse the same runner image or cache key because ownership and provenance no longer stay aligned.

Related resources from NHI Mgmt Group

• Why do developer workstations increase the blast radius of supply-chain malware?
• How do attackers turn a supply-chain incident into wider NHI compromise?
• How should security teams reduce supply chain risk in GitHub-based development pipelines?
• Why do AI coding agents increase supply-chain risk?