Security is a lot like quality and performance. You can’t tack them on at the end of the development cycle and expect it to be effective. All of them have to be built in along the way, in every phase of every cycle. But even though many companies claim that security is a priority, that doesn’t always translate to supporting security initiatives in the software development process. Security code reviews are often overlooked or avoided, and when development schedules fall behind security testing is often dropped to help the team "catch up". And there is almost never any money in the budget for buying new tools.

So the first step of building secure applications has to be making security part of the regular development process, but at the same time there isn't time or budget to do so. Developers have to get some quick, easy wins with security without expending a lot of time, money, or effort. Like any agile practice, continuous and rapid feedback is critical.

Static analysis tools look at source code or compiled code, looking for common errors, unused variables, style and formatting variations, and similar items. Most modern languages have a selection of open-source static analysis tools that can scan source code looking for predictable problems. SQL injection, cross-site scripting, and hard-coded passwords are common vulnerabilities that can often be detected by static code analysis. Static analysis tools can also look at the third-party libraries that the source code depends on, identifying components that have known vulnerabilities.  

With a continuous integration practice, it is easy to run some of these static code analysis frequently, beginning early in the development cycle. We can make these tools part of the developer's normal routine, heading off potential security problems before it is too late. 

Gene talks about his experiences with using open-source static analysis tools to build security into the development process without spending much time or effort, but still adding plenty of security value.