What breaks when a malicious dependency can execute on import in a build or ML pipeline?

Why This Matters for Security Teams

A dependency that executes on import collapses the boundary between “installing software” and “running attacker-controlled code.” In build systems and ML pipelines, that matters because package installation often happens inside environments that already hold secrets, signing keys, or write access to repositories and registries. Current guidance suggests treating dependency acquisition as a software supply chain control problem, not a routine developer convenience issue.

This is especially dangerous in CI/CD and model training flows, where automation increases the blast radius and reduces human scrutiny. A single compromised package can read environment variables, contact external infrastructure, or tamper with artifacts before anyone notices. Cases such as the Reviewdog GitHub Action supply chain attack and the LiteLLM PyPI package breach show how quickly installation-time trust can become credential theft. NHI Mgmt Group notes that 96% of organisations store secrets outside secrets managers in vulnerable locations, including code and CI/CD tools, which makes this failure mode far more common than many teams assume. In practice, many security teams encounter it only after tokens have already been exfiltrated from a build runner or notebook environment, rather than through intentional dependency review.

How It Works in Practice

The technical problem is that package managers and ML tooling frequently execute code during metadata resolution, setup, or import-time initialisation. That means the dependency can run with the full privileges of the process that loads it. In a developer laptop, that may expose local cloud credentials; in CI, it may expose deployment tokens, artifact signing keys, or repository write permissions. The right mental model is that install-time code is active workload code, not inert content.

Practical defenses start with isolating dependency evaluation from privileged environments. Teams should use ephemeral build workers, network-restricted runners, and separate stages for fetching, scanning, and executing packages. Runtime policy should assume that import can trigger side effects and should block outbound calls, filesystem writes outside approved paths, and access to injected secrets unless explicitly required. NIST Cybersecurity Framework 2.0 is useful here because it frames this as protect and detect work across the software supply chain, not just endpoint hardening. The Ultimate Guide to NHI is also relevant because build systems depend on service accounts, API keys, and other NHIs that must be tightly scoped and rotated.

• Pin and verify dependencies with hashes or signed attestations before installation.
• Run installs in disposable containers or sandboxes with no long-lived secrets loaded.
• Split package resolution from execution so review tools see what will be imported.
• Use read-only credentials for fetch steps and separate write credentials for release steps.
• Monitor for unexpected network access, file writes, or secret access during import.

Controls tend to break down when build images are reused across jobs or when notebook-style ML environments keep cloud credentials mounted persistently, because the malicious import can immediately reach high-value secrets.

Common Variations and Edge Cases

Tighter import controls often increase pipeline friction, requiring organisations to balance developer speed against the risk of silent code execution. That tradeoff becomes sharper in ML workflows, where transitive dependencies, custom operators, and notebook experimentation can make full package review impractical.

Best practice is evolving for environments that rely on plugin systems or dynamic model tooling. There is no universal standard for this yet, but the safest pattern is to treat every dependency as potentially executable and every pipeline identity as ephemeral. That means short-lived credentials, separate trust zones for training and deployment, and explicit allowlisting for packages that may run code on import. The CI/CD pipeline exploitation case study shows how attackers move from one compromised runner to broader environment access once secrets are present. The Guide to the Secret Sprawl Challenge is also relevant because import-time execution becomes far more damaging when secrets are scattered across configs, env vars, and build artifacts.

In practice, the weakest point is usually not the package manager itself but the surrounding trust model: one dependency import inside a privileged runner can undo otherwise strong IAM design.

Related resources from NHI Mgmt Group

• What breaks when malicious package installs are allowed to execute code by default?
• Who is accountable when a malicious dependency enters a build pipeline?
• What breaks when a malicious package can use a GitHub token to exfiltrate files?
• How should organisations respond when malicious code has already run in a build or developer environment?