pnpm
Proposal: on-device malware detection open IOC feed #12624
Replies: 2 comments 11 replies
|
While I don't reject this idea, this claim is not valid:
Historical data shows that all the malware was detected and removed from the registry in hours or even minutes. You are wrong saying "cooldowns hope the other users get attacked first". No, this is not about hope that other users get attacked first. Scanning IS happening. Socket.dev and multiple other companies are doing the scanning. Recent poisoned packages were detected in 15 minutes and removed from the npm registry soon after. Hence, delayed updates do solve the problem currently. If you want additional protection, you can use additionally something like the socket firewall. Regarding patching vulnerable packages, nothing prevents you from doing that. You just need to explicitly run "pnpm update pkg@<patched version>". About scanning done by pnpm, I don't feel comfortable doing it. If we add such feature to pnpm and it will fail to detect malware, it will be a huge reputational hit for us. I am not taking that risk with a free open source product. As I mentioned earlier, there are companies that focus on this, and if they provide a service for scanning packages, we can use them. If you want to add an opt-in plugin to pnpm that scans, that could probably be done via hooks: https://pnpm.io/pnpmfile This is my personal opinion. You shouldn't close the issue. Others can have a different opinion. |
|
While I do agree that malware scanning is a good idea, I feel that any kind of malware scanning can only be implement in the server-side registry, i.e. npm registry that takes in a newly published package, holds it off from distribution until its confirmed malware-free. It is meaningless to do a client-side package manager scanning because if I'm a malware author, I would not use that client and publish it directly using other methods (e.g. direct curl PUT request to registry)? |
|
On the client-side package manager scanning point, I do not think "it is meaningless to do client-side package manager scanning" is accurate. That argument is valid for publish-time scanning. If the scanner only runs in the publishing client, a malicious author can bypass it by using another client or by calling the registry API directly. In that case, registry-side scanning is clearly the right place to enforce the policy. But install-time checking is a different problem. A package manager can still protect the consumer by checking the package version, tarball integrity, or known IOC/advisory data before installing it. An attacker can bypass a publishing client, but they cannot bypass the consumer local install policy. I agree that the ideal first line of defense should be on the registry side. If npm scanned packages before they entered distribution, and blocked them until scanning completed, users would not need to rely primarily on a cooldown window like At the same time, So I think the better direction is not for pnpm to claim that it can detect all malware itself, but to provide a lightweight, optional, configurable policy layer: support signed and verifiable IOC/advisory feeds, allow third-party or organization-managed sources, and block known-bad packages or artifacts during install with minimal performance impact. |
|
@spencer17x I was writing all almost identical response so will simply agree almost verbatim to everything you say except the client-side detection should be entirely opt-in with this logic, blocking security patches for known exploits with a default minimumReleaseAge 1440 and therefore opt out to get your patches should never have been implemented I agree that in a perfect situation that opt in is best, but similar to minimumReleaseAge requiring a default 1440 is compensating for registry publishing unscanned detectable malware, then the detectable or known bad IOC checking is a required default unless registry changes their approach Again, well said on all points, including the policy opt in, but only on a perfect world would that work, we are not in a perfect world I would suggest a temporary default enabled, which can be opt-out and preferably adopt user allow list overrides, and a requirement to review the setting on major release to be reverted to default disable if the registry implements scanning before publication |
|
What about running osv-scanner from a pnpm hook? This is not instant detection, so |
Scanning pnpm-lock.yaml against osv.dev's MAL records answers a specific question well: is this installed dependency already on a known-bad list, by name. For that job a name is enough. Around a third of MAL records are pulled from the registry entirely by the time they publish. For that third there is no artifact left to match against, the record exists but the package does not, so it can never fire at install, but This idea for MAL/OSV data is meaningful and might be a separate issue to open and discuss on it's own merits. Consider the topic carefully though. I have thoughts on numbering databases, having published net new vulnerability and malware numbers, as a numbering authority. You need to understand a reality about numbering systems in security (built for people in the year 1999, not 2026). A vulnerability number is the last step, assigned after the incident is understood, so that everyone can point at the same thing in hindsight and discuss it. A historian takes other people's accounts and assembles them into the semi-fictional narrative we call a history book. OSV and MAL records are the equivalent for security. Furthermore, Malware is not like all other vulnerabilities, so a numbering system like CVE already excludes them, GHSA/OSV barely help improve the situation either. What helps is what my company and OpenSourceMalware (a commercial product I am not endorsing here) deal with real SOC teams that have real world malware incidents that occur after package registries and package managers shipped malware to developer laptops and CI/CD shared infrastructure to infect even apps that build on that same infra using entirely separate ecosystems. i.e. an npm malware installs then a Go or C++ app builds on the same shared CI runner and is infect too. This is the real world. What helps? When Malware is concerned, package ecosystems would benefit from scanning for IOCs proactively, which could eventually end up in a database like OSV much later after it is discovered (bonus) just like these MAL records, and maybe, just maybe, NPM registry wake up to this and pull the malware package managers detect and decide to be proactively scanning too. Circling back. While the MAL/OSV data is not on topic here, I do suggest it is opened as a discussion to change the way the resolution strategy of pnpm can be improved - it's not a meaningless idea, just not one that I see being relevant for the topic of conversation (proactive scanning) here. |
|
microsoft GitHub are doing the scanning of Microsoft NPM before publish now https://github.blog/changelog/2026-07-28-npm-publish-time-malware-scanning-and-dual-use-metadata/ What a novel idea! |
|
so you closed the discussion? not needed anymore? pnpm still can install packages from other sources, not just the public npm registry. |
like the dog who caught the car.. I'm not invested in the chase any more |
Uh oh!
There was an error while loading. Please reload this page.
Background
I see pull/11158 as a temporary bandaide.
As long as there is any publish first (controlled by registry) then install delay, there is a delay getting legit updates like patches for exploited vulns to users.
To be blunt, the malware is only prevented from installing if it is detected, until the cooldown expires, and the cooldown does not trigger anyone to scan for you - and the NPM registry discussions are leaning towards a 7 day cooldown default without scanning before publishing.
We see the PHP registry (packagist) doing scanning, and they're holding initial package publishing until scanning is complete, so there is no need for a user imposed cooldown which stops good patches that fix exploitable vulns. It's not clear why NPM discussion is preferring to not scan despite the clear benefits and success seen with PHP ecosystem - perhaps NPM have a plan they are not ready to go public with and the non-consentual blocking of users security patches is the price of negligence they are willing to take on for that plan? Who o=would know?
Proposal
We can offer pnpm users on-device malware detection compensating for the lack of NPM registry scanning adoption plans, using an open IOC feed, otherwise the
minimumReleaseAgeis meaningless. AllminimumReleaseAgeoffers when there is no scanning is a bleak expectation someone else (other package manager users) will be infected and implies a hope they report it before pnpm users are infected too.The problem is, if he npm package manager, yarn, bun, all move to 7 days - then pnpm defaulting to 1 day means pnpm users are the users expected to be infected first and the rest of them have 6 more days for US to report that to the registry and save them from infection.
It is a race to the bottom, and only the package manager with the longest cooldown wins - but ALL users lose because the longer the minimumReleaseAge / cooldown the longer they are being blocked from real security patches that stop exploits.
Data proves Exploits are a imminent threat
Why am I referring to exploits when the topic is mlware? Because the only defence from exploits comes in the form of a patch, which the NPM registry and package managers are preventing users applying with minimumReleaseAge / cooldowns.
But how bad are thee exploits? They;re mainly targetted at comercial entities and governments (my day job).
%%{init: {'theme':'base','themeVariables':{ 'doneTaskBkgColor':'#FFC107','doneTaskBorderColor':'#8a6d00', 'taskBkgColor':'#FB8C00','taskBorderColor':'#8a4b00', 'critBkgColor':'#d7514e','critBorderColor':'#8a1c1a', 'activeTaskBkgColor':'#2E7D32','activeTaskBorderColor':'#14401a', 'textColor':'#9e9e9e','gridColor':'#9e9e9e', 'sectionBkgColor':'transparent','altSectionBkgColor':'transparent', 'taskTextColor':'#1a1a1a','taskTextDarkColor':'#1a1a1a', 'taskTextOutsideColor':'#9e9e9e','taskTextLightColor':'#ffffff' }}}%% gantt dateFormat YYYY-MM-DD axisFormat %b %d section Can you install the fix Before publish, no fix released yet, is being exploited :done, a, 2026-01-27, 5d Day 0 to 1, pnpm cooldown holds patch from users being exploited : b, 2026-02-01, 1d Day 1 to 7, only pnpm users can be infected by malware, but they get the exploits patched :crit, c, 2026-02-02, 6d Day 7 onward, all package managers allow exploit patching but undetected malware too :active, d, 2026-02-08, 5dBasically, without scanning, cooldowns hope the other users get attacked first. it's that simple. and cooldowns put you at worse risk from exploits - the data is in, we can't ignore it.
If there is interest in getting malware IOCs into a bloom filter, and pnpm mechanism for keeping that in sync with an endpoint. I'll donate time and IOC feed until we can point at OSM or just stay on this, whatever is best for the community.
I have no PR prepared, I am hoping for some support to kick this off.
All reactions