Dan Sellers posted my rant on code scanning tools on his Security for Canadian Developers Blog:
--- START ---
Information managers, developers and testers commonly make the mistake of seeing code scanning tools as replacement for security QA processes. As a result they get a false sense of security about their software development lifecycle. Rather than using code scanning tools as a QA team replacement, think of code scanning tools an enforcement mechanism to help ensure that developers are following best practices and more importantly application security development policies.
Secondly tools need to be tightly integrated into a SDLC and not done as a one-off exercise. I visit a lot of customers each year to train them on developing applications securely and often ask them about their development processes and where tools fit into those processes. A common, almost consistent, response I hear is “developers run tools if they know they exist and if they remember.” Ouch. One way in which I’ve helped customers in the past is to integrated tools as a direct gate within their SDLC. Failure to complete this step affects the developer’s ability to proceed forward. As I always say, there’s a difference between what you say you do, and what you actually do.
Another common request from customers I get is for me suggest to them which is the ‘best’ tool. My response: potato. There is no best tool per se, but rather there is a best tool that meets their code scanning requirements. In order for a tool to be identified, I help my customers define those requirements first – otherwise they’ve just purchased or downloaded a tool that they have no idea whether or not is adding value or not.
Have fun scanning!
--- END ---
--
Kevin Lam, CISSP
Senior Security Technologist
Microsoft Application Consulting & Engineering (ACE) Team
