Oh I agree - it's far too late to make major changes. When they took over, they had the opportunity to drive a new roadmap towards a more secure solution.

2FA isn't a solution to security, it's a solution to hinder and dissuade low-effort hackers from compromising accounts - it's still subject to social engineering (like spearphishing).

I tend to agree with your broader point - sandboxing will be the way to go, I've been having that very discussion today. we're also now enforcing CI pipelines with pinned dependencies (which we do with our helm charts, but npm by default will install with ^ semver and putting that on the developer to disable isn't good enough - the problem of course is that requires the OS vendors to agree on what is common.

This is a riff - not sure how possible this is, but it's not coming from nowhere, it's based on work I did 8 years back (https://github.com/takeoff-env/takeoff) - using a headless OS container image with a volume pointing to the source folder, run the install within the container (so far so good, this is any multi-stage docker build)

The key part would be to then copy the node_modules in the volume _data folder back to the host - this would of likely require the OS vendors to provide timely images with each release of their OS to handle binary dependencies, so is likely a non-starter for OSX.

▲

inbx0 3 days ago | parent | next [-]

I don't think pinning deps will help you much, as these incidents often affect transitive dependencies not listed in package.json. package-lock.json is there to protect against automatic upgrades.

I know there are some reports about the lockfile not always working as expected. Some of those reports are outdated info from like 2018 that is simply not true anymore, some of that is due to edge cases like somebody on team having outdated version of npm or installing a package but not committing the changes to lockfile right away. Whatever the reason, pinned version ranges wouldn't protect against that. Using npm ci instead of npm install would.

	▲	tanepiper 3 days ago \| parent [-]
		No, it doesn't solve it - but it might minimise the blast radius - there are so many unmaintained libraries of code that indeed one compromised minor patch on any dependency can become a risk. That's sort of the thing - all of these measures are just patches on the fundamental problem that npm has just become too unsafe

▲

czbond 2 days ago | parent | prev [-]

I have come to using a multi stage Docker build. One to install dependencies and build whatever it is. I then might have a second clean docker image where the dependencies are copied to and run.

This helps with localized risk, and some production risk - but not all of it.

NPM packages have become a huge nuisance security wise.

	▲	tanepiper 2 days ago \| parent [-]
		Yes, also using multi-stage container - we output signed OCI to our repository and have Rekor and GitHub for SBOM and attestation. This is another huge pet peeve of mine is how hard it is to have a good container pipeline to build containers without running root - we tried some of the alternatives but they all had drawbacks - easiest is to just use GitHub Ubuntu images and hope for the best (although I recently saw some improvement in this area we want to investigate)