Thanks for sharing.
I understand the desire to set up a remediation plan to get everything cleaned up. However, what we’ve found works best in practice is focusing on the new code.
The idea here is that enough of any given code base is touched on a regular basis that if you make sure that the code you touch in the regular course of maintenance and new features meets the standard, eventually you’ll have cleaned up the majority of your code base just in the normal course of doing business. I think at one point Google was saying that 50% of their code base changed every year. If you assume that 30% of that is the same code churning over and over and the other 20% is different each year, a New Code focus and a ‘Clean as You Code’ policy gives you a sparkling code base in just a few years.
Obviously few other projects have the same level of code churn as Google, but the principle remains the same, it just takes a little longer.
At the same time, if you’ve got blocker-level bugs and vulnerabilities out there, you clearly want to clean them up. But if I were you, I’d let the non-urgent old issues lie until I came back across them in the normal course of maintenance if I were you.