Problem solve Get help with specific problems with your technologies, process and projects.

How to implement automated security testing in the continuous integration cycle

According to expert John Overbaugh, testers can implement automated testing to catch code security issues, and to conduct unit, acceptance and functional testing in an Agile environment. Here he explains the different types of tests and how to automate testing in a continuous integration build.

Can security tests be automated so they are included in the tests that are executed as part of a continuous integration build?

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.

Dig Deeper on Topics Archive

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

Thank you so much for this article,
well my end of studies project is about implementing security automated tests within a continuous integration solution so that's whay i hope you help me :)
I have to explore the different aspects of application security, tools application security testing and then to integrate them after being automated .
As you said sir thaere are two kinds of tests to be employed:
the security of an application as it is executed (for this i have choosen BDD-Security)
the ‘code security’ test : Ididn't know how t deal with that ?
I'll be satisfied to receive your comments and thank's
By the way , I'm working with SVN, Redmine and Jenkins. and i have to use tools which can be integrated with Jenkins
Sadly, the article is correct that code security is often overlooked in the CI/CD pipeline. I suspect that many people are just unaware of the proliferation of security tools that can be inserted into the pipeline, such as Gauntlt.
Suggested correction.
Automated testing checking to may catch some known code security issues.
Same applies to unit, acceptance and functional aspects.