Better, but not enough
The scanning headline will get the coverage. The second half of the announcement says more, and the mechanics are worth understanding.
Some legitimate packages, like security testing tools and network utilities, look exactly like malware to a scanner, and for good reason: they probe systems, harvest credentials, and move data across networks, because that is literally their job. Take Mimikatz. Security teams have used it for over a decade to test Windows credential defenses by pulling passwords from memory. Attackers use it to do the same thing, which is why it has its own page in the MITRE ATT&CK catalog and has tripped antivirus engines for years. A scanner sees the behavior, not the purpose. GitHub calls this dual-use content, and its answer isn't a smarter model. It's governance:
- Declared in metadata. Maintainers add a contentPolicy field to package.json, plus a plain-text DISCLOSURE file in the package root describing the dual-use functionality and its legitimate purpose. npm's policy covers things like penetration-testing tools, security research utilities, and code-obfuscation tools, and its Trust & Safety team reviews declarations with no guarantee of publication.
- 2FA-enforced publishing only. Dual-use packages must be published through a method that enforces two-factor authentication: trusted publishing (OIDC), an interactive 2FA session, or staged publishing. Publishing directly with a token that bypasses 2FA is not permitted.
- A one-way door. Once a package declares dual-use status, new versions can't remove the field or the file. Versions that drop them are rejected.
GitHub built a scanner, then built identity controls, human review, and permanent declarations for everything the scanner can't judge. And it states the limit on the other side just as plainly: "npm blocks the malware we can detect."
Both are admissions of the same fact: code doesn't carry intent, and scanners can't infer it. GitHub's own definition of dual-use concedes the point: legitimate packages whose security-relevant capabilities resemble malware under automated scanning. A credential-harvesting tool and a credential-harvesting attack look the same on disk. What separates them is policy: who can run what, where, under whose rules. A public registry cannot set that policy for you.
Why this is happening now
LLMs have cut the time to build a working exploit from months to hours, for under $5. Campaigns like Shai-Hulud, NX S1ngularity, and Cline poisoned the packages that AI coding agents pull automatically.
That last point is the multiplier. GitHub asks human publishers to tolerate a five-minute delay. Meanwhile, AI agents install dependencies at machine speed, with no human reading the dependency tree. Package consumption is growing faster than any review process, GitHub's or yours.
Publish time is the ecosystem's control. Install time is yours.
So is the problem now solved upstream? No, and GitHub isn't claiming it is.
Registry scanning raises the floor for everyone, and GitHub deserves credit for shipping it. But it enforces GitHub's policy for the average npm user. It cannot do three things you are accountable for:
- It can't enforce your policy. GitHub decides what counts as malware on npm. It doesn't know your license rules, your vulnerability thresholds, or how long a brand-new package should wait before it's allowed near your builds.
- It can't cover your surface. npm's gate covers npm. Your teams also pull from PyPI, Maven, NuGet, and beyond. A perimeter with one guarded gate isn't a perimeter.
- It can't judge your context. A dual-use package may be fine for your red team and unacceptable in a production pipeline: same package, different answer. Only your policy knows the difference. That is exactly why GitHub needed a disclosure-and-review process instead of an automated verdict.
And the uncomfortable fourth: detection blocks what's detectable. Novel malware and compromised maintainer accounts will sometimes pass a five-minute scan. GitHub says as much. When that happens, the only question that matters is whether the package reaches your environment. That isn't decided at the registry. It's decided at your install boundary, the one control in this story you own.
What good looks like
The right response is layered enforcement: not just a check at the registry-level but also at installation.
That's what Package Firewall does. It sits between your developers, your AI agents, and every registry they pull from: npm, PyPI, Maven, NuGet, and more. Malicious, vulnerable, and policy-violating packages are blocked at install time, before they reach a workstation or pipeline. Cooldown policies keep brand-new, unvetted packages out of your builds by default. One policy covers humans and agents alike.
For you, that translates into three things no registry can provide: a control you own, a policy that reflects your risk appetite, and evidence. Every allow-or-block decision is logged, so when the next Shai-Hulud hits the news, you answer "did it touch us?" from a record, not a scramble. Your board, your auditors, and your customers will ask you for that answer, not the registry.
The bottom line
GitHub just told the world that packages can't be trusted at publish time. Believe them, and finish the thought. The registry's scanner enforces the registry's policy. Yours has to be enforced where code actually enters your environment.
The fastest way to settle the question is with your own data: run Package Firewall against your real dependency traffic and read the block log. Book a demo or get started with Package Firewall today.
What's next?
When you're ready to take the next step in securing your software supply chain, here are 3 ways Endor Labs can help: