Earlier quoted context omitted.
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/
Malicious npm packages detected across Red Hat Cloud Services
81–90 of 494 posts
Re: Malicious npm packages detected across Red Hat Cloud Services
#82Redhat's entire reason for existence is to prevent this.
Re: Malicious npm packages detected across Red Hat Cloud Services
#83Our company uses yarn 4 which has an option to prevent you from installing an npm package for the first number of days of its release. Most of these seem to be caught within that timeframe (1-3 days). https://gist.github.com/mcollina/b294a6c39ee700d24073c0e5a4e...
There is something to be said about the need to keep all the packages as the latest and the greatest at all times. Every minor version update doesn’t need to be immediately applied. And maybe high and critical vulnerabilities don’t need to be a minor version upgrade.
huh? what do you suggest instead?
Re: Malicious npm packages detected across Red Hat Cloud Services
#84Re: Malicious npm packages detected across Red Hat Cloud Services
#85Earlier quoted context omitted.
Let me provide context, since a bunch of people responding with "every package manager can be hit!!!" npm, by design, allows all packages to run package supplied arbitrary code as the logged-in user after an update completes. That's an INSANE default. pnpm, by contrast, allows you to essentially "opt-in" only specific packages that need this (e.g. four out of thirty, in one of our projects). Then tacks on tons of oth…
> they've taken no action. Not running lifecycle scripts by default is eventually going to be the default behavior. Late is worse (edit: I meant better) than not at all. https://github.com/npm/rfcs/pull/868
Re: Malicious npm packages detected across Red Hat Cloud Services
#86Earlier quoted context omitted.
Let me provide context, since a bunch of people responding with "every package manager can be hit!!!" npm, by design, allows all packages to run package supplied arbitrary code as the logged-in user after an update completes. That's an INSANE default. pnpm, by contrast, allows you to essentially "opt-in" only specific packages that need this (e.g. four out of thirty, in one of our projects). Then tacks on tons of oth…
Mosts packages manager, allow that. pnpm can still be exposed, afterall the worm simply have to wait you run tests locally.
But that's a "Perfect is the enemy of good"-like argument. Wherein: Why even reduce an easy to exploit attack surface when there could be holes elsewhere?! Because, you know, it makes things much more secure even if imperfect.
Plus, to me, it is a culture issue. npm just doesn't take security seriously, so we don't see these improvements, and if there was additional test hardening later, I don't expect we'd see them in npm either. Since, they just don't care.
Re: Malicious npm packages detected across Red Hat Cloud Services
#87Earlier quoted context omitted.
All programming language package managers are vulnerable. They all have the exact same caveats as the Arch Linux User Repository. There are no trusted maintainers taking responsibility for things. Any random person can make an account and push packages.
While true, tarring Arch here is a little unfair. AUR isn't enabled by default. It can't even be used via the same package front end, and in fact the "official" usage model requires that you clone the source yourself. Indeed, AUR is bad as a software distribution mechanism (really it's best understood as a proving ground for baby packages before they get real maintainers and distro blessing), but it's less bad than N…
Re: Malicious npm packages detected across Red Hat Cloud Services
#88Re: Malicious npm packages detected across Red Hat Cloud Services
#89'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_...
Please stop posting this on every single security incident thread with npm. It was funny once, it's just rehashing the same debate over and over.