> The real judgement being made is money and resources.
Unnecessary changes and the overall fragility of "modern" software takes money and other resources away from dealing with actual security issues.
There's no reason why things like a library of geospatial calculations (distance between two lat/lon pairs, etc) should need constant maintenance. They could be written once and then used for decades.
That's the biggest problem with the "old" ways of doing things, you simply don't know where you're vulnerable. Refusing to allocate resources to revisit old code, only to add new features is a recipe for disaster.
Upgrading to Python 3 does not fix this alone, but ignoring it, and the other dependencies that you might have, and that old Redhat 7.1 box running Linux 2.4 that's all probably fine, it's just card processing, right? Nothing else has changed.
The "modern" ethos is testing everything all the time. Yeah, it's a shed-load of extra stuff if it's new to your project, but it's only codifying things that you should be doing anyway, even if only seasonally.
Yes, there is occasional fragility, but that's more than offset —at least in my network-facing world— by the constant stream of security fixes across my stack.
Unnecessary changes and the overall fragility of "modern" software takes money and other resources away from dealing with actual security issues.
There's no reason why things like a library of geospatial calculations (distance between two lat/lon pairs, etc) should need constant maintenance. They could be written once and then used for decades.