npm Just Shipped New Supply Chain Controls. Watch How Your Organization Misreads Them.

GitHub’s new npm install source controls restrict non-registry install sources. The 2FA-gated publishing requirement adds a human approval step before a package becomes installable. Both are real improvements. Both will be filed under ‘ingestion governance’ in security program reviews. Neither one is.

npm shipped three new install source flags: — allow-file, — allow-remote, and — allow-directory. They give developers the ability to apply an explicit allowlist approach to every non-registry install source, local files, remote URLs, local directories. Alongside staged publishing, which requires a human maintainer to pass a 2FA challenge before a package becomes publicly installable, these are the two most substantive supply chain security changes the registry ecosystem has made in a recent wave of improvements.

They are worth understanding precisely. Because the gap between what they do and what a security program needs them to do is exactly where the next class of attacks will land.

What These Controls Actually Do

The install source flags are opt-in, per-project, and configured at the developer toolchain level. They govern where packages can come from. A developer who sets them correctly cannot install a dependency from a remote URL or a local path that bypasses the registry. That closes a real vector. TrapDoor and Glassworm both exploited non-registry sources and compromised developer environments as entry points, and controls that restrict those sources make that class of attack harder.

The operative word is configured. These flags have to be set. By developers. Per project. Which means your security posture, if it rests on install source controls, is exactly as consistent as your developer configuration discipline across every active project in your environment. In organizations running dozens of projects with developers under deadline pressure, configuration drift is not an edge case. It is the default condition.

Staged publishing is the stronger of the two controls because it does not depend on developer configuration. It operates at the registry level. A human maintainer has to approve a release through 2FA before it becomes installable. TrapDoor built packages with plausible publishing histories specifically because attacker patience is a known counter to trust signals at the registry layer, but staged publishing meaningfully raises the cost of that approach.

So: one registry-level control with real structural teeth, and one set of developer-configured flags that provide coverage proportional to how consistently they are applied. Both belong in a mature security posture. Neither one is what most teams mean, or should mean, when they say the sourcing layer is governed.

The Gap These Controls Leave Open

BadHost is the clearest illustration of what install source controls and 2FA-gated publishing together do not cover.

BadHost is a high-severity Starlette vulnerability in production at a significant share of AI agent framework deployments. It is in the registry. It passed every check the registry applied when it was published. 2FA-gated publishing does not make it ineligible: it was published legitimately, by its maintainers, before the vulnerability was known. Install source controls do not make it ineligible: it comes from the registry, which install source controls explicitly permit.

Your scanner will find it after it enters your build. Your SBOM will document that it entered. Neither one made the eligibility decision. The npm controls do not make the eligibility decision. The eligibility decision is still unmade.

TrapDoor is a sharper version of the same argument. The 34 malicious packages TrapDoor distributed across npm, PyPI, and Crates.io were registry packages. They had publishing histories. They looked legitimate. 2FA-gated publishing raises the cost of building that cover, but a patient attacker who builds a legitimate presence before introducing a malicious release is exactly the threat model TrapDoor used. Install source controls would not have blocked them: they came from the registry.

These are not edge cases. They are the central case. The attacks that are actually happening exploit the gap between ‘this came from an approved source’ and ‘this package was eligible to enter our environment.’ npm’s new controls narrow the first question. They do not touch the second.

Why AI Makes the Mislabeling Expensive

Before AI coding tools, a developer searching for a package had to find it, evaluate it, and intentionally install it. That was not governance. But it created a moment of human friction between the registry and the build. A developer who paused to read a README was, however informally, making an eligibility judgment.

AI suggestions appear inline. Acceptance is a keystroke. There is no pause. The package moves from suggestion to dependency without any of the friction that previously provided an informal filter.

TrapDoor embedded hidden instructions targeting AI coding assistants directly. Not developers. The tool the developer is using. That is an attacker who understands that the new ingestion model routes around developer-level controls entirely. Install source controls are developer-level controls. They do not govern what the AI suggests from a permitted source.

If your security posture treats npm’s new controls as ingestion governance and stops there, the AI tool’s suggestion set from the registry is ungoverned. That surface is larger than any previous registry-based threat model was designed to cover, and attackers are already building for it.

The Correct Frame and What It Requires

A partial step is not nothing. npm moving toward install source controls and staged publishing is the ecosystem acknowledging that the sourcing question matters. That is worth naming accurately, which is why the interpretation gap is a problem rather than a minor quibble: treating a partial step as complete governance causes security programs to stop before the job is done.

Organizational source governance is the decision, made at the organizational level and enforced upstream of the developer, about what packages are eligible. It operates before the AI suggestion, before the developer decision, before the registry check. It is the allow list that makes your scanner’s job meaningful instead of reactive, because the scanner is now evaluating a governed set rather than whatever entered informally.

npm shipped a developer configuration feature and a stronger registry control. Both have value. Neither is a substitute for the eligibility decision your organization still needs to make.

Your SBOM is a crime scene photo. npm’s install source controls are a better lock on one of the doors. Organizational source governance is deciding who is allowed in the building before anyone tries the doors.

The industry is getting better at the doors. The building is still ungoverned.