There is likely never going to be an approach that yields 0 vulnerabilities, so instead we should be more focused on minimizing the risk as much as possible. Th

There is likely never going to be an approach that yields 0 vulnerabilities, so instead we should be more focused on minimizing the risk as much as possible. There is a middle ground and nuance between never update and always update, just as there is a nuance in how much and what you duck tape together. Not sure if it's the best, but my current approach is to target major revisions/versions with ABI/API compatibility as viable candidates, and update always, but at a lagged rate, ideally allowing enough time to pass for vulnerabilities to be surfaced in those versions. Log4j is a tough case due to how far back it goes version-wise, but you simply can't win them all. Another important way to minimize risk is to have a strong ability to provide a corrective action. If replacing the version or the entire dependency of a library you use takes a significant engineering effort, then you are arguably at a higher risk due to that than you are in your decision to never vs. always update.