70% of new NPM packages in last 6 months were spam
blog.phylum.io
70% of new NPM packages in last 6 months were spam
1–10 of 116 posts
Re: 70% of new NPM packages in last 6 months were spam
#2> Contrary to what npm states, this package actually depends on one of our aforementioned spam packages. This is a by-product of how npm handles and displays dependencies to users on its website.
For me personally, this is the biggest surprise and takeaway here. By simply having a key inside package.json's dependencies reference an existing NPM package, the NPM website links it up and counts it as a dependency, regardless of the actual value that the package references (which can be a URL to an entirely different package!). I think this puts an additional strain on an already fragile dependency ecosystem, and is quite avoidable with some checks and a little bit of UI work on NPM's side.
Re: 70% of new NPM packages in last 6 months were spam
#3TLDR:
1. a cryptocurrency scheme for funding OSS development[1] is incentivizing spammers to try and monetize NPM spam
2. it's easy to spoof your dependencies with package.json[2]
"dependencies": {
"axios": "https://registry.npmjs.org/@putrifransiska/kwonthol36/-/kwonthol36-1.1.4.tgz"
}
Re: 70% of new NPM packages in last 6 months were spam
#4Spam is the least of the worries.
Re: 70% of new NPM packages in last 6 months were spam
#5I wonder what is the long term plan.
Maybe the next step is to sell the control of all these packages to a rogue entity to be used for a supply chain attack?
Re: 70% of new NPM packages in last 6 months were spam
#6TLDR: 1. a cryptocurrency scheme for funding OSS development[1] is incentivizing spammers to try and monetize NPM spam 2. it's easy to spoof your dependencies with package.json[2] "dependencies": { "axios": "https://registry.npmjs.org/@putrifransiska/kwonthol36/-/kwonthol36-1.1.4.tgz" } [1]: https://tea.xyz/blog/the-tea-protocol-tokenomics [2]: https://www.npmjs.com/package/sournoise?activeTab=code
A "better" way is to modify the package-lock.json. You can still spoof the package but almost no one actually reviews it as npm will usually modify 1000s of lines.
for example take mongoose
"resolved": "https://registry.npmjs.org/mongoose/-/mongoose-8.4.4.tgz",
"integrity": "sha512-Nya808odIJoHP4JuJKbWA2eIaerXieu59kE8pQlvJpUBoSKWUyhLji0g1WMVaYXWmzPYXP2Jd6XdR4KJE8RELw==",
Re: 70% of new NPM packages in last 6 months were spam
#7The Tea protocol's flawed incentive model is a disaster, effectively encouraging developers to pollute npm with spam. It's a prime example of what happens when protocols prioritize quantity over quality, compromising the entire ecosystem.
Re: 70% of new NPM packages in last 6 months were spam
#8How about removing the incentive? Take down every package with tea.yaml in it, after say 1 month's warning, so legitimate packages trying to use it don't leave their users in the lurch. The tea protocol is clearly not going to accomplish what it set out to (see below), and is instead incentivising malicious behaviour and damaging the system it set out to support.
From https://docs.tea.xyz/tea/i-want-to.../faqs: "tea is a decentralized protocol secured by reputation and incentives. tea enhances the sustainability and integrity of the software supply chain by allowing open-source developers to capture the value they create in a trustless manner."
Re: 70% of new NPM packages in last 6 months were spam
#9Spam is the least of the worries.
Yeah this when I see one of our pipelines pull in 300 npm packages I wonder how much we really know about what our systems do.
Re: 70% of new NPM packages in last 6 months were spam
#10I wonder what is the long term plan. Maybe the next step is to sell the control of all these packages to a rogue entity to be used for a supply chain attack?
Would you be at all surprised? I'm fairly confident that like with browser addons, NPM package maintainers get offers from randoms to 'buy' their package in order to get backdoor access.
A secured registry is long overdue, where every release gets an audit report verifying the code and authorship of a new release. It won't be nearly as fast as regular NPM package development but that's a good thing, this is intended for LTS versions for use in long-term software. It'd be a path to monetization as well, as the entities using a service like this is enterprise softare and both the author(s) of the package as the party doing the audit report would get a share.