Explicar e possivelmente demonstrar a falha em
Quando é a sua palavra contra a dele, tudo o que você diz pode ser apenas ar quente, tanto quanto eles estão preocupados. Depois de mostrar a eles como o aplicativo pode ser abusado por meio de injeção de SQL, de repente você é uma pessoa confiável. Você vai precisar de credibilidade para renegociar. E isso é o suficiente para mudar o jogo para você.
Seja caridoso com relação ao seu antecessor
Isso não significa fingir que os erros não estão lá, mas se você se deparar com condescendência, perderá credibilidade. Não diga uma palavra sobre o programador, exceto, talvez, para lhe dar o benefício da dúvida. Concentre-se no código, não no codificador. Fazê-los sentir como se você fosse o "cara bom" lhe dará muito mais margem de manobra nas negociações. E "mocinhos" nunca dizem coisas ruins. Ao explicar erros de segurança existentes (como vulnerabilidades de injeção de SQL) ao cliente, prefiro dizer algo assim:
Web application security is a rapidly-evolving field. Many of the development tools and techniques that people learn even today evolved before most of these exploits were well-understood. In order to stay ahead of security developments, you have to follow the field very closely and occasionally even change your whole development style. Most programmers don't do this.
Lá vamos nós. Nem uma palavra de mal falada sobre o desenvolvedor; ele é apenas "a maioria dos programadores", o que significa que ele está em boa companhia. E agora você demonstrou que não são "a maioria dos programadores", o que lhe dá um pouco mais de credibilidade e talvez um motivo para eles pagarem mais dinheiro.
Negociar um novo acordo
Uma vez que o cliente entenda que seu aplicativo está aberto a abusos do público, ele vai querer que ele seja consertado. Você é provavelmente a pessoa que ele vai pedir para consertá-lo. Você pode ou não querer esse emprego, então pense bem antes de falar com eles.
No mínimo, você quer mais tempo para terminar o trabalho que eles já lhe deram. Você configurou o suficiente desprevenido com o material de vulnerabilidade que provavelmente não vai lhe dar a estimativa original. Mas certifique-se de que o cliente saiba o que você é e não vai consertar como parte desse arranjo.
Normalmente, o desenvolvedor (você) prefere refazer tudo do zero. E em casos como esse, isso pode até ser uma opção. Mas, mesmo assim, o cliente vai querer algo que possa manter seus negócios funcionando até que o novo aplicativo seja criado. Isso significa que mesmo que você esteja começando de novo, provavelmente ainda terá que atualizar um pouco o aplicativo antigo.