Testing and static analysis is a very bad way to find security vulnerabilities, and in fact it is a last resort method if you did not think about security throughout the design and implementation process.
The problem is that now you are trying to list all the ways in which your application can fail and refuse them (by fixing it), rather than trying to indicate what your application should do and prevent everything that’s wrong (defensive programming). Since your application probably has endless ways to go wrong and there are only a few things that it should do, you should take a “deny by default” approach and allow only good things.
In other words, it’s easier and more efficient to create controls to prevent entire classes of typical vulnerabilities (for example, see OWASP, as indicated in other answers) no matter how they may arise, than to look for what specific disgust is some version of your code. You should try to prove that there is good control (which can be done), and not the absence of bad things (which cannot).
If you ask someone to review your design and security requirements (what exactly are you trying to protect against?), With full access to the code and all the details, this will be more valuable than any black box test. Because if your design is wrong, it doesn't matter how well you implemented it.