NPM Users Download 2.1B Deprecated Packages Weekly, Say Security Researchers

The cybersecurity site SC Media reports that NPM registry users "download deprecated packages an estimated 2.1 billion times weekly, according to a statistical analysis of the top 50,000 most-downloaded packages in the registry." Deprecated, archived and "orphaned" NPM packages can contain unpatched and/or unreported vulnerabilities that pose a risk to the projects that depend on them, warned the researchers from Aqua Security's Team Nautilus, who published their findings in a blog post on Sunday... In conjunction with their research, Aqua Nautilus has released an open-source tool that can help developers identify deprecated dependencies in their projects.

Open-source software may stop receiving updates for a variety of reasons, and it is up to developers/maintainers to communicate this maintenance status to users. As the researchers pointed out, not all developers are transparent about potential risks to users who download or depend on their outdated NPM packages. Aqua Nautilus researchers kicked off their analysis after finding that one open-source software maintainer responded to a report about a vulnerability Nautilus discovered by archiving the vulnerable repository the same day. By archiving the repository without fixing the security flaw or assigning it a CVE, the owner leaves developers of dependent projects in the dark about the risks, the researchers said...

Taking into consideration both deprecated packages and active packages that have a direct dependency on deprecated projects, the researchers found about 4,100 (8.2%) of the top 50,000 most-downloaded NPM packages fell under the category of "official" deprecation. However, adding archived repositories to the definition of "deprecated" increased the number of packages affected by deprecation and deprecated dependencies to 6,400 (12.8%)... Including packages with linked repositories that are shown as unavailable (404 error) on GitHub increases the deprecation rate to 15% (7,500 packages), according to the Nautilus analysis. Encompassing packages without any linked repository brings the final number of deprecated packages to 10,600, or 21.2% of the top 50,000. Team Nautilus estimated that under this broader understanding of package deprecation, about 2.1 billion downloads of deprecated packages are made on the NPM registry weekly.

Re:

[Anonymous Coward]

> archiving the vulnerable repository the same day "Hey, a repo you haven't touched in forever and have no time or interest in working on has a problem."

"Blah, that reminds me I should archive the repo so everyone knows its a dead end project".

I don't understand why places like GitHub don't have some sort of automated system to flag a repo as "No one with a commit bit has touched this repository or looked at any of the issues in 6 months. Hell, they haven't even signed into GitHub for a year..."

...and there really should be a system where package repos like NPM, PyPi, etc...can do the same...or look at the upstream repo (i.e. GitHub) and see that it's flagged and warn users.

Then the installers like npm, pip, poetry, etc...should have a speci

Re: Pushes owners to actually mark abandoned proje

[guruevi]

There are two competing issues with NPM packages. First of all, yes, you do get a warning if your packages are outdated, but because JavaScript is a poor language and relying on online dependencies a dumb idea, a stupid package like leftpad being delisted broke all of NPM.

So they made it so packages could no longer be delisted if anything depends on it, however, again, NPM being poorly thought out, you can list * and have every version as a dependency regardless if it breaks future builds. Now all that is m

Re:

[ArmoredDragon]

JS was never intended to do any of the shit people use it for. Reminds me of my friend who once wanted to build MacOS server. Who the fuck thought it was a good idea to keep a language like JS around forever, let alone build an entire general purpose platform like Node based on it to extend its life even further, and then build a package manager to extend it yet further more? Extending a shitty language still leaves you with a shitty language, sometimes an even shittier one. Multiple additions to C++ taught

Re:

[fullgandoo]

As a long-time C/C++ programmer, I find JS a refreshing change. I find even TypeScript an unnecessary affliction. The brevity and ability to do whatever you want however you want is completely liberating.

Doesn't matter what it was intended to do, it's here to stay. I've been involved in some major projects where without the use of Node there would have been no end in sight. Sure it allows you to write shitty code, but which language doesn't?

Re:

[johnnys]

Every language allows a developer to write bad code, agreed.

BUT the spread of these crappy code repositories enable a whole new development ecosystem that consists of low-competence "developers" building business apps by clumsily slapping together modules from some cesspool repo. It's cheap and fast, which businesses love. The low-competence "developers" aren't real developers: They can do little more than slap barely-understood code blocks together. But they can do it quickly and they don't cost much becau

Re:

[fullgandoo]

What you've said is correct.

But there are also tons of excellent modules in the NPM repo on just about anything you can think of. It doesn't take that much effort to evaluate a module. Look at the number of downloads, examine the code, look at its github home page, etc.

I don't want to reinvent the wheel if at all possible. Life is short.

Re: Pushes owners to actually mark abandoned proj

[ArmoredDragon]

But did you use the right number of equal signs?

Re:

[dbialac]

A package can reach a point of maturity where there isn't anything new and it works properly. You accomplish this by not always adding something new. You don't have to change just for the sake of change, that's how we end up with bloatware.

Re:

[ArmoredDragon]

If somebody marks their own package as deprecated, there's probably a good reason for it.

4 paragraph summary...

[hazem]

and it's never mentioned what NPM is, other than a "repository of packages".

Re:4 paragraph summary...

[Retired Chemist]

National Association of Pastoral Musicians npm.org

Re:

[drinkypoo]

npm is "a JavaScript package manager"

If you are doing a website with javascript stuff then npm is often the official way to get the libraries for stuff like slideshows, color pickers, chart generators, etc.

I use it through composer to install dependencies for Drupal modules.

