enough bouncers to keep out the riff raff--even though the risks are real and can be devastating.
Are you depressed yet? As I said, this whole area is so overwhelming that I've worked overtime to avoid it. And while denial is not usually a successful strategy for something this important, it may have served me well in this particular case. Now there are tools that combine the best of all skills needed to test code for weaknesses.
These new tools hitchhike onto existing test tools--even manual testing--and run in the background, watching everything the application does looking for security holes. They can also trace the flow of information through the application on the server side and figure out whether it offers the potential for mischief. I don't have to see it or even understand it--I just have to invoke it. These tools also provide security coverage testing metrics so I can tell when I need to expand my scope.
Even better, when such tools spot an issue they don't just announce it, they give me the exact line of code and a detailed description of why it is a problem and--get this--how to fix it. I can just paste this into a defect report to my developer and come off looking like a security genius. This technology exists; you just have to seek it out.
If you are interested in researching or learning more about new tools, such as the ones discussed in this article, or if you have any secrets on security testing you want to share, join me on the Discussion board for test automation tools.





