I understand that not updating your dependencies when new patches are released reduces the chance of accidentally installing malware, but aren’t patches regularly released in order to improve security? Wouldn’t it generally be considered unwise to not install new patches?
Nobody has time to read source code, but there are many tools and services that will tell you brief summaries of release notes. Npm Audit lists security vulnerabilities in your package versions for example.
I do adopt the strategy of not updating unless required, as updates are not only an attack vector, but also an extremely common source of bugs that'd I'd prefer to avoid.
But importantly I stay in the loop about what exploits I'm vulnerable to. Packages are popping up with vulnerabilities constantly, but if it's a ReDoS vulnerability in part of the package I definitely don't use or pass user input to? I'm happy to leave that alone with a notice. If it's something I'm worried another package might use unsafely, with knowledge of the vulnerability I can decide how important it is, and if I need to update immediately, or if I can (preferably) wait some time for the patch to cook in the wild.
That is the important thing to remember about security in this context: it is an active, continuous, process. It's something that needs to be tuned to the risk tolerance and risk appetite of your organisation, rather than a blanket "never update" or "always update" - for a well-formed security stance, one needs more information than that.
This isn't trivial to organise though since semver by it's self doesn't denote when a patch is security related or not. Of course, you can always review the release notes but this is time consuming, and doesn't scale well when a product grows either in size of code base or community support.
This is where there's a fairly natural place for SAST (E.g., Semgrep, Snyk (many more but these are the two I've used the most, in no particular order)), and supply chain scans fall in place, but they're prohibitively expensive.
There is a lot of open source tooling out there that can achieve the same too of course.
I've found there's a considerable linear climb with overheads/TOIL and the larger the number of open source tools you commit to create a security baseline. Unfortunately, this realistically means most companies where time is scarcer than money, means more money shifts into closed source products like those I listed, rather than those ran by open source products/companies.
It's frustrating that a potential availability issue often gets the same (high) rating as a integrity/confidentiality issue