Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Malicious npm packages detected across Red Hat Cloud Services

github.com

Post reply on HN
Print view View original

41–50 of 494 posts

Re: Malicious npm packages detected across Red Hat Cloud Services

#41

Post by twodave »

gbuk2013 wrote: post #17

I came across this interesting rant the other day: https://github.com/uNetworking/uWebSockets.js/blob/master/mi... It does make sense that the right way would be to fork every dependency you use and install from your own repo reviewing and merging from upstream as needed. Would be a giant PITA though. :)

For smaller shops (by small I mean <1,000 employees) this isn't even tenable. We (engineering team of about 10 people) mitigate what we can via tooling and cooldown periods/minimum release age. This will work as long as these malicious packages remain reasonably detectable. I think that's the proper balance, because we can adjust the # of days we are willing to risk against the SOTA of detection tooling.

Re: Malicious npm packages detected across Red Hat Cloud Services

#43

Post by freakynit »

throwwwll wrote: post #28
chuckadams wrote: post #13

Earlier quoted context omitted.

The big attacks of today are spread across several package ecosystems: TrapDoor and Shai-Hulud have been hitting npm, pypi, composer, and crates with the same malware.

And all of them "thought" of security as an after-after-after-after-after-thought.

Most of these are now building upon techniques that have already been exploited since past 1 years. This attack used 4 of those techniques.

1. Lifecycle Hook Execution

2. CI/CD Identity Plane Attacks

3. Maintainer Account Takeover and Malicious Publish

4. Self-Replicating npm Worms

https://npm-supply-chain-attack-techniques.pagey.site/

Re: Malicious npm packages detected across Red Hat Cloud Services

#44

Post by sandos »

Tomte wrote: post #15
phoronixrly wrote: post #7

Earlier quoted context omitted.

What happens when everyone adopts this policy? You just change it to two weeks?

You rely on the security companies scanning the packages.

Then the ... malware will just add delays? Or do they really do manual in-depth analysis of all new code? Just running and seeing it do things is probably a lot easier.

Re: Malicious npm packages detected across Red Hat Cloud Services

#47

Post by dralley »

phishin wrote: post #39

Chainguard based images, packages and libraries are first line of defense. Expensive? Yes. Foolproof? No. I think these types services will be mandatory in the near future.

How would that help? These are not general purpose, base system libraries, these are libraries specific to a product that uses them. Either you're not using them and hence they would not be installed in the first place, or you're using them because you have the product installed.

Though I would expect that Insights uses RPM packages to ship components and not the public NPM packages.

Re: Malicious npm packages detected across Red Hat Cloud Services

#48

Post by general_reveal »

keyle wrote: post #46
general_reveal wrote: post #26

That’s why I switched to Java.

AbstractFinalFactoryShaiHuludSerialisedFactory

Yeah but you don’t have to use that I think. I think us Node people can just pretend to write Ecmascript 2 in Java and be fine.

Re: Malicious npm packages detected across Red Hat Cloud Services

#49

Post by TZubiri »

jofzar wrote: post #3

'No Way to Prevent This,' Says Only package manager Where This Regularly Happens Edit: some people don't understand that it's a defence to https://en.wikipedia.org/wiki/%27No_Way_to_Prevent_This,%27_...

tbf this is happening with a lot of package managers now, including pypi and composer

Re: Malicious npm packages detected across Red Hat Cloud Services

#50

Post by dboreham »

gbuk2013 wrote: post #17

I came across this interesting rant the other day: https://github.com/uNetworking/uWebSockets.js/blob/master/mi... It does make sense that the right way would be to fork every dependency you use and install from your own repo reviewing and merging from upstream as needed. Would be a giant PITA though. :)

I think the general idea that your supply chain should be rooted in source repositories and associated commit hashes is the right one. Tooling can be made to automate the process of putting together a product from those defined sources. Some languages/systems already have some support for this. E.g. Golang and Rust. The concept of a "binary" artifact is really dead now everyone uses git and builds are quick. It lives on in things like npm and docker hub but we don't actually need it.
Post reply on HN