4 ms·

Unless you've been particularly careful with your build chain, your ability to actually do anything with an untouched codebase degrades over time. There may wel

Unless you've been particularly careful with your build chain, your ability to actually do anything with an untouched codebase degrades over time. There may well come a point where just getting the damn thing to build so you can release a version with whatever vulnerability patched can cost more than the remaining lifetime value of leaving it running. In that case, it's already dead, it just doesn't know it yet.

TeMPOraL 7y ago
What you say "being particularly careful with your build chain" was the status quo just few years ago, and I'd argue is still good engineering. You should pin your dependencies, and updates of everything - including build tools - should be explicit steps in the process. This should be trivial on the small (just pin versions and disable automatic updates of your build tools / package repos), and with recent proliferation of cheap VMs and containers, it should be simple over time - you should be able to pull a 5 years old image full of old software and rebuild the original binary. > There may well come a point where just getting the damn thing to build so you can release a version with whatever vulnerability patched can cost more than the remaining lifetime value of leaving it running. In that case, it's already dead, it just doesn't know it yet. Vulnerabilities aren't sins, they are things that can be fine to leave unfixed. The software isn't dead, it'll just keep running with a known exploitable issue.
- regularfry 7y ago
  > You should pin your dependencies, and updates of everything - including build tools - should be explicit steps in the process. Yes, and in the not uncommon case where part of the build environment is left unspecified, the untouched code accrues debt over time. As you say, it's possible not to take on that debt by making a significant investment up front. This isn't an argument against the debt metaphor, it's an argument for it. > Vulnerabilities aren't sins, they are things that can be fine to leave unfixed. My point doesn't change if you s/vulnerability/sufficiently serious vulnerability/.

TeMPOraL 7y ago

What you say "being particularly careful with your build chain" was the status quo just few years ago, and I'd argue is still good engineering. You should pin your dependencies, and updates of everything - including build tools - should be explicit steps in the process. This should be trivial on the small (just pin versions and disable automatic updates of your build tools / package repos), and with recent proliferation of cheap VMs and containers, it should be simple over time - you should be able to pull a 5 years old image full of old software and rebuild the original binary. > There may well come a point where just getting the damn thing to build so you can release a version with whatever vulnerability patched can cost more than the remaining lifetime value of leaving it running. In that case, it's already dead, it just doesn't know it yet. Vulnerabilities aren't sins, they are things that can be fine to leave unfixed. The software isn't dead, it'll just keep running with a known exploitable issue.

regularfry 7y ago
> You should pin your dependencies, and updates of everything - including build tools - should be explicit steps in the process. Yes, and in the not uncommon case where part of the build environment is left unspecified, the untouched code accrues debt over time. As you say, it's possible not to take on that debt by making a significant investment up front. This isn't an argument against the debt metaphor, it's an argument for it. > Vulnerabilities aren't sins, they are things that can be fine to leave unfixed. My point doesn't change if you s/vulnerability/sufficiently serious vulnerability/.