cli VS npm

Co-funder @ Phylum here (https://phylum.io) We have been actively scanning dependencies across npm (and PyPI, RubyGems, Crates.io, etc.) for nearly three years now; quite successfully, I might add (https://blog.phylum.io/tag/research/). We _automatically_ hit on this package when it was published, and our research team has been all over it.

A collective of us are active in Discord (https://discord.gg/Fe6pr5eW6p), continuing to hunt attacks like these. If that's something that interests you, we'd love to have you!

In addition to this, we've released several open source tools to help protect against supply chain attacks:

1. https://github.com/phylum-dev/birdcage - Birdcage is a cross-platform embeddable sandbox that's been baked into our CLI (which wraps npm, pypi, etc.) to sandbox package installations

2. https://github.com/phylum-dev/cli - Our CLI provides an extension capability so you can lock down random executables you might use during your software development (define _what_ it's allowed to do, e.g. network access, and then lock it down with Birdcage)

We also have a variety of integrations, including Github, Gitlab, BitBucket, CircleCI, Tines, Sophos, etc.

https://docs.phylum.io/docs/integrations_overview

It's unfortunate that software dependency attacks continue to plague open source registries. It seems unlikely this will let up in the near future. We are continuing to work closely with the open source ecosystems to try and get these sorts of packages removed when they pop up.

We're actively working on this with our sandbox (https://github.com/phylum-dev/birdcage). We've wrapped the likes of pip, yarn, and npm already and are making moves to similarly provide support for cargo.

Currently comes as part of the Phylum CLI (https://github.com/phylum-dev/cli), so that doing something like:

    phylum npm install 

cli - uses sandbox to block packages during installation, performs pre-install checks to determine (by hitting the API) if the package performs actions congruent with malware, e.g. phylum pip install requests will use pip wrapped by the sandbox to install requests after verifying that it doesn't have malware like behavior.

This is bundled with our CLI tool today (which is also open source) and allows you to install packages with phylum npm install . We currently support npm, yarn and pip and are planning on rolling out further support for other ecosystems in coming months.

We open sourced our tooling to help with this problem specifically. We have an extension framework that wraps npm for three purposes:

Our CLI tool (also open source and free) will check for typosquats, dependency confusion, malicious code, vulnerabilities, etc. in your package dependencies. Works for pypi, npm, rubygems, maven, nuget and very recently golang and rust crates.

This is built into the Phylum CLI so you can do things like:

This is one of the projects we're working on (and open sourcing)!

Currently allows you to specify allowed resources during the package installation in a way very similar to what you've outlined [1].

The sandbox itself lives here [2] and can be integrated into other projects.

1. https://github.com/phylum-dev/cli/blob/main/extensions/npm/P...

2. https://github.com/phylum-dev/birdcage

We will start here with a slightly more in-depth, custom version of the existing NPM shim extension - a tool that enforces default project policy when installing NPM packages. This custom extension will do some additional custom validation before allowing the installation process to continue.

The fact that JSON doesn't support comments is so annoying, and I always thought that Douglas Crockford's rationale for this basically made no sense ("They can be misused!" - like, so what, nearly anything can be misused. So without support for comments e.g. in package.json files I have to do even worse hacky workaround bullshit like "__some_field_comment": "this is my comment"). There is of course jsonc and JSON5 but the fact that it's not supported everywhere means 10 years later we still can't write comments in package.json (there is https://github.com/npm/npm/issues/4482 and about a million related issues).

Things like the sparkline charts on npmjs (e.g. https://www.npmjs.com/package/npm ) are interactive SVGs. I think they're pretty common for data visualizations of all kinds

I actually did a POC 7 years ago about this - https://github.com/tanepiper/steal-ur-stuff

It was reported to npm at the time, but they chose to ignore it - https://github.com/npm/npm/issues/17724

Every time this pops up, I'm reminded of the day that the NPM registry started returning 418 responses.

I remember being at a training course that day and my manager asking me what we could do to fix it because our CI was failing to pull dependencies from NPM.

Trying to explain that NPM was returning a status code intended as an April Fools joke and which was never meant to see the light of production was quite difficult

https://github.com/npm/npm/issues/20791

I should really get around to how I discovered this 6 years ago and still nothing done about it

Whenever something like this comes up I usually have to tap the sign (and the original report)

NPM is not "Node Package Manager". https://www.npmjs.com/package/npm

> which can be overriden with env setting

Support for this is not great. Lots of packages still don't support this properly. My experience matches the 2015 comment https://github.com/npm/npm/issues/775#issuecomment-71294085

> Not sure why "symlinks" would be involved.

If you make your node_modules a symlink, multiple packages will fail. Even if you're not interested in doing that, others are.

> What NPM does is leaps and bounds ahead

Unless you change your node / gyp version. It doesn't really have a concept of runtime version. You can restrict it, but not have two concurrent versions if they conflict.

[email protected] was released in May 2017 and it seems to address many of the issues that Yarn aims to solve. Do keep an eye on it!

I think it's had been supposed to do that since forever. Apart from some bug in npm 5.3. Are you sure your package-lock versions actually conform to the semver ranges in your package.json?