crev VS cli

In other cases it may be more documented, such as Golangs baked-in telemetry.

There should be better ways to check these problems. The best I have found so far is Crev https://github.com/crev-dev/crev/. It's most used implementation is Cargo-crev https://github.com/crev-dev/cargo-crev, but hopefully it will become more required to use these types of tools. Certainty and metrics about how many eyes have been on a particular script, and what expertise they have would be a huge win for software.

Looks like there's an implementation of it for npm: https://github.com/crev-dev/crev

I've been willing to try it for a while for Rust projects but never committed to spend the time. Any feedback?

If you don't know the author, signatures do nothing. Anybody can sign their package with some key. Even if you could check the author's identity, that still does very little for you, unless you know them personally.

It makes a lot more sense to use cryptography to verify that releases are not malicious directly. Tools like crev [1], vouch [2], and cargo-vet [3] allow you to trust your colleagues or specific people to review packages before you install them. That way you don't have to trust their authors or package repositories at all.

That seems like a much more viable path forward than expecting package repositories to audit packages or trying to assign trust onto random developers.

[1]: https://github.com/crev-dev/crev [2]: https://github.com/vouch-dev/vouch [3]: https://github.com/mozilla/cargo-vet

I don't think it makes much sense to verify pypi authors. I mean you could verify corporations and universities and that would get you far, but most of the packages you use are maintained by random people who signed up with a random email address.

I think it makes more sense to verify individual releases. There are tools in that space like crev [1], vouch [2], and cargo-vet [3] that facilitate this, allowing you to trust your colleagues or specific people rather than the package authors. This seems like a much more viable solution to scale trust.

[1]: https://github.com/crev-dev/crev

Crev?

Alternatives to cargo-vet that has been mentioned before here on HN:

- https://github.com/crev-dev/crev

- https://github.com/vouch-dev/vouch

Anyone know of any more alternatives or similar tools already available?

I plug this every time, but here goes: https://github.com/crev-dev/crev solves this by providing code reviews, scales via a web-of-trust model, and relies on cryptographic identities. That way, you can depend on a package without having to trust its maintainers and all future versions.

I understand your worries about the number of dependencies you're "forced" to use, however, most of them tend to be doing something that's both non-trivial and useful for more than a single project. As for being able to trust all your transitive dependencies, well, that's something that the Crev project is trying to address, although I don't believe that has gained much traction yet.

It's good that having a reproducible build process is a requirement for the Gold rating, as is signed releases.

Perhaps there needs to be a Platinum level which involves storing the hash of each release in a distributed append-only log, with multiple third parties vouching that they can build the binary from the published source.

Obviously I'm thinking of something like sigstore[0] which the Arch Linux package ecosystem is being experimentally integrated with.[1] Then there's Crev for distributed code review.[2]

[0] https://docs.sigstore.dev/

[1] https://github.com/kpcyrd/pacman-bintrans

[2] https://github.com/crev-dev/crev

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.