Social engineering campaign targeting tech employees spreads through NPM malware | Hacker News Reader

Social engineering campaign targeting tech employees spreads through NPM malware

socket.dev

114 pointsfeross87 comments

I'm co-founder of Phylum (https://phylum.io), the group that originally identified/reported this campaign back in June [1] and that Github references [2] in their security alert. Happy to answer any questions about this campaign and any other supply chain attacks.

1. https://blog.phylum.io/sophisticated-ongoing-attack-discover...

2. https://github.blog/2023-07-18-security-alert-social-enginee...

Good work on finding this. This is a scary attack.

Thanks, we report _many_ of these every day to all the ecosystems. It's wild how many malware packages get released. Doing our best to help clean up these ecosystems for everyone!

I guess a couple questions, if you don't mind:

1. Can you say how you find things like this? Just bulk scanning packages doing pattern matching heuristics?

2. I know it gets talked about every time, but I'd be interested in your perspective on how we (as an industry) could stop this kind of thing from happening. Is it as easy as blocking hooks from executing, or is there a better way forward? EDIT: Oh, just now seeing https://news.ycombinator.com/item?id=36869587 - so I'm assuming your answer is better sandboxing:)

I’ll be the first to say it: it looks like breaking everything down into a dependency graph of a million tiny packages that nobody understands and letting anyone publish anything they like might have been a bad idea.

At least npm has namespaces (scopes) to group packages by trustable entity. I wish cargo had namespaces. It's a big miss for an otherwise security conscientious project imo.

More important than the namespace is who published the package. I'm more inclined to trust an individual I know who takes security than a namespace that may change hands.

NPM exposes that info in the _npmUser field: https://github.com/npm/registry/blob/master/docs/REGISTRY-AP.... That gives "name" (NPM username) and email.

While there are thousands of packages, I bet there's a much smaller number of publishers to worry about.

Like this guy pretty much has a separate NPM package for every single function that he writes: https://www.npmjs.com/~sindresorhus (1162 packages under his name alone, maybe even more in other namespaces).

Wow. There is even one package to not use a JavaScript object: https://www.npmjs.com/package/conf

> More important than the namespace is who published the package. I'm more inclined to trust an individual I know who takes security than a namespace that may change hands.

Doesn't matter if you trust them; can you trust the 100+ dependencies they pull in? If it's a large package, you can be certain that they aren't verifying their deps.

So write a tool that checks the authors of all your transitive dependencies against your trusted list. (Or, more likely, pull one in, I'm sure someone's written that already). Are you a programmer or not? The amount of pearl-clutching over numbers of dependencies is something I'll never understand.

It works nicely in your theory, in practice no one does this because you always have a chain in which some dep is not trusted.

Always.

It's a poor ecosystem, dominated by untrustworthy participants. There's no digital identity verification of participants or their packages. anyone can claim to be whoever they want to.

Pointing this out is not pearl clutching, and if it was easy to solve it would have been done so by now.

The only way to trust a package is to verify the authors identity and verify that that identity generated that package.

But tying packages to domain names means that all these low effort two line package authors have to put in non-minimal effort (acquire a domain, maintain the cert) which is not going to happen.

> It works nicely in your theory, in practice no one does this because you always have a chain in which some dep is not trusted.

It works fine in practice; I've seen at least one big company do it. It doesn't happen in the public ecosystem only because people don't care enough.

> It's a poor ecosystem, dominated by untrustworthy participants. There's no digital identity verification of participants or their packages. anyone can claim to be whoever they want to.

Fixing that isn't hard. The Java/Maven ecosystem already enforces OpenPGP signing of all package uploads; NPM could do the same if they wanted.

But unfortunately the culture around npm is such that even entities that should be trustworthy pull in random transitive dependencies that aren't well vetted.

I work arch in a modern TS Angular Client for a larger education org and I'm shocked by the number of amateur devs and external contractors who think the solution for everything is 'just add a package'. Need to filter arrays in a pipe in one spot? Package. Paginate an array into a set of defined length arrays so you can do faux pagination in the ui? Package. Need a button of the design in our design system? Material UI and a hell of a lot of CSS, here we come!

