Most modern applications are mostly code the team did not write. Every package in your manifest is a decision to ship someone else's code, with someone else's bugs and someone else's maintainers. A good secure code review treats a new or updated dependency as a change that deserves its own scrutiny, not as a one-line edit to a lockfile.

Why do dependencies belong in code review?

Two recent events show the range of risk. Log4Shell (CVE-2021-44228), disclosed in December 2021, was a flaw in a widely used logging library that left countless applications exposed, many of them without their owners knowing the library was present. In March 2024, a backdoor was found in the upstream releases of the xz compression library (CVE-2024-3094, affecting versions 5.6.0 and 5.6.1), planted by a maintainer account over a period of time. One was an accidental vulnerability, the other a deliberate compromise. Both arrived through code that teams trusted by default.

What should you ask when a pull request adds a package?

  • Do we need it? A package pulled in for one small function adds its whole dependency tree. Sometimes ten lines of your own code is the safer choice.
  • Is the name right? Typosquatting and dependency confusion attacks rely on a reviewer not noticing a name that is one character off, or an internal package name that also exists on a public registry.
  • Is it maintained? Check recent releases, open security issues and whether a single person maintains it.
  • What does it pull in? Look at the transitive dependencies, not just the one you asked for.
  • What does it do at install time? Some ecosystems allow install scripts that run code on developer machines and build servers.

What should you check on version updates?

Read the changelog. Be suspicious of a large jump, an unexpected change of maintainer, or a new release with no explanation. Confirm that the lockfile changed only in the ways the pull request says it did. A lockfile diff that touches dozens of unrelated packages deserves a question.

Which controls make this easier?

  • Lockfiles and pinned versions so builds are reproducible and changes are visible in review.
  • Automated vulnerability alerts from your repository host or a software composition analysis tool, so known flaws are flagged without waiting for a reviewer to notice.
  • A software bill of materials (SBOM) so you can answer "are we affected?" in minutes the next time a library makes the news.
  • A private registry or proxy to control where packages come from.

Tools find known vulnerabilities. They do not tell you whether a package is a good idea. That part is still a human decision, and a secure code review is the right moment to make it.

Related reading: Code Review for Authentication and Authorization Flaws.

Key takeaways

  • Dependencies are code you ship. Review changes to them like code you wrote.
  • Ask whether a package is needed, correctly named, maintained and safe to install.
  • Use lockfiles, automated alerts and an SBOM so reviewers see changes and you can respond quickly to disclosures.