NPM debug and chalk packages compromised

Tips to protect yourself from supply-chain attacks in the JavaScript ecosystem:

- Don't update dependencies unless necessary

- Don't use `npm` to install NPM packages, use Deno with appropriate sandboxing flags

- Sign up for https://socket.dev and/or https://www.aikido.dev

- Work inside a VM

Can you expand on "use Deno" for installing dependencies? I assume you don't mean to use Deno as the runtime, just for dependency management.

I do mean use Deno as the runtime. Details and examples of how to switch are here: https://crib.social/notice/AwQqG9gm365uat93Nw

> Don't update dependencies unless necessary

And get yourself drowning in insurmountable technical debt in about two months.

JS ecosystems moves at an extremely fast pace and if you don't upgrade packages (semi) daily you might inflict a lot of pain on you once a certain count of packages start to contain incompatible version dependencies. It sucks a lot, I know.

Updating packages daily (!) is insane to me as someone from the other end of the programming spectrum (embedded C). Is this really the recommended practice?

It varies but there are a lot of tools built around the idea of rapid updates so things like APIs can change quickly throughout a far more fragmented ecosystem. I suspect that we’re going to see a lot of places back off of that a bit to have something like monthly update cycles where there’s more time for scanning and review while still expecting people to upgrade more frequently than used to be common.

It is insane to me as a C programmer as well. It is something I got used to as a frontend js developer.

It so recommend to stay on top of the dependencies and for different stacks this means different update schedule. For some, daily is indeed a good choice.

> daily

Somehow we've survived without updating dependencies for probably at least a year.

How would this have prevented anything?

Then you probably have over a dozen CVEs in your code. Now, this is a different question whether they are exploitable and how much it is a risk.

Other than that you now probably have an insurmountable technical debt and upgrading the dependencies is a project of itself.

All the above applies to JavaScript world, of course. It's much different for the rest.

It really isn't, and I've never seen anyone do that. In every project I've worked on in the past decade, dependencies were only occasionally bumped in the context of some maintenance task or migration.

   content-security-policy: default-src 'self';

(and not sending crypto transactions): No need to worry about CVEs in js

Even if there is a new version every day, not every release is born equal. Wouldn't updating while developing to "stay on top of dependencies" only be necessary on a major version? Surely there is not a major version per day. I mean otherwise you would use a library, that constantly imposes work on you and it would probably make more sense to write the library yourself. Minor versions and bugfixes can be incorporated when you do your release.

If a library introduces CVEs per day, it's probably not so good to begin with.

In this case it would not have prevented anything, but I never claimed that it would. Using Deno with appropriate sandboxing flags can protect developers against many classes of supply-chain attacks.

The reason it doesn't help in this instance is because the attack targets the generated bundle and runs on client devices, whereas other attacks will target developer machines themselves (and possibly also client devices). Those types of attacks can be mitigated by using Deno.

> Then you probably have over a dozen CVEs in your code.

We continuously monitor our dependencies for CVEs and update them if necessary. Most of the time the CVEs that are reported are not relevant / worth updating for.

All I want to say is that it's truly cheaper to upgrade and test daily in the world or javascript. Seriously, it breaks rarely and you can immediately spot what exactly failed and fix it right away.

Upgrading after a month will take some serious time.