Re:

[hazem]

Thanks for that explanation!

So when you use npm as part of your website build, does it only read npm when you deploy (you get local copies)? Or does it get accessed/read as users interact with your website?

Re: 4 paragraph summary...

[hey00]

It's like maven, if you know it.

In your project, you have a file that describes the dependencies you need, and when you execute npm install, it fetches all of them (including the dependencies of your dependencies) and stores them in a node_modules directory.

When you build your website, the bundler tries to be intelligent and only include in the final build the parts of the packages you actually used, and not the whole 1.5 GB or more of node_modules (not all of them are needed to be bundled, for example, sas

Re:

[fullgandoo]

Yes it is a JavaScript package manager. But npm stands for "Node Package Manager".

Packages on npm are meant to be executed by Node and can't be directly executed on the browser like jquery.

That's no wonder

[Opportunist]

node.js has the worst collection of packages of pretty much any language that has some kind of packet repository.

Now, it's hardly a novelty that there is for every language out there some package, some library, some repo for every fart you might want to pass using that language. node.js is the only one I know, though, where there are not only 10+ for every single application, but there also is no "gold standard" with the other 9+ being merely the toy project of someone who insists that his way is the only right one.

Even for petty crap like Arduino, where the packages are hardly official for most sensors or motors you may want to read or control, or where the official ones are also the crappy one that have been improved and superseded by user packages, usually one such package stands out as "the one", where there are 90% of the downloads and implementations using that package instead of the other ones.

Not so with node.js.

With node.js, not only is that urge to reinvent the wheel pretty strong in the userbase, they also insist in smearing their crap into the npm repo. And someone else then downloads and uses it. Unfortunately, pretty much all packages have about the same usage statistics.

And also unfortunately, they only get maintained for as long as the person originally throwing their garbage into the repo feels like maintaining it. Because it seems to be anathema to maintain the code of someone else, to fork an existing project that suffers from bit rot and take it to the next level. And frankly, looking at the code, who can fault them? Because everyone else of course clearly does it WRONG.

So it's no wonder the npm repo is in the shabby state it's in.

ban node.js and npm

[backslashdot]

Can't we get a law passed banning all usage of node.js and npm? Just fucking ban it on the federal level. And yes I am serious. Modify the constitution, pack the courts etc.

If your UI doesn't import 1000 libs, you suck...

[Somervillain]

Can't we get a law passed banning all usage of node.js and npm? Just fucking ban it on the federal level. And yes I am serious. Modify the constitution, pack the courts etc.

Great idea...one problem...NPM is used for UIs even more than node.js backends. Yes, node.js is the bane of my existence...or more accurately, I have spent the last 10 years, watching inexperienced devs write stuff in node.js...I warn against it....they do it anyway because what could an experienced professional possibly teach you?...yup...innovation trumps knowledge, experience, quality, common-sense, and general reading and understanding of systems.

So some manager who is too dumb to make technical dec

Re:

[Junta]

So my group had an application stack that was more liekly to be used via users writing against our API or using the command line client, but we also had a WebUI with a few uniquely useful features that the users liked.

The larger organization decided to declare some standards about how work like ours should be done, without having us invited to the table.

So the end result was that one of the standards was that "Backend code allowed to service requests from a WebUI must be implemented in Node, other languages

Context...

[stikves]

Context is important. Yes people download old packages, this happens all the time.

You can for example still download Debian Jesse packages for an older system where new kernels are not available for one reason or another:

deb [trusted=yes] http://archive.kernel.org/debi... [kernel.org] jessie main contrib non-free

Do you want to keep this server running? Yes
Do you plan to migrate to a new release? As soon as possible
Do you open this one to the Internet? Of course not

And the last one is the most crucial part.

And unfortunat

Re:

[xlsior]

How many of these downloads are due to dependencies of transient / incremental upgrades?
Just because someone downloaded something doesn't mean that's what they will stick with.

Start with an older base image, apply updates, apply updates, apply updates, apply updates -- no more updates, done.

Re:

[drinkypoo]

unfortunately NPM (JavaScript) packages are even more fragile against upgrades. Yes, I want latest and most secure version. But at the same time, I might have preferred my internal application to continue running without spending weeks (or more!) porting to the new fancy release of the library

I don't know how this works when using naked npm, but with composer I add some lines to my composer.json to support npm assets, and then when I install a package it naturally gets pinned to a major version like everything else I install using composer. Then it doesn't get updated to a new major version when I do a composer update unless something else I've installed requires it. Let's see if I can get even two lines from my composer.json posted to this site where we all used to post code snippets...

npn shot themselves in the foot

[Anonymous Coward]

They caved in to a DMCA, trademark dispute or some such, the maintainer of the library went nuclear and deleted the library breaking many dependencies and the PTB at npm decided to implement a no delete policy.

Then there is the everything package that depends on everything.

Reap what you sow.

updating/upgrading often not in the budget

[CoderFool]

What you will often hear from management is: "if it ain't broke, don't update it"
This depends on how much is changed in the new version, and whether there is major work to accommodate the new version or not.
It also depends on if the formerly free version isn't free anymore.
Like EPPlus. Where I work we use the last free version of EPPlus all over the place, and there is no budget for a newer, licensed version, not to mention how much effort it might take to update our code to the new version. And that w

What is it really like?

[johnnys]

1. BSD = Cathedral
2. Linux = Bazaar
3. NPM = Septic Tank