But refactoring code is hard and many customers will try to eliminate only those bugs that were identified in a security audit. That of course is a good start, but stopping there is a mistake. Code that does not use prepared statements will likely cause problems eventually. Trying to put patches on your code will cause problems too. It's like propping up that rotting floor joist instead of actually replacing it. Bottom line: even if the program isn't currently vulnerable, it is too easy for a future code change create a vulnerable condition. Prepared statements make this substantially less likely.
So to companies unwilling to use prepared statements in their code and refactor to their code I say this: use other prepared statements. Coordinate with your PR team and have them prepare statements (see what I did there?) explaining why you were compromised when you could have fixed the issues found in the code audit earlier. Basically, if you don't use prepared statements in your SQL queries expect to be exploited. Don't get caught unprepared to handle the media backlash when you lose customer information or regulated data.
