There are so many possible points of attack? How do I narrow it down
After reading about security vulnerabilities and what a malicious user could do to your software application, you are probably overwhelmed with the security testing possibilities. If you have ever worked in testing or quality assurance, this is a very familiar problem. There is always WAY too much to test, and not enough time to test everything. But there is a process to help you determine what needs to be tested and will give you guidance in priortizing the testcases. This process will include reviewing product requirements documents, product use cases, and design architecture. This will help limit what will be tested. What would a customer use, how are the software's customers going to setup and configure the product.
Unfortunately there is not a similar type of process. The black hat hacker is not going to tell you how he/she is going to attack your system. There is not any use cases. If you are the person heading up the security testing, you realize this is a very daunting task. To start with you will need to define where the risk area's are, where would a common attack vector occur, what are some possible abuse cases that you can think of.
What are the risks involved with leaving the security vulnerabilites in the code? This is a hard thing to come up with. If a security vulnerability is left in the code what could be the outcomes? How difficult is the vulnerability to find? Is there an exploit that could compromise the user, application, or system? If a vulnerability is found, how much time will your development and testing team spend to fix it? If a vulnerability is announced in public how much damage will it cause to the company? It could cause loss of customers, loss of market share.
Typically a product will have use cases, which define how a customer is going to be using various features of a software product. This will list out and define what the administration and end-user experience will be. An abuse case is the same type of use case, but it defines how a malicious user is going to be attacking a software product. Where are the potential attack vectors that the malicious user could or would use.
If you have never created an abuse case before, you have to start somewhere. A good place to start is by becoming more knowledgeable about security vulnerabilities. This site and others on the web are a great resource to discover the thought processes and potential vulnerabilities that need to be considered. Developing abuse cases is a learning experience, the more you do the better you will get at it. Don't worry if the your first shot is not that great, remember it's much better than what you had before.
If there is nothing else that can be done, at least run a vulnerability scanner. A vulnerability scanner can help you identify some of the common security vulnerabilities with an application. Click to view more information on vulnerability scanners.