Why do AI-suggested dependencies create supply chain risk?

Why This Matters for Security Teams

AI-suggested dependencies turn package selection into a trust problem, not just a procurement problem. A model can produce a name that looks legitimate, and an attacker can register that name before anyone verifies provenance. That creates a clean path from suggestion to installation to compromise, especially when developers rely on autocomplete, bots, or rushed build steps. The risk is not limited to code repositories. It extends into CI/CD, internal package mirrors, and build automation.

Security teams often focus on malware inside known packages, but the more dangerous failure is installing a package that was never meant to be trusted in the first place. The pattern is familiar in supply chain incidents involving secrets exposure and dependency compromise, such as the LiteLLM PyPI package breach and the Shai Hulud npm malware campaign. The control gap is usually verification, not visibility. Current guidance suggests treating every AI-suggested dependency as untrusted until it passes registry, provenance, and policy checks. In practice, many security teams encounter the issue only after a build pipeline has already pulled the wrong package.

How It Works in Practice

Defending against AI-suggested dependency risk requires layered checks that happen before and during installation. The first layer is registry validation: confirm the package exists in an approved registry, belongs to the expected namespace, and matches an allowlisted publisher or maintainer. The second layer is provenance validation: verify signatures, attestations, or source-linked metadata so the build can distinguish a real package from a lookalike.

That approach aligns with the OWASP Non-Human Identity Top 10 and the NIST Cybersecurity Framework 2.0, which both emphasise controlled trust boundaries and repeatable protection. For dependency workflows, the operational pattern is straightforward:

• Require human approval or policy approval for any new package name suggested by an AI tool.
• Check whether the dependency is already mirrored in an internal repository before fetching externally.
• Validate package provenance, source repo linkage, and maintainer identity before install.
• Block typosquats, empty packages, and recently registered lookalikes unless explicitly approved.
• Record the dependency decision in CI/CD logs for later review and incident response.

NHIMG research on supply chain compromise shows how quickly malicious packages can weaponise trust, including the Mastra npm Supply Chain Attack and the Miasma and Hades Supply Chain Worms. Once a dependency reaches CI, it can inherit build-time secrets, tokens, and deployment reach. These controls tend to break down in fast-moving teams that auto-merge dependency suggestions into ephemeral build environments because verification is bypassed for speed.

Common Variations and Edge Cases

Tighter dependency controls often increase developer friction and pipeline latency, so organisations have to balance velocity against the cost of a compromised build. That tradeoff is especially sharp in AI-assisted coding environments, where suggestions arrive continuously and not every dependency is equally risky.

Best practice is evolving for generated suggestions versus existing dependencies. For established packages, teams may rely on lockfiles, internal mirrors, and periodic provenance checks. For brand-new names suggested by an AI agent, the safer posture is stricter: require explicit approval, verify the package’s publication history, and reject anything that cannot be traced to a trusted maintainer or source repository. This is particularly important when the agent has access to toolchains that can install packages automatically. The issue is not just the dependency name. It is the autonomous workflow that converts a suggestion into execution without enough scrutiny.

Some teams try to solve this with static allowlists alone, but that breaks down when packages are renamed, transferred, or republished by different maintainers. Others rely on a single malware scan after installation, which is too late if the package already executed postinstall scripts or exfiltrated secrets. Emerging practice suggests combining allowlists, provenance, and runtime policy, but there is no universal standard for this yet. Where internal package registries are unavailable, the fallback should be a denial-by-default model for AI-suggested additions, with manual review for exceptions.

Related resources from NHI Mgmt Group

• Why do vulnerable dependencies create such a large software supply chain risk?
• Why do transitive dependencies create more software supply chain risk than direct packages alone?
• Why do AI-generated package choices create more supply chain risk than normal developer workflows?
• Why do third-party dependencies create more supply chain risk than first-party code?