Skip to content
Free public beta until December 4, 2026: every course is open, no card needed. After that, the first chapter of each course stays free and full access is a one-time $39 ($19 for up to 100 founding members chosen for helpful feedback). Your progress is kept. How the beta works

Recipe

Review a pull request that adds a dependency

Use when: a change adds a crate to Cargo.toml, or its Cargo.lock diff shows crates that are new to the graph

Goal: a written decision, in the pull request, on whether each new crate is trusted, based on who publishes it, what it runs and what it brings

Taught in Reviewing unsafe and dependencies · extends Check a crate before adding it

Quick recipe

  1. Confirm the name
  2. Look at who maintains it
  3. Read what runs at build time
  4. Check unsafe code and advisories
  5. Count what comes with it
  6. Record the decision
  1. 1

    Check the exact crate name against its repository and documentation, before building the branch.

    Why: a look-alike name is the cheapest attack, and building the branch would already run its build script.

  2. 2

    Read its crates.io page: owners, release history, repository activity.

    Example

    One owner, no release since 2021, and a new owner added last month: hold the change and ask why.

    Why: an abandoned or recently handed-over crate is where takeovers happen.

  3. 3

    Open its build.rs and, for a proc-macro crate, the macro's source.

    Why: that code runs on every developer machine and CI runner, before any test.

  4. 4

    Look for #![forbid(unsafe_code)], count unsafe where there is some, and search RustSec for the crate.

    Why: an unsound block in a dependency is undefined behavior in your program.

  5. 5

    Read the Cargo.lock diff and cargo tree -e normal for crates that are new to the graph, and repeat these steps for each.

    Why: every transitive crate is another publisher you trust.

  6. 6

    Write the answers in the pull request, and let cargo deny and cargo audit in CI check license and advisories.

    Why: the next reviewer, and the next update, start from what was already checked.

Common mistakes

  • Reviewing only the crate named in Cargo.toml, not the ones it brings.
  • Building the branch before checking the name and the build script.
  • Treating a high download count as a review.