book/src/motivation.md - toolchain/cargo-vet - Git at Google

 # Motivation

 The discussion below covers the high-level motivation for building this system. If
 you're just interested in how it works, you can skip to the next section.

 ### Security Risks of Third-Party Code
 Low-friction reuse of third-party components — via systems like crates.io or npm — is
 an essential element of modern software development. Unfortunately, it also
 widens the set of actors who can introduce a security vulnerability into the final
 product.

 These defects can be honest mistakes, or intentional supply-chain attacks. They
 can exist in the initial version, or be introduced later as an update. They can
 be introduced by the original author, or by a new maintainer
 who acquires control over the release of subsequent versions.
 Taken together, these avenues constitute a demonstrated and growing
 risk to software security.

 Ideally, the composition model would include technical guarantees to isolate
 components from each other and prevent a defect in one component from compromising
 the security of the entire program (e.g. [WebAssembly nanoprocesses](https://bytecodealliance.org/articles/announcing-the-bytecode-alliance)).
 However, that is often not a realistic solution for many projects today. In the absence
 of technical guarantees, the responsibility for ensuring software integrity falls to
 humans. But reviewing every line of third-party code can be very time-consuming and
 difficult, and undermines the original premise of low-friction code reuse. Practically
 speaking, it often just doesn't happen — even at large well-resourced companies.

 ### Tackling This in Rust
 There are two properties of Rust that make this problem easier to solve.

 First, it's relatively easy to audit Rust code. Unlike C/C++, Rust code is
 memory-safe by default, and unlike JavaScript, there is no highly-dynamic shared
 global environment. This means that you can often reason at a high level about
 the range of a module's potential behavior without carefully studying all of its
 internal invariants. For example, a complicated string parser with a narrow
 interface, no unsafe code, and no powerful imports has limited means to
 compromise the rest of the program. This also makes it easier to conclude that a
 new version is safe based on a diff from a prior trusted version.

 Second, nearly everyone in the Rust ecosystem relies on the same set of basic tooling
 — Cargo and crates.io — to import and manage third-party components, and there is high
 overlap in the dependency sets. For example, at the time of writing,
 [Firefox](https://hg.mozilla.org/mozilla-central/file/add572d6012047244d022436e0b5c578b3dd7cf7/Cargo.lock),
 [wasmtime](https://github.com/bytecodealliance/wasmtime/blob/49c2b1e60a87623796046176500bed6afa956d2f/Cargo.lock),
 and [the Rust compiler](https://github.com/rust-lang/rust/blob/532d3cda90b8a729cd982548649d32803d265052/Cargo.lock)
 specified 406, 310, and 357 crates.io dependencies respectively[^1]. Ignoring
 version, each project shares about half of its dependencies with at least one of
 the other two projects, and 107 dependencies are common across all three.

 This creates opportunities to share the analysis burden in an systematic way. If you're able to
 discover that a trusted party has already audited the exact crate release you're using,
 you can gain quite a bit of confidence in its integrity with no additional effort. If
 that party has audited a different version, you could consider either switching to it, or
 merely auditing the diff between the two. Not every organization
 and project share the same level of risk tolerance, but there is a lot of common
 ground, and substantial room for improvement beyond no sharing at all.


 ## Footnotes

 [^1]: The following command string computes the names of the crates.io packages
   specified in `Cargo.lock`. Note the filtering for path and git dependencies,
   along with removing duplicates due to different versions of the same crate:

 ```
 grep -e "name = " -e "source = \"registry" Cargo.lock | awk '/source =/ { print prv_line; next } { prv_line = $0 }' | sort -u
 ```
	# Motivation

	The discussion below covers the high-level motivation for building this system. If
	you're just interested in how it works, you can skip to the next section.

	### Security Risks of Third-Party Code
	Low-friction reuse of third-party components — via systems like crates.io or npm — is
	an essential element of modern software development. Unfortunately, it also
	widens the set of actors who can introduce a security vulnerability into the final
	product.

	These defects can be honest mistakes, or intentional supply-chain attacks. They
	can exist in the initial version, or be introduced later as an update. They can
	be introduced by the original author, or by a new maintainer
	who acquires control over the release of subsequent versions.
	Taken together, these avenues constitute a demonstrated and growing
	risk to software security.

	Ideally, the composition model would include technical guarantees to isolate
	components from each other and prevent a defect in one component from compromising
	the security of the entire program (e.g. [WebAssembly nanoprocesses](https://bytecodealliance.org/articles/announcing-the-bytecode-alliance)).
	However, that is often not a realistic solution for many projects today. In the absence
	of technical guarantees, the responsibility for ensuring software integrity falls to
	humans. But reviewing every line of third-party code can be very time-consuming and
	difficult, and undermines the original premise of low-friction code reuse. Practically
	speaking, it often just doesn't happen — even at large well-resourced companies.

	### Tackling This in Rust
	There are two properties of Rust that make this problem easier to solve.

	First, it's relatively easy to audit Rust code. Unlike C/C++, Rust code is
	memory-safe by default, and unlike JavaScript, there is no highly-dynamic shared
	global environment. This means that you can often reason at a high level about
	the range of a module's potential behavior without carefully studying all of its
	internal invariants. For example, a complicated string parser with a narrow
	interface, no unsafe code, and no powerful imports has limited means to
	compromise the rest of the program. This also makes it easier to conclude that a
	new version is safe based on a diff from a prior trusted version.

	Second, nearly everyone in the Rust ecosystem relies on the same set of basic tooling
	— Cargo and crates.io — to import and manage third-party components, and there is high
	overlap in the dependency sets. For example, at the time of writing,
	[Firefox](https://hg.mozilla.org/mozilla-central/file/add572d6012047244d022436e0b5c578b3dd7cf7/Cargo.lock),
	[wasmtime](https://github.com/bytecodealliance/wasmtime/blob/49c2b1e60a87623796046176500bed6afa956d2f/Cargo.lock),
	and [the Rust compiler](https://github.com/rust-lang/rust/blob/532d3cda90b8a729cd982548649d32803d265052/Cargo.lock)
	specified 406, 310, and 357 crates.io dependencies respectively[^1]. Ignoring
	version, each project shares about half of its dependencies with at least one of
	the other two projects, and 107 dependencies are common across all three.

	This creates opportunities to share the analysis burden in an systematic way. If you're able to
	discover that a trusted party has already audited the exact crate release you're using,
	you can gain quite a bit of confidence in its integrity with no additional effort. If
	that party has audited a different version, you could consider either switching to it, or
	merely auditing the diff between the two. Not every organization
	and project share the same level of risk tolerance, but there is a lot of common
	ground, and substantial room for improvement beyond no sharing at all.


	## Footnotes

	[^1]: The following command string computes the names of the crates.io packages
	specified in `Cargo.lock`. Note the filtering for path and git dependencies,
	along with removing duplicates due to different versions of the same crate:

	```
	grep -e "name = " -e "source = \"registry" Cargo.lock \| awk '/source =/ { print prv_line; next } { prv_line = $0 }' \| sort -u
	```