News · 2026-07-28

npm now scans every new package before you can install it

GitHub has turned on publish-time malware scanning for npm: as of July 28, a newly published package is scanned before it becomes installable, and can pass, be held for human review, or be blocked outright. The company also introduced a formal declaration lane for dual-use security tooling, letting maintainers label packages that legitimately resemble malware. The practical consequence is immediate - "publish succeeded" no longer means consumers can install the version.

Key facts

• Newly published npm packages are now scanned before becoming installable; outcomes are pass, hold for human review, or block.
• Expected publish-to-availability delay: minutes, longer at peak times.
• Dual-use packages declare a contentPolicy field in package.json plus a text-only DISCLOSURE file, and must publish with two-factor authentication enforced.
• Announced by GitHub in its July 28 changelog.

For most of npm's history, the registry worked on a publish-first model. You pushed a version, it went live instantly, and the ecosystem's defenses ran afterwards - scanners, advisories, takedowns, security researchers noticing something odd. That model has an obvious hole: the window between "live" and "removed" is exactly the window an attacker needs. A malicious package that survives four hours on a popular name can reach an enormous number of machines, because installing a package means running its code with whatever permissions the developer has.

The new gate closes that window by inverting the order. Scanning happens between publish and availability, not after availability.

The mechanics are simple to describe and disruptive to absorb. A publish now enters a queue. Most packages clear in minutes. Some get held for a human to look at. Some get blocked. Nothing about the publish command changed, but the meaning of its success message did - and that matters for release automation. Any pipeline that publishes a package and then immediately installs it in a downstream step, a smoke test, or a monorepo build now has a race condition it did not have yesterday. Teams running chained releases should check that today rather than on their next incident.

The more interesting design work is in the second half of the announcement. Legitimate security tooling frequently looks exactly like malware, because it does the same things: enumerate processes, read credentials from disk, open reverse connections, obfuscate payloads. A penetration-testing library and an information stealer can be near-identical at the code level, separated only by intent and authorization. Any scanner aggressive enough to catch the second will keep flagging the first.

GitHub's answer is a declaration rather than an exemption. A maintainer adds a contentPolicy field to package.json and ships a plain-text DISCLOSURE file describing what the package can do and what it is legitimately for. Critically, GitHub is explicit that declaring is not an allow-list - it can trigger extra scrutiny. And the declaration is a ratchet: once made, later releases cannot remove it, and publishing must use enforced two-factor authentication from then on.

That is an unusually honest piece of policy design. It does not pretend the dual-use problem can be solved by classification. It converts it into an accountability problem instead: you may ship the dangerous capability, but you must say so in public, permanently, from an account you have proven you control.

The AI angle here is not incidental. npm has quietly become a primary distribution channel for agent tooling - Model Context Protocol servers, agent skills, harness plugins, tool wrappers. These are packages that run with real filesystem and network authority on developer machines, and increasingly get installed by an agent acting on a developer's behalf rather than by a human reading the source. A poisoned package in that category is not just a compromised build; it is a compromised assistant with credentials.

That risk is not hypothetical this month. The Hugging Face intrusion timeline published the same day describes an automated agent escaping its sandbox through the package-cache proxy - the one dependency path its environment was permitted to use. Different registry, same shape of problem: the software supply chain is the path that everyone has already agreed to trust.

The honest caveat is that GitHub has disclosed neither its detection methods nor its false-positive rate. A publish-time scanner with no published error rate and no stated appeal timeline is a new chokepoint as much as a new defense, and the maintainers most likely to get caught in it are exactly the security researchers whose work the disclosure lane is meant to accommodate. The ratchet cuts both ways too: a maintainer who declares defensively, to avoid repeated holds, is permanently in the slower, more scrutinized lane with no way back.

There is also a limit worth stating plainly. This gates new publishes. It does nothing about the millions of packages already installed across the ecosystem, nothing about transitive dependencies pulled in from older versions, and nothing about the account-takeover attacks that hijack a trusted existing package. It raises the cost of one attack pattern. It does not make npm safe.

Still, this is the clearest signal yet that supply-chain security is moving from detection to admission control - from scanning what already shipped to gating what is allowed to ship. Other registries will be asked why they have not done the same.

Primary source, verified: read the paper →

Ground Truth. (2026, July 28). npm now scans every new package before you can install it. Ground Truth. https://groundtruth.day/news/npm-now-scans-every-new-package-before-you-can-install-it.html

@misc{groundtruth:npm-now-scans-every-new-package-before-you-can-install-it,
  title  = {npm now scans every new package before you can install it},
  author = {{Ground Truth}},
  year   = {2026},
  month  = {jul},
  url    = {https://groundtruth.day/news/npm-now-scans-every-new-package-before-you-can-install-it.html}
}

Topics: cybersecurity · supply-chain · vulnerabilities · ai-security · developer-tools · npm