"If all that isn't signed off at the start of a system's life, it doesn't happen."
That still doesn't solve the issue with *existing* technical debt. I fully agree with you, but i think software lifecycles are extremely complex, especially when you're working with massive technical debts. So you create an inventory of software, assign priority and risk levels, make plans for their lifecycles... and then what?
You need to get budget to even execute the plans, this can take a lot of time. You're also not going to get this budget all at once, it needs to be gradual. But what do you do in the meantime? While you're building a new system, the old system may need maintenance or hardening, how do you approach this? How do you approach dependencies and interfaces, especially when the programs it interfaces with are due a replacement as well?
That is assuming you can get company-wide support for such an undertaking.
Again, i fully agree with the sentiment, but frameworks for software lifecylcle management didn't exist (or at least weren't widely used) when the most problematic of today's software was deployed. The massive complexity and cost of relieving this technical debt is a serious undertaking, and i feel like this article doesn't sufficiently address the complexities of it.
I also think there is is an easier way to address the most problematic part of this: improve your security posture. Review and test your DR protocols, assess your risks, and reduce your attack surface. Focusing on this first will allow you to partly mitigate the most direct threats, and reduce the impact associated with them. This will also serve you well into the future, it's an investment that is guaranteed to pay off.
Do the DR assessment and attack surface reduction on all software changes, use the risk assessment to prioritize your software lifecycle decisions. This is a continuous process, but you need to start in the right place.