Earlier quoted context omitted.
This is a culture issue with developers who find it OK to have hundreds of (transitive) dependencies, and then follow processes that, for all intents and purposes, blindly auto update them, thereby giving hundreds of third-parties access to their build (or worse) execution environments. Adding friction to the sharing of code doesn't absolve developers from their decision to blindly trust a ridiculous amount of third-…
> This is a culture issue with developers who find it OK to have hundreds of (transitive) dependencies, and then follow processes that, for all intents and purposes, blindly auto update them I do not know about NPM. But in Rust this is common practice. Very hard to avoid. The core of Rust is very thin, to get anything done typically involves dozens of crates, all pulled in at compile time from any old developer impli…
Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised
651–660 of 1001 posts
Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised
#652Earlier quoted context omitted.
Don't update your dependencies manually. Setup renovate to do it for you, with a delay of at least a couple of weeks, and enable vulnerability alerts so that it opens PRs for publicly known vulnerabilities without delay https://docs.renovatebot.com/configuration-options/#minimumr... https://docs.renovatebot.com/presets-default/#enablevulnerab...
Why was this comment downvoted? Please explain why you disagree.
Depending on a commercial service is out of the question for most open source projects.
Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised
#653On the contrary - almost being a decade into Elixir - most of the time, I don't need (and I don't like) using external dependencies. I can just write something myself in a matter of just an hour or so because it's just so easy to do it myself. And everything I've written till date hasn't required an audit or re-write every 6 months or sometimes, even for years.
We all seem to hate the concept of Nazis and yet somehow we have done nothing about the Nazi-est language of them all which literally has no other alternatives to run on web browsers?
Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised
#654My comment yesterday, which received one downvote and which I will repeat if/until they’re gone: HTTP and JS have to go. There are ways to replace them.
HTTP?
Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised
#655I have been telling people for ages - Javascript is a pack of cards. We have progressed as a society and have so many alternatives for everything, and yet, we still haven't done anything about Javascript being forced down onto us by browsers. If it wasn't for web browsers, JS would have become irrelevant so fast because of how broken it is - both as a language and its ecosystem. On the contrary - almost being a decad…
Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised
#656As a user of npm-hosted packages in my own projects, I'm not really sure what to do to protect myself. It's not feasible for me to audit every single one of my dependencies, and every one of my dependencies' dependencies, and so on. Even if I had the time to do that, I'm not a typescript/javascript expert, and I'm certain there are a lot of obfuscated things that an attacker could do that I wouldn't realize was embed…
I recently started using npm for an application where there’s no decent alternative ecosystem. The signal desktop app is an electron app. Presumably it has the same problem. Does anyone know of any reasonable approaches to using npm securely? “Reduce your transitive dependencies” is not a reasonable suggestion. It’s similar to “rewrite all the Linux kernel modules you need from scratch” or “go write a web browser”.
I would love to have something like that "in the open"…
Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised
#657Earlier quoted context omitted.
Have we all forgotten the left-pad incident? This is an eco system that has taken code reuse to the (unreasonable) extreme. When JS was becoming popular, I’m pretty sure every dev cocked an eyebrow at the dependency system and wondered how it’d be attacked.
> This is an eco system that has taken code reuse to the (unreasonable) extreme. Not even that actually. Actually the wheel is reinvented over and over again in this exact ecosystem. Many packages are low quality, and not even suitable to be reused much.
Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised
#658As a user of npm-hosted packages in my own projects, I'm not really sure what to do to protect myself. It's not feasible for me to audit every single one of my dependencies, and every one of my dependencies' dependencies, and so on. Even if I had the time to do that, I'm not a typescript/javascript expert, and I'm certain there are a lot of obfuscated things that an attacker could do that I wouldn't realize was embed…
Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised
#659As a user of npm-hosted packages in my own projects, I'm not really sure what to do to protect myself. It's not feasible for me to audit every single one of my dependencies, and every one of my dependencies' dependencies, and so on. Even if I had the time to do that, I'm not a typescript/javascript expert, and I'm certain there are a lot of obfuscated things that an attacker could do that I wouldn't realize was embed…
Use NPM Package Cooldown Check
The NPM Cooldown check automatically fails a pull request if it introduces an npm package version that was released within the organization’s configured cooldown period (default: 2 days). Once the cooldown period has passed, the check will clear automatically with no action required. The rationale is simple - most supply chain attacks are detected within the first 24 hours of a malicious package release, and the projects that get compromised are often the ones that rushed to adopt the version immediately. By introducing a short waiting period before allowing new dependencies, teams can reduce their exposure to fresh attacks while still keeping their dependencies up to date.
Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised
#660So, other packaging environments have a tendency to slow down the rate of change that enters the user's system. Partly through the labor of re-packaging other people's software, but also as a deliberate effort. For instance: Ubuntu or RedHat. Is anyone doing this in a "security as a service" fashion for JavaScript packages? I imagine a kind of package escrow/repository that only serves known secure packages, and acti…
I've worked in companies that do this internally, e.g., managed pull-through caches implemented via tools like Artifactory, or home-grown "trusted supply chain" automation, i.e., policy enforcement during CI/CD prior to actually consuming a third-party dependency. But what you describe is an interesting idea I hadn't encountered before! I assume such a thing would have lower adoption within a relatively fast-moving e…