“The tools we use are maintained by a reputable supplier”
Ah but human accidents and sabotage happen so, well, it’s job security for you guys. Multiple cats chasing multiple mice, huh?
What percentage of security breaches begin with human error?
I don't have hard numbers, but practical experience deploying website updates that failed was most often attributable to a failure to get some software settings correct on the deployment. At the coding level, failure to check return values, failure to initialize variables before using them, using memory that has been freed, failing to free memory after use, reading/writing off the end of an array, returning a reference to a local variable. Little stuff. The class of tools emulating the early "lint" for C is helpful for finding problems in source code. At runtime, tools like purify or valgrind expose memory misuse, but only if the code is executed. Code coverage analyzers track lines of code actually executed so your test cases can be improved to run all of the code and help purify or valgrind report a problem. When it's all "done", source code analysis with tools such as fortify driven with known defect databases look for the odd stuff.
Modern software depends on a lot of reuse of other people's work. A defect widely shared gets reported as a Common Vulnerability Enumeration (CVE) with a description of how to replicate the defect, how to exploit it and what release of the commonly shared library has been posted with a fix for the problem.
Between security and regular development, there is plenty of work in the queue.