Dependency Review: A Checklist for Every Upgrade

The second check is identity: is this release the thing it claims to be, from the people you expect? Supply chain attacks succeed precisely because the malicious code arrives through a trusted channel, and a compromised maintainer account is one of the documented ways attackers push malicious updates into legitimate packages according to Apiiro's overview of software supply chain attacks. If you only read the changelog, you are trusting the same account the attacker may now control.

Check three things. First, the publisher. Look at the package registry page and confirm the maintainer name and signing identity match what you saw on prior releases. Second, the provenance or signature. Many registries now attach a signed attestation that links the published artifact to a specific source repository and build pipeline; if your ecosystem offers this, verify it rather than assuming it. Third, the version and integrity hash. Your lockfile should record a content hash per package, and a restored package can be checked against it. The NuGet ecosystem, for example, records a SHA-512 content hash for each package in its lock file so a restored package can be verified against what was locked as described in this write-up on NuGet version locking.

A recent event shows why this is not theoretical. In a documented npm incident, attackers phished a package maintainer by impersonating registry support and convincing them to "update" their two-factor authentication, then used the stolen access to publish malicious versions of widely used packages, which stayed live for roughly two hours before removal per Palo Alto Networks' analysis of the npm supply chain attack. The changelogs for those releases were not the problem. The identity behind the publish was.

A practical rule: if the publisher identity, signing state, or provenance attestation changed since the last release you approved, stop and escalate. Do not merge a bump that silently changes who signs the artifact, even for a patch version. That is the one signal a human reviewer can catch that automated dependency scanners routinely miss.

Abandonware and account takeover are two sides of the same risk. An unmaintained package is a target because nobody is watching it, and a package whose ownership has quietly changed hands is a target because the new owner may not be who they claim. The NCSC names both patterns directly: maintainer account compromise and abandoned package takeover are recurring attacker techniques in open source ecosystems in its dependency guidance.

You do not need a tool for the basic version of this check. Spend two minutes on the package's repository and registry page:

• When was the last release, and when was the one before it? A sudden gap followed by a burst of releases warrants a closer look at who authored them.
• Did the maintainer list, owner, or signing key change since the last release you approved?
• Is the repository archived, or does the README point to a new home?
• Do the release notes describe changes that match the diff, or do they look rushed and generic?

A decision rule helps here. If a package you depend on has had no release in a long stretch, treat any new release as a major review regardless of its version number, and read the diff of install scripts and entry points specifically. The reason is mechanical: Node.js and Python allow scripts that execute at install time, so a malicious package can run code immediately, without human approval, through an automated pipeline per the same NCSC guidance.

The lockfile is the honest record of what your build resolves. Direct dependencies are the ones you typed; transitive dependencies are everything else, and they are the majority of what executes in production. Diffing the lockfile turns an opaque resolution step into a reviewable list.

The table below maps what each kind of lockfile change should trigger in your review.

The integrity hash row deserves emphasis. Republishing the same version with different content defeats the purpose of pinning, because your pin now points at something new. Registries generally discourage or prohibit it, but the check costs nothing: compare the hashes in the diff.

Lockfiles also make the review repeatable across machines. If your build resolves versions at restore time rather than from a locked file, the same commit can produce different binaries on different days, because a transitive package three levels down shipped a patch over the weekend as the NuGet locking article explains. Locked-mode restores fix that by either reproducing the locked versions exactly or failing, so a drift never reaches a build nobody reviewed.

Here is a compact way to surface the lockfile diff in a pull request comment, using a generic diff against the merge base:

git diff --unified=0 origin/main -- '**/package-lock.json' '**/poetry.lock' '**/packages.lock.json' \
  | grep -E '^\+|^-' \
  | grep -vE '^(\+\+\+|---)' \
  | grep -E '"(version|resolved|integrity|contentHash)"' \
  | head -n 80

Adjust the paths and key names for your ecosystem. The point is to print version, source, and hash lines in one place so the reviewer reads the actual resolution rather than scrolling a thousand-line JSON file.

A dependency bump is a change to code you did not write, running in a process you do control. The test plan should target the surface where your code touches the package, not the entire suite again for the sake of it.

A four-part plan covers most bumps:

1. Unit tests for the modules that import the package. If coverage marks those modules as untested, add at least one test that exercises the public calls you rely on before merging.
2. The integration paths that cross the package boundary: serialization, HTTP clients, parsers, date handling, anything where behavior changes are plausible.
3. A smoke test in a staging environment that mirrors production configuration, because peer dependency and runtime version checks only fail in a real install.
4. A rollback check: confirm you can revert the lockfile and redeploy without a data migration problem.

The NIST Secure Software Development Framework provides a language for placing this inside a broader process. It groups practices into four areas: prepare the organization, protect the software, produce well-secured software, and respond to vulnerabilities as summarized by NIST's SSDF project page. A dependency review that verifies publisher identity and artifact integrity sits squarely in protecting the software, and the test plan plus rollback check sits in responding to vulnerabilities. If you need a documented control for an audit, mapping your pull request checklist to those four groups makes the conversation easier; CISA publishes the same framework for reference via CISA's SSDF page.

For teams that want to measure whether this review is consistent across products rather than existing on one team's goodwill, OWASP SAMM is a maturity model built for exactly that question. It asks not whether a dependency scanner exists but whether it is configured consistently, whether exceptions are risk accepted and documented, and whether remediation times are tracked as Security Boulevard summarizes in its SAMM write-up. The OWASP SAMM project page describes the model as technology and process agnostic and risk driven per the OWASP SAMM project.

The final step is to make the review cheap for the next reviewer. Put the checklist in the template so every dependency pull request arrives with the same slots to fill.

• Changelog read for every package in the lockfile diff, direct and transitive
• Breaking changes identified and mapped to call sites in this repository
• Security fixes noted, with advisory identifiers if any
• Publisher and signing identity unchanged since the last approved release
• Provenance or signature verified where the registry provides it
• Maintainer and release activity checked; no unexplained ownership or key change
• Lockfile diff reviewed: additions, removals, version changes, hash changes
• New transitive packages checked for install scripts and recent creation date
• Unit tests covering the touched modules pass
• Integration paths crossing the package boundary pass
• Staging smoke test completed
• Rollback path confirmed

The maturity-appropriate advice is to start with the rows you can automate and reserve human attention for the rest. Scanners can flag known vulnerabilities and list changed packages; nobody's scanner tells you whether a maintainer's signing key quietly changed. That judgment call is where a reviewer earns their keep.

If your team is building shared tooling around this, a shared credit pool and a private skill library with per-person keys makes it easier to keep review automation consistent across a group rather than one person's laptop see Quanta for Teams. Keep the checklist versioned next to the template so changes to the process are themselves reviewable.