The goal of DevOps is to engage the development and operations teams simultaneously throughout the software development...
lifecycle. That means both during the code's initial development and whenever developers modify or update it. No matter what the stage, it's essential to maintain security and compliance by building them in at the outset. Here's the good news: There's not necessarily a tradeoff between security and agility. It's possible to develop code that's even more secure than before the move to DevOps if you approach DevOps and security properly.
Initial steps to DevOps and security
The first step to marrying DevOps and security is to be sure you understand the security controls that are currently in place and the ones that are desired. A good starting point is to meet with your enterprise risk management team; if you don't have one, or need additional background, a good framework can be found through the not-for-profit security organization ISACA, which recommends a lineup of key controls for software development that include the following:
Automated software scanning. Developers should deploy an application code scanning tool and also examine log files or other evidence to prove scans are taking place.
Automated vulnerability scanning. In addition to code scanning, ISACA also recommends performing automated vulnerability scanning.
Developer application security training. Auditors should validate that developers received adequate training and demonstrate the use of that training in their practices. That is, developers need to know which tests are appropriate and validate that the tests have been run.
Software dependency management. Tracking dependencies that internally developed code has on software libraries is a critical component of crafting clean, modular code -- and minimizing dependencies makes code cleaner and, generally speaking, easier to secure.
Access and activity logging. Developers should deploy tools that automate developer activity logins so that there's a timestamped trail of changes made by each developer. It's also wise to integrate this with business feature tracking -- so it's clear when and why certain business features were modified.
Documented policies and procedures. ISACA directs auditors to review policies to ensure that they cover all aspects of the production release process.
Application performance management. The ISACA recommendation here is to collect metrics to manage performance and address them when they occur.
Asset management and inventory. Unsurprisingly, an automated tool should maintain a record of assets and applications.
Separation of duties. All code must be peer reviewed, and approvers cannot be the individuals who developed that code. Nor can change managers be the individuals who implemented the change.
The second step, after determining which controls to apply, is to assess the security tools that are currently in place and compare that to what's needed. Good tools for vulnerability assessment include Fortify, SonarQube and Nexus IQ. For automated DevOps and security testing, there's a large portfolio of product types, including static application security testing, dynamic application security testing, interactive application security testing and runtime application security testing. Vendors include Contrast Security, Fortify, Veracode and Waratek. And for activity logging, both Jira and Cucumber can track changes. Many of the other controls can be met by a combination of tools and enhanced processes.
Step three? Automation
The third step to DevOps and security is to see if these automated tools enable any degree of process streamlining. One area in which they likely will is separation of duties. A traditional approach might require four people to record a change: One person creates the change, a second reviews it, a third approves it and the fourth does the actual deployment. Although this sounds extremely secure, in practice it's not: It's too easy for someone in the record process to make a human error.
Automated tools can transform this into a simpler, more automated two-step process in which one person changes and a second person approves, with the rest automated, logged and documented. The automation improves both traceability and error rates.
Finally, don't forget about implementing security during the update phase of the software development lifecycle. Specifically, the tools described above can and should extend to the handoff of code to the operations teams. As this is often done in part by creating explicit rules for deployment -- a concept sometimes referred to as configuration as code -- security teams may find new checkpoints where important DevOps and security requirements can be verified.
The bottom line? Integrating application security into DevOps isn't as difficult as it may appear. Leading firms typically establish an appsec bootcamp that trains developers on the fundamentals of application security, including the use of chosen tools. This serves to distribute security knowledge quickly and effectively throughout the developer organization.
Learn how to fast-track DevOps security in your company
See what's new in the market for DevOps tools that provide security
Why is security so often an afterthought in DevOps?