Why You Shouldn't Auto-Increment Your Dependencies
Recently I saw this tweet which advocates for something I consider a dangerous development practice; Not fixing your builds to a version of its dependencies.
There are three main reasons why I consider this dangerous;
- Supply chain attacks (e.g. 5 in https://dni.gov/files/NCSC/documents/supplychain/Software_Supply_Chain_Attacks.pdf)
- It breaks the Reproducible Builds principle (Tag X won’t build the code shipped to users after any new library release)
- It could cause unexpected build breakages unrelated to code changes.
The most serious but least common is the first. Most developers, at some point, test on a device with VPN/CorpNet access, and so any malicious code would have access to a companies internal LAN.
Most companies use perimeter based network security, which VPN/CorpNet access circumvents.
My personal preference, when there’s time, is to check the library binaries into the repository, which Git LFS makes a lot easier. That way you isolate yourself from supply chain attacks, and Dev/CI builds aren’t subject to all the fun of dependency downloading issues.
It also means you have an accurate copy of what you shipped. When you ship an app you are responsible for the code in it, so you aren’t subject to third-party repositories pulling releases which your builds used.
So, to me, any benefit from auto-incrementing your dependency versions is far outweighed by the problems it can cause.