A gate for new dependencies
The practical answer is to make dependency changes a separate, enforceable part of code review. A pull request that adds a package or changes its resolved version should produce a dependency diff before it can merge. Known-vulnerability checks remain useful, but they are only one input: indexed-btree did not need a known CVE to be dangerous. The gate must also show the exact package name, version, provenance when available, and the published files that will actually run.
For an existing dependency receiving a routine update, teams can apply their normal policy. A new name, a switch to a look-alike package, a change of publisher, or an unexplained executable or obfuscated file should pause the merge for an owner to investigate. That is a decision rule, not a request for every engineer to read every line of node_modules. Review the resolved artifact and its change from the previously approved version; record why the package is needed and where it will execute.
Use an automated dependency diff to make this visible on every pull request, then require the check in branch protection. GitHub’s dependency review, for example, can enforce checks for newly introduced known vulnerabilities and show package changes. It does not certify that a package without an advisory is safe. Add a separate rule for new or unexpected package identities and route those cases to a designated reviewer. The merge outcome should be explicit: approve the exact version for a defined use, investigate it, or reject it.
