Two pieces of advice, both correct, in direct conflict.
Patch quickly, because exploitation of a published vulnerability often begins within days. And review what you take from third parties, because a malicious version of a package you already trust is the most effective supply chain attack there is.
Auto-merging dependency updates satisfies the first and abandons the second. Reviewing every update satisfies the second and guarantees you fail the first, because nobody has time to read forty diffs a week.
This post is how to resolve that, rather than pretending one side does not exist.
What auto-merge actually does
It takes a version published minutes ago by someone outside your organisation, and puts it into your build, your artefact and your production environment, with no human between publication and deployment.
For the overwhelming majority of updates that is fine and it is the reason the practice works. The exposure is the narrow case where the new version is malicious, and in that case your pipeline is the delivery mechanism, running at machine speed.
The historical incidents have this shape: a maintainer account is compromised or transferred, a version is published, and consumers pull it automatically. The window between publication and detection is usually hours to days, which is precisely the window auto-merge operates in.
The resolution is a delay, not a review
The insight that makes this tractable: you do not need a human to read the diff. You need the version to be a little bit old.
Most malicious package versions are detected and removed quickly, by registries, by scanners, and by the people who noticed something odd. A cooling-off period converts that collective detection into your protection, at no cost in human attention:
{
"minimumReleaseAge": "3 days",
"automerge": true,
"automergeType": "pr"
}
Three days of delay costs you almost nothing against an exploitation window measured in days, and it removes most of the risk that auto-merge introduces. It is the single highest-value setting in this whole area and it is off by default in most configurations.
Then differentiate by what the update is
Not all updates deserve the same treatment.
Patch and minor versions of packages you already depend on, after the delay, with tests passing: auto-merge. This is the bulk of the volume and the point of the automation.
Major versions: a human, because the breaking changes need a decision regardless of security.
A new dependency, or a new transitive one appearing for the first time: a human, because this is the adoption decision, and adoption is where the twenty-minute review belongs.
A change of maintainer or repository: a human, and ideally an alert. This is the signal that precedes the attack pattern above, and several tools can surface it.
Anything with an install script that did not have one before: a human, and with some suspicion.
A security patch for something actively exploited: skip the delay. The calculus inverts when the vulnerability is being used, and this is the case where the fast lane earns its complexity.
Make the tests worth trusting
Auto-merge delegates the decision to your test suite, so the suite's coverage is the control.
That is fine if it is honest about what it covers, and the check worth adding is a smoke test against the built artefact: does it start, does it serve, does a representative request work. Unit tests passing against a new dependency version tells you less than you think, because a malicious postinstall script has already run by the time any test executes.
Which is the other reason the delay matters: for install-time attacks, the damage happens on your build machine before a single test runs, so no amount of test coverage helps and only not-taking-the-version-yet does.
Keep the runners in mind
Auto-merge means untrusted code executes on your build infrastructure regularly, unattended. That makes the runner's isolation part of this decision: ephemeral runners, no standing credentials, restricted egress.
If your build machines are persistent and hold long-lived secrets, auto-merge is handing a regular opportunity to whoever compromises a package you depend on.
The concession
There is a real argument for reviewing everything, and it is not unreasonable for a small dependency tree in a high-consequence product. A team with thirty direct dependencies and a medical device can read every diff, and should.
It does not scale past that, and the failure mode of trying is worse than auto-merge: updates queue, nobody reads them, the queue becomes a backlog, and six months later you are running versions with known vulnerabilities while feeling careful. Unreviewed-and-current beats unreviewed-and-stale, which is the choice actually on offer.
The implication
The question is not whether to automate dependency updates. It is what stands between a stranger publishing a version and that version running in your production environment.
If the answer is "nothing but a test suite", add three days. It is one configuration line, it costs almost nothing against the exploitation window, and it borrows everyone else's detection for free.
