rvlsoft - Fotolia

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

Code security: Can a continuous delivery model be secured?

Continuous code delivery is critical in certain scenarios, but it's not always the most secure approach. Michael Cobb explains how to secure code in a continuous delivery model.

Developers in my organization push code into production dozens of times daily because of the organization's continuous...

delivery (CD) model. Though the development cycle is short, I recognize the need for security gateways. Which gateways or security measures would be best to use in such an environment? Or, should we move away from a CD model?

A continuous delivery model to software application development and delivery means development cycles are short; new code is released as soon as it's ready, rather than being delayed and bundled with other changes. From a security development viewpoint, the main problem with many real-life CD implementations is they solely focus on testing and releasing new features and functionality as fast as possible, and pay scant attention to security. User feedback is fed into the next release, but this, too, is heavily biased towards usability and functionality, rather than security. However, there's no reason why a CD model should be abandoned due to concerns about security as long as security is built into the overall process.

The core idea of a continuous delivery model -- creating a baseline of automated unit and integration testing to eliminate defects as they occur -- lends itself well to secure development practices as long as the development and security teams work together. Continuous delivery implemented with sound security-acceptance processes can improve the security and resiliency of software, as it offers an opportunity to integrate continuous security checks at key stages of the software development and deployment process. Traditional software development introduces large numbers of changes to an application's code all at once. This makes it harder to review; when a test fails, it's not necessarily obvious which particular code change caused the problem. The constant code evaluation in the CD model makes finding problems easier, plus the code is still fresh in the developer's head. It's important, of course, to establish secure coding rules that ban the use of dangerous code constructs and functions -- only approved third-party libraries and components should be used, and comprehensive error and exception handling mandated for all critical functions.

As soon as new code is checked in, it should be subjected to automated code security reviews to check that known weaknesses have not been introduced, and should flag code in need of a manual review. Testing for known weaknesses is well-suited for automation, but it's important to add tests based on identified scenarios and abuse cases that capture non-normal behavior. These tests can mostly be automated using acceptance-testing browser automation tools, such as Selenium. This sequence of tests is essentially the same as automated acceptance tests, but they are targeted at verifying that security features -- such as log in and log out -- work as expected, and unexpected behavior doesn't result in any unexpected outcomes. The key is to create tests that are based on the application's attack surface, as detailed in the threat model. Consider a hardening sprint to focus on fixing problems found during security tests, but the security team should have the ability to block delivery if test results indicate the presence of unacceptable risk.

Ask the Expert:
Have a question about application security? Send it via email today. (All questions are anonymous.)

Next Steps

Does continuous delivery equal continuous improvement? Learn more here

Explore how to integrate security into the software development lifecycle

How to prepare for continous delivery

This was last published in November 2015

Dig Deeper on Secure software development