I basically act as a middleman whose job is 'THIS IS A ONE LINE PIPE!'

Perhaps that's also due the lack of a proper standard library like every other language on this planet has.

And back in the day it was necessary because there weren't polyfills and there weren't build tools. Nowadays your JS is being run through Typescript or some other JS bundler and it's converting your code into something every browser can support.

If you're still using Lodash or Ramda or whatever it's because the standard library isn't quite as expressive as they are sometimes.

No mainstream language has a built-in GUI utilities.

(Except Java....maybe.)

I think tkinter is included with Python, but other frameworks are more popular. I struggle to think of any others.

I frequently push back on these complaints.

Does the library you pulled in to manipulate an array polyfill newer array prototype functions? If so it likely fixes issues in older browsers.

Does the library get tested by a much larger QA / QE user base than your ad hoc code? Importing a library might benefit you from not having to reinvent the wheel.

Does the library have unit tests and documentation? That is likely less work for your team to deal with bugs and maintenance.

In practical terms, I doubt I have ever written a line of code that nobody else in the world has written. In that sense, I know that my value to my company is to judiciously choose when to write code in-house and when to import. And the heuristic is way different than what you describe.

The nuance is: how much do you trust the package owners and their transitive dependencies to be:

Secure

Performant

Non breaking

etc.

I would hesitate to import a package for a one liner (a left pad for example) but happier to import a decent bunch of battle tested utils (date-fns, underscore, etc.)

Since each dep is a political org you need to trust, so I wanna get a decent amount of problems solved with that dep not just save a line of code.

underscore is actually our latest casualty in the new tool. It is now generally recommended to do array functions using standard JS if your product system reqs mesh.

Agree that every dependency is a new org to trust.

I’m very interested in ways to identify high quality+security libraries and orgs.

Simply saying “I am willing to rewrite everything from scratch” doesn’t work. Finding the best way to work with the existing ecosystem is more or less a requirement for most companies/projects.

I definitely think my comment lacked a bit of nuance that may have come off as a blanket statement, sorry about that.

My focus was on the types of poorly thought out package choices without the very care you are explaining. We would never reinvent rxjs, most tailwind plugins, or a key example of what you are explaining: Angulartics2.

But on the other hand, my example here is closer to some packages that have zero user base or are, in themselves, a reimplementation. The angular Material example is that we already have a design system with buttons that is heavily documented and tested, it would have been less work than dealing with the package to just read the documentation or ask questions.

We’ve built an open-source tool, called Packj [1], to offer developers more insights into packages, such as risky install hooks, embedded binary blobs, and other malicious/risky packages. It performs static/dynamic/metadata analysis to look for "suspicious” attributes.

1. https://github.com/ossillate-inc/packj

What’s the alternative? Ultimately, the issue isn’t “a dependency graph of a million tiny packages” but rather running other people’s code. If you read the attack details, this is a targeted campaign where people are being tricked into running untrusted code. I don’t see how removing small dependencies solves that problem.

I think a benefit of a smaller number of larger packages is reduces the number of parties you need to trust.

The people in charge of each larger package can review contributions made to it and have the authority to reject code that includes attacks. If a larger package doesn't do a good job of preventing attacks, its reputation will decline and because there are fewer packages involved it is easy to remember these reputations.

It's never as simple as finding exploits in code review though. Trusted accounts are compromised or the credentials to the package manager are compromised or there is some other supply chain attack. Larger packages tend to have a lot more community and governance around them than your typical JS-style function-as-a-dependency left-pad affair, so maybe they're safer if computer accounts are gatekeeping the published artifacts rather than having individuals embed their personal keys or tokens into the publishing pipeline.

I've had this debate before and, as far as dependencies go, sometimes you have to rip the bandaid off and audit your shit, and understand why exactly you outsourced something to a package.

That seems intuitive.

