[stephenr]

I mean even if you blindly copy in the dependency (I'm not saying you should) you've already solved two supply chain issues with install-on-prod:

- dependencies "disappearing" (aka left pad 2, electric boogaloo)

- dependencies running nefarious "install scripts" on prod

Apparently some language package managers also will silently install newer versions than a lock file specifies, if you use the wrong install command. So that's arguably more a case of saving you from yourself but the example I saw said that "... install" is wrong you need to use "... ci" which is kind of asinine IMO.

Things like sudden changes in dependencies should also be noticed more readily.

[MeetingsBrowser]

Copy/pasting source code doesn't solve either of those problems either.

If you already had left pad cached then you were not affected by its disappearance.

If a package needs an install script to be used, to compile some native code for example, you still need to run the install script before you can use the package.

Manually repeating the actions npm does automatically does nothing to protect you from supply chain attacks.

The only thing that helps is to review code before you run it. How the code got to your machine before it was run does not matter.

[matbanik]

The real vulnerability isn't the supply chain, it's the muscle memory of running install and update reflexively without reading what changed.

[stephenr]

> If you already had left pad cached then you were not affected by its disappearance.

The evidence of course is that when you say "left pad" no one knows what you're referring to because nothing bad ever happened.

> If a package needs an install script to be used, to compile some native code for example, you still need to run the install script before you can use the package.

This already sounds like a giant red fucking flag, but sure whatever, what you're using needs some compile step. You can be in control of what runs when and where. Heck you could even take the fucking maverick solution and compile the shit once out of band and deploy the compiled binary to your production environment. I know that forethought and planning ahead will come as a fucking shock to the NPM using community, but try it some time, it's really kinda good.

> Manually repeating the actions npm does automatically does nothing to protect you from supply chain attacks.

I mean it does, inherently, if you're running those actions locally in an environment without production access...

Oh noes, your compromised module stole your DB credentials, and your SES credentials to spam all your customers..... and just got a bunch of failures or sent messages to no-one because the environment has dummy data and uses a locked down sending configuration for SES.

There is 100% benefit in running that shit in a development environment.

> The only thing that helps is to review code before you run it.

Right, and somehow you think having the code in question literally in your VCS, waiting for a merge like all the other code... that's not apparently helpful.

But hey thanks for proving me right about the unhinged complaints. Stong echoes of "we've tried nothing and we're all out of ideas".

[MeetingsBrowser]

> There is 100% benefit in running that shit in a development environment.

Most of the recent supply chain attacks specifically target stealing secrets from development environments.

> But hey thanks for proving me right about the unhinged complaints.

I'm sorry if I'm upsetting you, but I am not complaining or trying to provoke you.

"Just check in the dependencies and review them" is not a revolutionary idea. It makes sense in many contexts.

But it is not practical in the overwhelming majority of contexts. React's last minor version bump included 100 files and ~5k changes. It also bumped the versions of 6 direct dependencies, which in turn bumped dependencies, etc.

It is not reasonable for a small (or even medium) team using react to manually review all of the changes and all the changes in react's transitive deps each time they need to update. The problem grows exponentially with all of the other common projects and libraries likely being used in a front end project(vite, react router, redux, vitest, etc).

pick a few non-trivial npm projects and try to audit all of the changes (for all transitive dependencies) for a few releases that bumped dependencies.

[stephenr]

> Most of the recent supply chain attacks specifically target stealing secrets from development environments.

If your secrets in a dev environment can actually do any damage if leaked, you're doing something very fucking wrong.

> React's last minor version bump included 100 files and ~5k changes.

So you're choosing over engineered dependencies and then complaining they're too big.

Somehow I think the problem, as usual, started with the meat sack on the chair.

[MeetingsBrowser]

I think we may be talking past each other at this point, but secrets from a dev env can be more valuable than secrets from a production env.

With things necessary for a dev env, like read/write access to source control, attackers can get access to internal data, and push malicious code that gets run in a prod env anyway.

If you want to make the claim that using react is an insane indefensible choice from a security standpoint, you are being idealistic at best.

Telling people not to use react does not help anyone, and that type of recommendation causes reputational damage to the security industry.

[stephenr]

We are clearly talking about different things.

Access to source control is required on a developer workstation.

It is not required inside an application environment on that workstation (eg a VM or other such system that both provides a standard environment and creates separation)

I'm not making any claims about the security of react.