What every developer should know about dependency security

You probably have a dependency scanner. You might have Dependabot configured, or Snyk running in CI, or a GitHub security alert set up on your repos. That is a reasonable baseline and it was sufficient for most threat models two years ago.

It is not sufficient for the 2026 threat model.

This is not a post about buying more tools. It is about understanding what the tools you already have do and do not catch, and making a few concrete decisions based on that understanding.

What your scanner actually checks#

Most dependency scanners, including Dependabot, Snyk, npm audit, and Safety for Python, check the CVE database. They look at the packages in your lockfile, compare the versions against known vulnerability records, and flag anything with a published CVE above your severity threshold.

This is genuinely useful. CVE-based scanning catches real vulnerabilities: Log4Shell would have flagged, Spring4Shell would have flagged, the OpenSSL vulnerabilities would have flagged. Keep running it.

What it does not catch is a package that has been compromised by an attacker who published a malicious version using a stolen maintainer credential. Because that attack does not generate a CVE. It generates an OSV malware advisory, or a Socket security report, or a BleepingComputer article, none of which are in the CVE database your scanner is reading.

[email protected], [email protected], [email protected]: all three were actively malicious and carrying North Korean malware in 2026. All three would have passed your CVE scanner clean. Combined they cover an estimated 80% of Node.js cloud environments.

The lockfile is not a guarantee#

Pinning your dependencies to specific versions in a lockfile is good practice. Do it. npm ci over npm install every time in CI.

What pinning does not protect against: a version that was clean when you pinned it and then got compromised after the fact. ChainDrop in August 2026 compromised keyv, flat-cache, and cacheable, packages that were in millions of lockfiles as trusted pinned dependencies. Updating or removing the package does not undo what already ran.

If a compromised package was installed and ran in your environment, treat every credential that process could access as potentially exfiltrated. npm tokens, GitHub tokens, cloud credentials, AI provider API keys. The 2026 campaigns were specifically targeting all of these.

Install scripts are not the only execution path#

The conventional advice when a suspicious package surfaces is: run npm install --ignore-scripts to prevent lifecycle hooks from firing. This stops preinstall and postinstall scripts, which is how most malicious packages delivered their payloads in 2020 and 2021.

The 2026 campaigns have adapted. JoyFill, ViteVenom, the Alibaba dependency confusion cluster, and the WEL1DROPPER flooding campaign all deliver their payloads at import time rather than install time. The malicious code runs when your application loads the module, not when npm installs it. --ignore-scripts does not stop this. The first require() or import of the affected module is enough.

The practical implication: you cannot rely on install-time controls alone. A package that passes a clean install can still execute malicious code the first time your application starts.

AI coding assistants introduce a new vector#

If you use Copilot, Cursor, Claude Code, Windsurf, or any AI coding assistant, you have a new dependency security exposure that did not exist three years ago.

AI models hallucinate package names. Not rarely: commercial models do it at an average 5.2% rate across tested prompts, and 43% of the names that get hallucinated repeat consistently across multiple runs of the same prompt. Attackers have started registering those predictable hallucinated names.

Amazon's July 2026 attribution report confirmed that North Korean state actors are actively using this technique, registering package names that AI assistants predictably recommend, and waiting for developers or autonomous agents to install them. A Russian campaign in August published over 700 packages using AI-hallucinated names.

The check is simple: before installing a package an AI assistant recommended, verify it exists on the registry with a real author and a real download history. npm info package-name before npm install package-name. It takes five seconds and it catches the attack before anything runs.

What autonomous agents change#

If you are building anything with an AI agent that can install packages or execute code, the exposure profile is different from a human developer workflow.

A human developer who sees an unfamiliar package name in an AI suggestion can pause, check it, decide not to install it. An autonomous agent that receives a task, generates install commands, and executes them without a review step cannot do that unless the check is built in.

This is not a hypothetical risk. ENCFORGE, the AI-specific ransomware documented in July 2026, entered through CVE-2025-3248 in a Langflow instance that an autonomous agent was running. The CVE had been public and patched for over a year. The agent was not checking whether the version it was running had known critical vulnerabilities before proceeding. The full account is in the thesis.

If you are building autonomous systems that touch dependencies or infrastructure, build the security check into the agent's decision loop rather than assuming a human will catch what the agent misses.

The practical steps that actually help#

Run CVE scanning and keep it running. It catches real vulnerabilities. It is not sufficient on its own but it is necessary.

Add supply chain compromise monitoring. This is the signal CVE scanning misses. The two signals are independent: a package can have a critical CVE and a clean supply chain, or a compromised supply chain and zero CVEs. Both checks are needed.

Use npm ci in CI, not npm install. This enforces your lockfile exactly. It does not protect against a compromised version in the lockfile but it prevents unexpected version resolution surprises.

Verify AI-recommended package names before installing. Five seconds of npm info catches the slopsquatting attack before it runs.

Treat compromised environment credentials as exposed. If a package with a supply chain compromise ran in an environment, rotate every credential that environment had access to. This is not optional.

Monitor continuously, not just at install time. A package that was clean when you installed it may have been compromised since. Static scanning at install time does not catch this.

Where to go from here#

The npm supply chain attacks pillar covers the three main attack vectors in technical detail with 2026 examples.

The vs-nvd page makes the case for why CVE-based signals and supply chain signals are independent and why both matter.

The use-cases/cicd page covers how to integrate supply chain checks into a pipeline.

If you are building with AI agents specifically, the docs/ai-agents page covers the integration patterns for checking dependencies before an autonomous system acts on them.

---