I agree in the sense that smaller supply chain surface area is easier to secure/verify.

But it also makes the developers/maintainers of the few packages much brighter targets.

I’m more of a fan of standardizing how libraries can be rated, evaluated, trusted, marketed, etc. we need more efforts analogous to Consumer Reports / Underwriters Laboratories. So far there are a few for-profit companies in this space, including Google.

With some other languages, you have big projects that basically are your secondary stdlib. Boost in C++, Apache Commons in Java, etc. These can reduce a lot of your dependencies down to a single umbrella project who stewards everything. The number of developers who work as maintainers on the packages within these projects is probably comparable to the number of developers working on the same sorts of packages in Node, but they're all working under a single banner, effectively. It's about having dependencies within projects as organizations vs the NPM approach where basically every dependency is it's own project and organization.

The JS ecosystem has moved away from massive monolithic packages due to bundle size constraints. Unfortunately, JS code has a lot of extra constraints placed on it since it has to be instantly performant over the wire. Something desktop apps don't have to deal with!

jQuery and Lodash could be considered "secondary stdlib" packages. Lodash for various data functions, and jQuery for dom manipulation functions. Now that other frameworks are more common and the basic stdlib is larger, many projects have migrated away from them to improve bundle size. (As an example, pulling in one lodash function tends to pull in lots of other functions from within lodash, unnecessarily inflating the amount of code sent to the browser.)

Another advantage of this, at last for the backend, is that Node itself has a small footprint. Compared to the JVM, Node is tiny. It does some IO stuff and some eventing stuff and not much else.

For the front end, ideally tree shaking is used, and even fancier build systems create code that doesn't pull down dependencies until they are actually needed at runtime.

Why not just strip out unused code? This has existed in other toolchains for years.

Tree shaking exists in build tools, but (1) libraries like Lodash have functions that use many other functions in the same library (for DRY reasons) and (2) the issue with NPM libraries is that they generally pull in all dependencies and Dev dependencies, not just an efficient dist / build minimal code set.

Fwiw I strip out my dev deps before publishing. I've started bundling in the prod deps and stripping them too. That way if I need like 5 random functions from 5 random packages the end result just includes the 5 funcs and has 0 deps. It avoids version issues too. And I don't minify anymore so it's very readable.

They don't even need to be big. They just need to cover a subject, but most of it needs to be the library code instead of a thin wrapper around multiple libraries. Take Carbon, the PHP library. It is centered around date time manipulation and provides a cleaner alternative to the standard library. It only has 6 dependencies, and I figure it wouldn't take long to vet it. The Laravel Framework also has few dependencies, and it was a delight to browse.

I created a small Node+Express project, added a few dependencies to handle things like CORS, API Authentication, ORM, and data validation, and my node_modules folder has 300 packages already. Frontend wise, it's worse.

I only used a few libraries when I was doing Android, most of them utilities and vendor SDKs. And the contrast is even higher in another project I'm working on. The Java Code takes less than 10 minutes to build, while the frontend code turns the laptop into a jet.

> I created a small Node+Express project, added a few dependencies to handle things like CORS, API Authentication, ORM, and data validation, and my node_modules folder has 300 packages already. Frontend wise, it's worse.

The vast majority of node dependencies are for testing frameworks and other tools that are never shipped to the customer.

For example, if you install any tool that does pretty command line output, odds are it installs some console UI libraries as a dependency, and odds are they also install a lower level curses like library as a dependency.

