If your team builds on Vercel, your builds now refuse to install npm packages on a curated blocklist, automatically, on every plan, with no configuration. That is the factual core of Vercel’s changelog, and it settles one old argument by default: npm supply-chain enforcement on Vercel now lives at the build layer whether you chose it or not. What the changelog does not settle is the harder question underneath it, where should enforcement actually live for your team, given that Vercel’s mechanism is a known-bad version list, not a detector?
Everything specific in this piece about Vercel’s filter comes from that single vendor changelog, and it should be read as vendor-claimed until independently verified. The research numbers on install hooks, false positives, and registry scale come from 2021–2026 academic work, not from any evaluation of Vercel’s implementation. With that scope stated, there is enough here to make the enforcement-point decision well.
What Vercel’s changelog actually claims
The mechanism is narrower than the headline suggests. Per the changelog: “The checks use a blocklist of specific package versions selected for blocking because of malware or security vulnerabilities, with new rules typically reaching new builds within minutes.” Three details matter for planning:
- It is a version blocklist, not detection. Nothing in the changelog describes typosquat heuristics, behavioral analysis, or any scoring of previously unseen packages. A package version gets blocked because someone selected it for blocking.
- It runs in two places. “Before installation, Vercel checks supported lockfiles, including when dependencies are restored from the build cache. During installation, Vercel blocks affected public npm downloads.” The cache-restore check is notable: a blocked version hiding in a warm build cache is supposed to get caught. But “supported lockfiles” is never enumerated, and the install-time action is scoped to “public npm downloads”, private registries, mirrors, and vendored dependencies sit outside the documented claim.
- A hit is a build outage. “If a blocked dependency is detected, Vercel fails the deployment, identifies the package and version in the error, and attempts to invalidate the affected build cache.” There is no warn mode described, and no override or appeal process is mentioned. That silence is not evidence an override does not exist; it is just not documented in this source.
“Typically reaching new builds within minutes” is a typical-case vendor statement, not an SLA, so I would not plan an incident response around it.
Where malicious npm code actually runs
Enforcement layers only matter if they sit upstream of execution. Research maps three trigger points: “Malicious code primarily triggers during package installation, import, and runtime,” according to DistillGuard, a recent detection paper. Each layer of defense can only intercept what happens after it:
- Registry publish gate, catches things before anyone can install them.
- Lockfile check (pre-install), catches known-bad pinned versions before any code runs.
- Download block (during install), catches known-bad packages mid-install, before install scripts execute.
- Post-install / CI audit, finds problems after code has already run on a machine, which makes it a detection-and-response layer, not prevention.
Vercel’s filter occupies the middle two layers. The registry layer, by contrast, is effectively open as of a 2021 survey: “The public registries npm and PyPi use to host packages allow any user with a verified email to publish code. The lack of a comprehensive scanning tool when publishing to the registry creates security concerns,” notes that survey of npm and PyPI threats. That structural gap is why downstream enforcement exists at all, and why every downstream layer inherits the registry’s influx problem. A 2022 study put npm at over 1.7 million packages, with “tens of thousands of updates as well as hundreds of new packages” each day. Any curated blocklist lags that flow by definition. First-seen malware is, almost by construction, not on the list yet.
Install hooks are a strong signal and a narrow net
The reason “before and during installation” matters as a check point is that install-time execution is the most reliable marker of malice in the research. “While 81%81% of the malicious packages found in npm (true positives) make use of installation hooks,” a cross-language detection study reports, “only 8%8% and 2%2% make use of them among the false positives and the packages flagged as benign, respectively.” (The doubled percentages are LaTeX artifacts in the source text.)
Two implications follow. First, blocking a package before its install scripts run genuinely defuses the most common attack shape, which is exactly what Vercel’s changelog claims its checks accomplish (“helping prevent malicious install scripts from running”). Second, the same number implies roughly a fifth of malicious true positives do not use installation hooks, so an enforcement story built entirely around install-time execution misses them. Those packages fire on import or at runtime instead. The concentration holds in the most recent study cited here: DistillGuard finds that install-time attacks account for nearly 88% of the malicious cases in its empirical analysis.
The complementary number comes from a study of npm supply-chain weak links: “We found 2.2% (33,249) of packages use install scripts, indicating that 97.8% of packages may follow npm recommendation of not using the install script as best security practices.” So hook-centric rules are cheap in one sense, they touch a small legitimate minority, and blind in another: they cannot see the 97.8% of the ecosystem where import-time and runtime payloads would live. Both figures date from 2021–2023 research and may not reflect npm’s 2026 scale.
The false-positive bill: who pays when a block is wrong
Here is the second-order consequence that matters most. Moving enforcement from a security team’s post-install audit to every developer’s install step changes who absorbs false positives. In an audit queue, a wrong flag costs an analyst some triage time. At install time, a wrong block is a failed deployment for whoever hits it first, which is precisely Vercel’s documented behavior on any match.
The research gives a sense of what naïve behavior-based detection would cost at that enforcement point. The Cerebro paper, describing a deployed detection system, reports real success, “We detected 683 and 799 new malicious packages in PyPI and NPM, and received 707 thank letters from the official team of PyPI and NPM” (Table 10), but also states a false positive rate of 81.5% for PyPI and 64.2% for NPM. (The figure is quoted from the paper; how it defines “false positive rate” is worth checking against the full text before treating it as a classic FPR.) Even read generously, that is an error profile acceptable for a triage queue and unacceptable for a hard install-time block. Research frontier self-reports are better, DistillGuard claims 95.3% accuracy and 99.4% precision in its own experiments, but those are lab numbers, not deployed-product evaluations, and even a one-percent wrong-block rate would be a steady drip of broken builds if wired to fail deployments.
Read against that backdrop, Vercel’s conservative design choice makes sense. A curated version blocklist trades coverage for precision: it will miss first-seen malware, but its false-positive exposure should be limited to curation errors rather than classifier error rates. That is a reasonable trade for an automatic, default-on control. It is also why the changelog’s silence on an override path deserves attention, if a block is ever wrong, “fails the deployment” is the only documented outcome.
Coverage gaps worth writing down
Two failure modes in the research deserve explicit mention because they map onto real infrastructure. Donapi describes “a local npm package cache of over 3.4 million packages, capable of synchronizing official replicate in near real-time and retaining deleted malicious packages,” and reports finding 325 new malicious packages through manual checks. The lesson cuts both ways: mirrors and caches preserve evidence for forensics, but they also preserve deleted malware. If your builds pull from an internal mirror or a vendored copy rather than the public registry, Vercel’s install-time block, documented as covering “public npm downloads”, is not obviously in the path. The pre-install lockfile check may still catch the pinned version, but only for “supported lockfiles,” a set the changelog never defines. Teams running private registries or artifact mirrors should treat coverage there as an open question and verify it directly, not assume it.
Choosing your enforcement point
| Layer | What it plausibly catches | Where it fails | Who pays for a false positive |
|---|---|---|---|
| Registry publish gate | Everything, in principle | Documented as absent as of the 2021 survey: no comprehensive scan at publish time (survey) | Registry operator |
| Build-time lockfile check (Vercel, vendor-claimed) | Known-bad pinned versions, including cache restores | First-seen malware; undefined “supported lockfiles” | Whoever’s build fails first |
| Install-time download block (Vercel, vendor-claimed) | Known-bad versions mid-install, before install scripts run | Scoped to public npm downloads; mirrors, private registries, vendored deps undocumented | Whoever’s build fails first |
| Post-install / CI audit | Detected malware after the fact; triage-friendly | Code has already executed on the machine; CI tooling specifics are outside this article’s evidence | Security team’s triage queue |
One honest limitation on this table: no source cited here evaluates CI-audit tooling such as npm audit or Dependabot as a deployed enforcement layer, so that column stays generic. DistillGuard does benchmark SocketAI, but only as a detection method on a labeled dataset, not as a deployed CI gate, so it does not fill that gap either. Do not read any comparative effectiveness claim into it.
My recommendation
Keep Vercel’s blocklist check on. It is zero-config, it addresses the highest-signal execution point in the research, and its conservative known-bad mechanism is the right shape for a control whose documented failure mode is a hard deployment failure. But treat it as a backstop with a lag, not as detection. New rules arrive “within minutes” in the typical case, while hundreds of new packages hit npm daily, the window between publication and blocklist entry is where first-seen malware lives, and closing it requires a separate detection or audit layer where a human, not a build, absorbs the false positives.
Two verification steps follow from the evidence gaps rather than from any assurance the setup is safe. If your dependency path involves a private registry, mirror, or vendored packages, test whether the filter actually sees your installs, because the documented claim stops at public npm downloads. And before you need it, find out whether an override or appeal path exists for a wrong block; the changelog does not say, and discovering the answer during a production outage is the expensive way to learn it.
Frequently Asked Questions
What happens to a deployment if Vercel detects a blocked npm package?
If a blocked dependency is detected, Vercel fails the deployment, identifies the package and version in the error, and attempts to invalidate the affected build cache.
Join the discussion
Share a useful perspective or ask a question about this article.