Question for tanepiper: what would you have Microsoft do to improve things here?

My read of your article is that you don't like postinstall scripts and npx.

I'm not convinced that removing those would have a particularly major impact on supply chain attacks. The nature of npm is that it distributes code that is then executed. Even without npx, an attacker could still release an updated package which, when executed as a dependency, steals environment variables or similar.

And in the meantime, discarding box would break the existing workflows of practically every JavaScript-using developer in the world!

You mention 2FA. npm requires that for maintainers of the top 100 packages (since 2022), would you like to see that policy increased to the top 1,000/10,000/everyone? https://github.blog/security/supply-chain-security/top-100-n...

You also mention code signing. I like that too, but do you think that would have a material impact on supply chain attacks given they start with compromised accounts?

The investment I most want to see around this topic is in sandboxing: I think it should be the default that all code runs in a robust sandbox unless there is as very convincing reason not to. That requires investment that goes beyond a single language and package management platform - it's something that needs to be available and trustworthy for multiple operating systems.

▲

rs186 3 days ago | parent | next [-]

Exactly.

The biggest problem with npm is that it is too popular. Nothing else. Even if you "mitigate" some of the risks by removing features like postinstall, it barely does anything at all -- if you actually use the package in any way, the threat is still there. And most of what we see recently could happen to crates.io, pypi etc as well.

It is almost frustrating to see people who don't understand security talk about security. They think they have the best, smartest ideas. No, they don't, otherwise they would have been done a long time ago. Security is hard, really hard.

	▲	singulasar 3 days ago \| parent [-]
		There's multiple security firms by now that constantly scan updated npm packages for malware. Obviously those companies can only do this after a new package has been published. Npm could add this as an automated step during publishing. Sure, there's a manual review needed for anything flagged, but you can easily fix this as well by having smth like a trusted contributor program where let's say you'd need 5 votes to overrule a package being flagged as malware

▲

dns_snek 3 days ago | parent | prev | next [-]

For a start, maintainers of dependencies with more than 1000 weekly downloads should be forced to use phishing-resistant 2FA like WebAuthN to authenticate updates (ideally hardware security keys, but not strictly necessary), or sign the code using a registered PGP key (with significant cooldown and warnings when enrolling new keys, e.g. 72h).

▲

tanepiper 3 days ago | parent | prev | next [-]

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 3 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)

▲

zachrip 3 days ago | parent | prev | next [-]

What about if pw or 2fa change, your tokens go on a 24hr cooldown? I think the debug package maintainer even provided his 2fa to the phishing site. Obviously doesn't fix the case where they just exfiltrate and use tokens, but there's no fix that solves all of this, there needs to be layers. I also think npm should be scanning package updates for malicious code and pumping the brakes on potentially harmful updates for large packages.

▲

Ajedi32 3 days ago | parent | prev | next [-]

I made a list a few years back: https://news.ycombinator.com/item?id=29266992

At the time, I was focusing more on the approach of reducing the number of people you have to trust when you depend on a particular package.

▲

whatevaa 3 days ago | parent | prev [-]

Code signing would help with stolen authentication tokens.