Securing our Rust supply chain with cargo-vet

[Bobby Holley]

Firefox’s Rust integration makes it very easy for our engineers to pull in off-the-shelf code from crates.io rather than writing it from scratch. This is a great thing for productivity, but also increases our attack surface. Our dependency tree has steadily grown to almost four hundred third-party crates, and we have thus far lacked a mechanism to efficiently audit this code and ensure that we do so systematically.

To address this gap, we’ve been working with several industry partners on an audit system for Rust called cargo-vet. This system enforces that new third-party code has been audited, facilitates the process of performing and recording these audits, and enables the results to be shared with others in the ecosystem to reduce duplication of effort.

I’m happy to announce that as of this morning, cargo-vet is fully operational on mozilla-central. When you invoke `./mach vendor rust` to add new third-party Rust code to Firefox, cargo-vet will automatically run and inform you whether additional audits are needed, and if so, how to proceed. CI will reject any pushes for which `cargo vet` fails. In general we will require audits for all new code, though we may permit new additions to the unaudited table in exceptional circumstances (at the discretion of the Supply Chain module, as discussed below).

This is an operational win for Firefox, but it’s also just the beginning. Our aim here is to neutralize supply chain threats across the Rust ecosystem by driving widespread adoption of this tool. Each new participant automatically contributes its audits back to the commons, making it progressively less work for everyone to secure their dependencies. We’ve learned many times that the best way to move an ecosystem towards more-secure practices is to take something that was hard and make it easy, and that’s what we’re doing here.

Cargo-vet is useful today, but there are two ways we can further move the needle towards “easy”. The first is to continue to improve and refine the tool itself. We have ongoing work in this area, but welcome suggestions for making the experience better or more self-explanatory.

The second is to log more audits, since a larger corpus of existing audits make the tool more attractive to adopt. While all new third-party code must be audited, our pre-existing dependencies are largely exempted in the unaudited table. Replacing these placeholders with actual audits both improves our confidence in Firefox’s integrity and grows the public set. You can find candidates for audit with `./mach cargo vet suggest`.

Since there is no way to independently verify that an audit was performed faithfully and adequately, we must necessarily apply careful judgment as to which ones to accept under the Firefox umbrella. To manage this, we will be creating a Supply Chain module whose peers will be responsible for reviewing audit submissions and ensuring they meet our standards.  

Please reach out to me with any questions or feedback, or if you’re just generally interested in helping out. Let’s raise the bar.