Making Moves: How to Successfully Transition to DevSecOps

As we look toward the future, it is becoming critical that development organizations are not only agile and flexible but – just as important – secure. In turn, security and development need to work together more closely than ever before. When security and development are in unison, organizations can produce higher quality code quicker and more securely while reducing costs and conforming to regulations. Most companies realize that DevSecOps is the true nirvana, but they are not sure how to get there.

For starters, a successful transition to DevSecOps means that security and development teams need to reevaluate their roles. Ensuring the stability and security of software is no longer just the security team’s responsibility, it now includes developers. Developers should be testing, and security professionals should now be governing the testing. This culture shift can be a real challenge given that most security professionals have never worked alongside development teams and are not familiar with their processes, priorities, or tools. But once security and development teams are able to successfully work hand in hand, DevSecOps is achievable.  

With this culture shift in mind, how do we formulate an AppSec strategy that transforms DevOps into DevSecOps? In its new report, Building an Enterprise DevSecOps Program, analyst firm Securosis provides an outline of the security tools and techniques needed at each stage in the software development lifecycle:

Define and Architect Phase

Reference security architectures: Reference security architectures – or service provider guidelines for cloud services – to understand the rules and policies that dictate how applications operate and communicate. Once you are familiar with the security architecture, you should work with development to come up with operational standards. Some important operational standards to consider include minimal testing security requirements, time frames for fixing issues, and when to break a build.  

Security requirements: Decide which security tests should be run prior to deployment. Are you going to test for OWASP Top Ten vulnerabilities?

Monitoring and metrics: Consider what metrics you need to improve releases or problematic code or to determine what is working well. You should also think about what data you want to collect and build it into your CI/CD and production environments to measure how your scripts and tests perform.

Design Phase

Security design principles: Follow security design and operational principles because they offer valuable security improvement recommendations. Following these principles can be time consuming, but IT and development typically help because it benefits them as well.

Secure the deployment pipeline: Ensure that development and test environments are secure. Set up strict access controls for CI/CD pipelines and additional monitoring for scripts running continuously in the background.

Threat modeling: Teach the development team about common threat types and help them plan out tests to address attacks. If your security team is not able to address threat monitoring internally, you can consider hiring a consultant.

Develop Phase

Automate: Automating security testing at this phase is key.

Secure code repositories: Make it easy for developers to get secure and internally approved open source libraries. How? Consider keeping local copies of approved, easy-to-access libraries, and use a combination of composition analysis tools and scripts to make sure developers are using the approved versions.

Security in the scrum: Set up your "security champions" program, training selected members of the development teams in security basics, to help with these security tasks.

Test-driven development: Consider incorporating security into test-driven development, where tests are constructed along with code.  

Interactive Application Security Testing (IAST): Analyze your application’s code using IAST. The IAST scanner aims to find security vulnerabilities before you launch code into production.

Test Phase

Design for failure: The thought process behind this concept is, if there is a flaw with your application, it is better that you break it than an attacker.

Parallelize security testing: Address security tests that are slowing down your deployments by running multiple tests in parallel. Reconfiguring test environments for efficiency helps with Continuous Integration.

Pre-Release Phase

Elasticity: Make sure your security testing leverages on-demand elastic cloud services to speed up security testing.

Test data management: Prevent unnecessary data breaches by locking down production environments so quality assurance and development personnel cannot exfiltrate regulated data or bypass your security controls. Consider using tools like data masking or tokenization, which deliver test data derived from production data but without the sensitive information.

Deploy Phase

Manual vs. automated deployment: Use automation whenever possible. It is okay to use some manual processes, but it is important to remember that the more you automate, the more capacity the team will have to test and monitor. 

Deployment and rollback: Start by using smoke tests to make sure that the test code that worked in pre-deployment still works in deployment. Then, if you need to augment deployment, use one of these three tricks. The first is Blue-Green or Red-Black deployment. This is where old and new code run simultaneously on their own set of servers. The rollout is simple and, if errors are uncovered, the load balancers are pointed back to the older code. The second is canary testing. In canary testing, a small subset of individual sessions is directed toward the new code. If erors are encountered and the canary dies, the new code is retired until the issue is fixed. Lastly, feature tagging enables and disables new code elements. If event errors are found in a new section of code, you can toggle off the feature until it is fixed.

Production security tests: Note that it is common for applications to continue to function even when security controls fail. Consider employing penetration testers to examine the application at runtime for flaws.

Learn More

By embracing the role changes brought about by DevOps and working with developers to add security tools and techniques into the software delivery lifecycle, you can successfully transition to DevSecOps.

Get more detailed information on building out a DevSecOps program in the Securosis report, Building an Enterprise DevSecOps Program.