Can security tests be automated so they are included in the tests that are executed as part of a continuous integration build?
Requires Free Membership to View
When you register, you'll receive targeted emails designed to keep you informed of the most relevant information on Agile development, application security, testing & QA, software requirements, and more.
Hannah Smalltree, Editorial Director
One of the most important aspects of security is code security -- ensuring that, as requirements are implemented, code is written in a secure manner. As an Agile evangelist, I’m very enthusiastic about real-time validation. In Agile environments and other environments where continuous integration is leveraged, automated security tests can be leveraged to catch code security issues as soon as they are introduced.
When considering a CI security strategy, keep in mind there are two kinds of tests to be employed. First, teams will want to test the ‘execution security’ (the security of an application as it is executed). These are the more traditional tests engineers generally think of. They lend themselves well to automated unit, acceptance, and functional tests. They test activities like authentication, authorization, password protection. Some tests might verify that sensitive data is only transmitted over secure channels or that cookies are secured, etc. As teams develop and implement their build test strategies, it will become obvious what types of security tests are best leveraged in this environment. Keep in mind, not all testing can be automated in this phase. For instance, penetration testing is best performed when an application, or at least a major feature and its sub-components and dependencies are completed. Unit testing and automated functional testing of new code are best suited to testing functional elements of an application rather than broader features. For that matter, penetration testing is a heuristic activity where information learned in one test is used to influence or even design subsequent tests. Automated check-in tests simply do not lend themselves to heuristic testing techniques.
A second kind of test, which is often overlooked at this stage, is the ‘code security’ test. This activity emphasizes adherence to best practices and internal coding requirements. Leveraging tools like Microsoft’s StyleCop or FXCop, or other commercial equivalents, helps teams identify best practice violations which may result in security vulnerabilities. This is also the stage where security static code analysis tools can be implemented. The most effective uses of the ‘code security’ test is to validate code security prior to or just after check-in. That way, code security flaws can be discovered almost immediately, well before additional features and functionality have been built on top of poorly-designed code. This can dramatically reduce the cost of finding and fixing security-related flaws, and speed up time to market in today’s compressed lifecycles.
Teams that understand appropriate security validation, and implement it correctly in the continuous integration cycle, will contribute significantly to the overall security of their application. They will receive immediate feedback on many aspects of the security of their project, and they will likely find obvious security vulnerabilities early in the project.
For a comprehensive resource on continuous integration, see Continuous integration: Achieving speed and quality in release management.
This was first published in September 2011