There are tools like dependabot or greenkeeper for npm and others for other languages. Now at first glance they improve security by keeping open source dependencies up-to-date. But I am wondering, do the benefits outweigh the risk of a hostile party taking over or sneaking in a seemingly harmless commit, which will then automatically be rolled out via the updater? How quickly such exploits are found depends on the number of users and the activity of the maintainers, so I assume the best trade-off would be to instruct the update-script to wait somewhere between 1-3 months before a version update is applied, no? I am not sure if that actually is possible with most tools, but surely a feature for versions to "mature" before being applied would make sense?
2 Answers
There are many factors at play to choose between "fast" or "slow" upgrades. The main one is that unless you have an absolutely gigantic budget (time, people, expertise) you will always have imperfect information. Therefore, the rest of this answer assumes that you do not have the budget to fully review all updates, and that you must try to make a pragmatic trade-off between some often fundamentally conflicting values.
In the case you mention, probably the most relevant trade-off is between avoiding installing intentionally tampered packages and having insecure code installed on your machines while an upgrade fixing the issue is available. Based on a hand-wavy feeling of security news in the last couple of decades, it seems that intentionally tampered package versions are somewhere between 100 and 10,000 times vastly less common than package versions containing insecure code which is discovered by someone before the next version is available. Consider that there are millions of releases every day, and a tampered release comes to light seemingly every year or so. (Of course, there might be tampered releases which are never detected, but neither strategy copes with that case.) Therefore, I think it's more secure (but never completely secure) to install upgrades ASAP, and spend the effort saved by automated upgrade tools on instead mitigating risks, like compartmentalising, reducing your attack surface, and making it harder to exfiltrate data or control your computers via a botnet.
(As a side note, you also get some other nice benefits from fast upgrades:
- Packages are generally only ever tested against the latest versions of other packages. So if your project builds at all, you probably will have the best possible compatibility between the packages.
- It's an efficient way to detect brittle parts of your code. If some part keeps breaking whenever you upgrade a dependency, it might be too closely tied to details of that dependency.
- You are much more likely to get help from community projects if you can file issues or ask questions about the latest version rather than an older version. )
Changing dependency versions always involves risk. Mitigate that risk by hiding your use of the dependency from your own consumers; automated unit and integration tests; and pre-release versions to detect problems missed by your tests. (And fix those issues before final release, unlike Google.)