(Also I've yet to meet a simple ORM system!)

Jest is another common offender, much like every other popular testing framework, it is large and complex, and due to the nature of Javascript, it is also more powerful than a lot of the other testing frameworks I have seen (e.g. Jest can do stuff at runtime that Java frameworks need to do at compile time).

Those Java frameworks that go in and mock classes are complicated, but they are all hidden behind a "single" dependency.

Regarding front end build times, if a frontend website is taking any amount of time to build, something else is wrong (e.g. TypeScript is rebuilding everything one very build). Typical frontend website dev stacks have hot reloading enabled that allows for the site to be refreshed and updated the instant a file is saved. Nicer setups live change the DOM and try to avoid reloading the page unless something touching state management has been altered.

(My experience is with React and Svelte alongside TS, Angular may be a different story, not sure!)

> Those Java frameworks that go in and mock classes are complicated, but they are all hidden behind a "single" dependency.

I'd take complicated and sane over the literal software illusions that many npm packages are.

> Regarding front end build times, if a frontend website is taking any amount of time to build, something else is wrong;

Not necessarily. Any production build should start from scratch (the dependencies may be cached).

> due to the nature of Javascript, it is also more powerful than a lot of the other testing frameworks I have seen (e.g. Jest can do stuff at runtime that Java frameworks need to do at compile time)

oof... way to snatch defeat from the jaws of victory :(.

Jest is magic, but far less magic than rewriting JVM bytecode.

I generally prefer less magic over more magic.

> The vast majority of node dependencies are for testing frameworks and other tools that are never shipped to the customer.

So just to test I installed Django in a new virtualenv. I get a testing framework, and ORM, CORS, authentication, data validation, hot reloading and much more. It's three dependencies: django, asgiref and sqlparse.

Part of it is that Django just builds a ton of stuff on their own, but they also have the Python stdlib to build on.

As others mentioned you have things like Boost, the Go standard library, or even libc (of which there are multiple implementations). There's no reason why you couldn't have a JavaScript standard library, or multiple. They don't have to be shipped with the browsers, in fact I think that would be a bad idea. So when you start a new JavaScript project, you pull in your favorite standard library and when you ship your code, the bundler or whatever it's called could analyze your code pull out the relevant bits of the standard library and only include the bits you need.

> As others mentioned you have things like Boost, the Go standard library, or even libc (of which there are multiple implementations). There's no reason why you couldn't have a JavaScript standard library, or multiple. They don't have to be shipped with the browsers, in fact I think that would be a bad idea. So when you start a new JavaScript project, you pull in your favorite standard library and when you ship your code, the bundler or whatever it's called could analyze your code pull out the relevant bits of the standard library and only include the bits you need.

That is kinda-sorta how things work, except JS devs like to split code up into smaller modules.

https://www.npmjs.com/package/jest?activeTab=dependencies has 4 dependencies, if you look at @jest/core a lot of its dependencies are in fact other parts of the same project.

The lack of batteries included means there is a lot more room for diversity, if someone wants to write a new server to compete with express (and plenty of people have) they can follow the same middleware API standard and you can swap our your existing web server for another one but your ORM will still work!

Also a minimum viable JS Rest endpoint is literally 4 or 5 lines of code. Getting cors working is 2 or 3 lines more (based on if you count the import statement as a LoC).

Adding schema validation to an endpoint is another 2 LoC.

The number of concepts needed to be understood to setup an endpoint in Node land is minimal, and you can then build out whatever tools you want on top.

If you want a batteries included framework, there are also plenty of those, from fullstack systems Sveltekit and Next.js to multiple starter templates for backend services that give you whatever tools you wanted.

People go "Python has Django" and there are huge advantages to having a single golden path, but Node has a richness in the ecosystem that lets people start off small with and choose what tooling is best as their projects grow.

And at the end of the day, an ORM is going to require N lines of code, it doesn't matter if it is bundled with a framework of it is an external dependency.

...or you can have a solid stdlib like Go where you don't need any dependencies to do everything from encryption to regex to json encoding, image creation and MIME parsing.

I wish more languages would invest in their stdlib.

JS is burdened by being a browser standard though. But this could be worked on I agree. But then who leads that?

With Go there is an owner at least.

I am pretty sure that Javascript programmers would love to have a better stdlib.

But who is going to do it?

That might be bit better from a security perspective but modularity and code reuse are good things and npm makes them easy

I guess it’s a tradeoff

Consider a runtime like Microsoft's .NET:

    - The standard base class libraries with .NET are quite comprehensive; I end up rarely adding "utility" libraries
    - For non-standard libraries, Microsoft is a first party publisher of many packages on nuget; many of their first party frameworks and tools are published this way
    - For third-party libraries, generally speaking, I end up using maybe a dozen or so very well-known and well-vetted libraries which have low dependencies of their own (again, because of the rich standard libraries)
    - You end up with far less surface area for dependency chain attacks

According to the 2020 State of the Octoverse report [0]:

    - Node projects had nearly an order of magnitude more transitive dependencies than the next highest (683 to 70 for PHP) (p.11)
    - npm had the highest percentage of critical and high severity advisories (p.14)
    - 72.8% of JavaScript repos had dependabot alerts (well above the weighted average of 59%) compared to 6.5% for .NET and 40.2% for Java

Some would say that Microsoft's stewardship of .NET and C# is a negative; it can never be truly OSS. The flip side of that is that there is a professional team of paid software engineers -- some of the best in the world -- maintaining, patching, and securing the platform. While the third party ecosystem doesn't have as many options for doing X, the few options for doing X on .NET tend to be more well-rounded by the tighter community focus on a few, well-known libraries.

Maybe some variation of an Apache Foundation like approach to curating a set of OSS NPM libraries and some mechanism of establishing trust would be beneficial to the NPM ecosystem?

Just my take.

[0]: https://arxiv.org/ftp/arxiv/papers/2110/2110.10246.pdf

And for literal decades the 3rd party library ecosystem around .NET was anemic. Importing 3rd party libraries was an afterthought in the language, typically it involved downloading a .dll from some server, dropping it in the same folder as your project, and then manually editing some XML.

Things are better now, but for all its (many!) positives, .NET is not an example of how to create a good ecosystem.

Of course back then Microsoft considered an ecosystem to be 3rd party partners selling libraries, of which quite a few successful companies did.

nuget has existed since 2010.

.NET itself is only 2 decades old (first release in 2001).

Normalize writing your own code. If you’re in an environment where importing GetFirstChar from an essentially random person is the norm, this is bound to happen. It seems like some developers write code only if the functionality isn’t provided by some package, when really they should be reaching for the imports only if writing the package is too much effort.

This is the opposite of specialization, so there are reasons to not do this.

Examples: are you likely to write unit tests for your GetFirstChar? A specialized open source library that built this function is far more likely to have unit tests and documentation. Those unit tests and documentation come in handy during edge cases and when your coworker decides to extend the function with an `options` parameter.

Also, general developers rarely understand the full breadth of character sets, for example. So if your function just grabs the 1st byte from a string and expects it to be a character, your end user might be angry when only the first byte of a multi byte character is returned. Similarly the difference between a character and a glyph and a rune, etc. are important and lesser understood.

>difference between a character and a glyph and a rune

What is the difference?

Characters are abstract entities, glyphs are the shapes that represent them. a and a are two distinct glyphs for the same character.

"rune" is Go's name for a unicode code point.

The best option as always is somewhere in between and depends on context. If you’re Netflix or Walmart, localization is a high priority concern and these sort of things need to be considered. If you’re a N=50 company doing logistics for a fishing company, you probably only need to worry about your own internal Char representation that you have complete control over.

Having a few big dependencies would make you more likely to check them all out individually? I can never personally check my entire 2000 package forest, but if I had only 5 I could reasonably audit them.

Remember the Left-Pad debacle? That was already 7(!) years ago, yet I still remember like it was yesterday: https://news.ycombinator.com/item?id=11348798

It's not surprising that this is continuing to happen in JavaScript, the language whose userbase could actually be considered largely computer-illiterate.

That's not to say other languages don't have the same problems, but in my experience those who have experience with lower-level languages are more likely to have come from being power users and thus have a reasonable amount of computer literacy.

In contrast, the JS world is full of people who, lured by the promise of a well-paying easy job, "teach" themselves via the most shortcut-filled way and churn out a torrent of barely-working code that relies on others' barely-working code. It's pure quantity over quality and no one really understands what they're doing.

I kinda hate this take and to be clear this is coming from someone who did learn at the low level first: objective c then c++ with some fiddling with assembly and fpgas along the way. In my experience JS programmers are people who want to get things done and see results they can touch. It does have many inexperienced programmers, but because it's one of the better languages to learn if you want to get into programing. The people I saw learning it when I co-led an on campus club focused on encourage people to build things and a hacker mentality were interested in it because it was the path to building things they wanted to build not because it was the path to riches

The market asked for these developers, and it got them. Their inexperience is not a symptom of a decided ineptitude or nonchalance towards CS fundamentals. It’s a case of getting what’s required for a job (web apps and crud backends) and not much more.

I'd argue that if you limit your learning to what you need to get a job and not much more, you are exemplifying decided ineptitude and a nonchalant attitude towards the science that underpins your trade.

Capitalism doesn't reward anything more, which is the point.

And academia has gone down the drain just as well, just look at how ridiculously insecure and underpaid most academic employment is, outside of the holy grail aka tenure track of course. Meanwhile, universities blow billions on fucking sports teams.

Requiring brick layers to learn the chemistry of cement wouldn't suit society's demand for brick laying services.

It's not a matter of capitalism, it's a matter of priority.

We at this forum are a tiny minority of people who have the time and mental capacity to learn science. Most people in the world are struggling to have quality food and a roof.

Although not as essential as housing, the software industry also faces such challenges. Sure, every IT shop would love to have computer scientists, but they need some things done and there wouldn't be enough scientists if every developer was waiting to accomplish a full CS degree and get 5 years of high quality CS experience.

I'm not talking about credentials or trade vs science. I'm talking about the attitude and disposition of knowing just enough and tuning out the rest vs being curious and digging deeper. This has nothing to do with society, markets or staffing practices. This is about how each one of us can approach challenges.

Besides most people in the world are not struggling. Where do wealthy Americans get this idea that out there most people are poor and ignorant? Global poverty and vulnerability stands at around 15% of population.

no one said anything about growing them further, or limited their growth.

but this app needs to ship now, and we need 3 more bodies to make that happen. in a perfect world they'd be from an actual tech school, but bootcampers who can spell C-R-U-D might be good enough.

Thank you for being the first to say this! I can't believe no one has said this before.

The title is incorrect, npm malware spreads through social engineering, not social engineering through npm malware.

I expected npm packages to somehow carry the social engineering, like carry a message somehow, but that’s not the case.

npm and pip is a dumpster fire for IT production environment security. The out-of-band ecosystems evolved to sidestep bureaucratic processes in favor of rapid release versioning.

Anyone who understands the auditing role and provable chain of accountability FOSS OS packagers volunteer for... knows why it was necessary.

Malware will always show up, but it is arguably more important to be able to hold sources accountable. =)

…do people just accept invitations to clone repos on Whatsapp?

It's the least you can do for our North Korean comrades

I can only assume it's the same people who are opening "ImportantDocument.doc.exe" in their email.

We really need better (easier to use) sandboxing for apps, or in this case a project (create directory, few allowed apps, no access to rest of fs or a dummy fs, whitelisted urls/IPs only, etc.).

Sure you can use a VM, a container, firejail (for an app), etc. but it all has quite a high barrier to entry & burden to bother with, so the vast majority don't, and the majority of the rest only do occasionally for something they already trust less.

We (https://phylum.io) actually open sourced our sandbox for this exact purpose.

https://github.com/phylum-dev/birdcage

It's baked into our CLI and supports limiting access to network, disk, etc. during package installation. For example, running something like

    phylum npm install react

Will perform the installation in a way that disallows access to disk and network that aren't explicitly approved. This prevents malicious packages from grabbing and exfiltrating things like developer SSH keys during package install.

Ha, well now I look like a shill installed in the audience. Nice though, I'll give that a go, thanks.

It's probably manageable through direnv & some shell magic, but it'd be nice to have a built-in way of saying 'everything in this directory gets run through phylum [with these defaults] and has access to only this directory [by default]'.

It's basically managed by a TOML file, so should be able to specify something like that. If that's not to your liking, you can extend the CLI using Typescript and make it do whatever you want.

If you have any questions/issues, feel free to shoot me a message. My email should be in my profile!

Try Qubes OS. It runs everything in VMs, but the UI is amazingly usable. The VMs look like ordinary windows with different border colors. Inter-VM copy-paste works with ctrl+shift+c/v.

Well... sure, but frankly 'just use a different operating system' is exactly the kind of 'we need better (easier)' than I'm talking about.

IMO the whole approach to security in ordinary operating systems is practically flawed, if you actually need a strong security guarantee.

Nice ad.

My thoughts exactly. Every time something like this makes the frontpage, it's a thinly veiled ad for whomever the author works for.

I really want to see those WhatsApp chats...

The last few articles I've read about dependency chain attacks have been from socket.dev, and frankly, they've all been interesting and included important research. I don't mind content marketing when it's relevant and a description of important work. Would you rather nobody get paid to work on products targeting supply chain integrity? It's a real and important problem.

I don’t think anyone has issues with pertinent content marketing that also provides something to the community.

The argument can be made that the _important_ work was already done by GitHub and Phylum. This just appears to be a derivative work without any additional value add. That is, it functions mostly as an advertisement.

Doesn’t help that they clearly don’t even have all the malware packages in their system from this campaign, three weeks after the attacks…

https://socket.dev/search?e=&q=Btc-api-node

In his talk, Feross mentioned that it would cost approximately 1 billion dollars to scan the entire npm ecosystem. They do it on demand for their customers IIRC. Try signing up and running their scans on it.

There’s no way that’s true. Last I checked there were 16M packages in npm, not counting versions. If we bump that up to 20M and add a multiple of 30 to account for versions, we get 60M total tar.gz files we’d need to scan.

At a total cost of $1B that would put scanning a single package at $16/package? Nonsense. Even at $1 in compute time on aws that feels outlandishly high…

You can’t retroactively scan the package Socket missed. It was removed from npm. Scanning on demand means you’re going to miss critical relationships across threat groups, or across disparate but related packages.

Retroactive scanning, you have a point. Integrating the scan into your CI/CD would catch it.

As for the numbers: see 39 mins into https://youtu.be/jWujI7Hk8O4

I used to work at npm as the SRE manager right before the acquisition and the ballpark figures make sense to me.

I admittedly pulled the numbers out of thin air, and things I thought I’d seen before.

Had a second to sit down, and I _way_ overestimated my counts.

Per NPM there are 2,480,373 packages. According to Whitesource [1] there are an average of 12.3 versions per package. This gives us a total of 30,508,587.9 archives to scan. At a cost of $1B to scan that means each package would cost $33.959…

There’s no way that’s reality. That seems like several orders of magnitude too high.

1. https://threatpost.com/malicious-npm-packages-web-apps/17813...

But they’ve got a point. And they’re one of the first to market.

Yeah I’d get it if their solution was only tangentially applicable (it’s directly applicable). I certainly don’t want YC:HN to turn into GPT generated ad-city either.

If you met Feross, you’d agree he and his team are deserving of the credit for finding a timely and constructive solution to supply chain problems without filling OpenAI with your IP. He lives the kind of values we respect on YC:HN.

I had the pleasure at Refactor Conf in Toronto a couple of weeks ago. You can watch his talk here: https://youtu.be/jWujI7Hk8O4

(I have no pecuniary interest in Refactor conf. I just think it was an awesome time.)

Both of these things can be true at the same time:

1. An article is posted with informative, useful, original content.

2. An important motivation of the article author is marketing to get people to use or become aware of their product.

I see no problem with this. I think it's always important to keep the motivation of the author in mind, regardless of whether it's an ad for a product or just the author themself.

JS Party episode on Socket, if anyone is interested: https://changelog.com/jsparty/272

"It's called fullstack webdev jobs" /s

Reply on news.ycombinator.com