cargo-vet VS LavaMoat

For supply chain security, you might be interested in cargo-vet[0], a tool for coordinating and requiring manual reviews of open source dependencies. Both Mozilla and Google[1] have started publishing their audits.toml files, which are a machine-readable file describing what source code reviews they have performed.

[0] https://github.com/mozilla/cargo-vet

[1] https://opensource.googleblog.com/2023/05/open-sourcing-our-...

there is also cargo-vet for manual auditing of the source code of the crates, which is not something that can be done automatically. Quite a few companies and orgs use it now like Mozilla, Google, Bytecode Alliance, us (Embark Studios), ISRG, zcash etc. And believe its usage will expand significantly going forward with corporate users and security sensitive projects/orgs.

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

The other approach is https://github.com/mozilla/cargo-vet

cargo crev and cargo vet for reviewing dependencies and using reviewed versions

Since the audits are designed to be used at a per project level and contributed directly into the VCS repo (allowing you to using git signing for example) I don't quite understand what additional off-line cryptographic signatures are required here (considering that Cargo's lockfiles already contain a hash of the crate which would prevent the project from getting an altered version of a crate accidentally and that SHA validation is being considered as part of vet as well https://github.com/mozilla/cargo-vet/issues/116).

Just yesterday I watched a talk [0] at WarsawJS about LavaMoat [1], a set of tools to protect against malicious behaviour from npm dependencies. Guess it’s time to look into it deeper.

[0]: https://naugtur.pl/pres3/lava/2023end.html

[1]: https://github.com/LavaMoat/LavaMoat

You are basically talking about Lavamoat. It provides tooling and policies for SES, which aims to make it into standards.

https://github.com/LavaMoat/LavaMoat

Enter: lavamoat. https://github.com/LavaMoat/LavaMoat

You should check out Lavamoat: https://github.com/LavaMoat/LavaMoat

It attempts to do what you're essentially describing. It was built by the MetaMask team, where supply chain attacks are an obviously huge risk.

I've spent some time trying to get it working in an app, but haven't been able to get it all the way working. It's still pretty beta and not well documented.

And it is happening right now. Github is opening the GitHub Advisory Database to community submissions. Awesome community NodeSecure builds cool things like scanner and js-x-ray. There are also lockfile-lint, LavaMoat, Jfrog-npm-tools (and I am sure there is more).

There is a proposal to add OCAPs on a language level in TC39[0]. There is already a drop-in implementation which already works in both Nodejs and browsers[1].

As a developer who wants to sandbox your own (recursive) dependencies, this is made accessible today in Lavamoat[2]. Basically a package or app can provide a policy manifest specifying which capabilities (e.g. network or filesystem access) should be granted for each dependency. Also comes with a tool that will auto-generate a starting point from your existing dependency tree.

IMO this is the future. Currently it does come with a performance penalty but hopefully this idea will catch on and make it into runtime implementations.

Lavamoat is still marked as "preprod" on npm but talking to the author it's a matter of days or weeks until the first stable release.

[0]: https://news.ycombinator.com/item?id=30703817

[1]: https://github.com/endojs/endo/tree/master/packages/ses

[2]: https://github.com/LavaMoat/LavaMoat