Unless you have a company-wide monorepo, you'll end up needing to vendor the same dependencies on separate occasions in multiple projects. If you use vendoring

Unless you have a company-wide monorepo, you'll end up needing to vendor the same dependencies on separate occasions in multiple projects. If you use vendoring as an opportunity to review code of dependencies you're adding, you end up with multiple PRs that include the same code you've already reviewed. In some cases you may remember you've already reviewed code of a certain dependency and can skip it next time, but human memory is imprecise (have you reviewed this exact version or an older one?), and harder to share between team members to avoid duplicate effort across the team (if someone else gets a vendoring PR, how will they know what you've already reviewed before?) Tendency to "LGTM" grows with code size. If you get a massive PR that vendors fifty deps at once, it will be an intimidating wall of code, under pressure to quickly accept the PR to unblock development. A tool that shares and "recycles" prior reviews may reduce amount of code you review. It lets you review one package at a time, and split that work among team members. Depending on your threat model you may also review deps asynchronously, not blocking PRs.