Secure DevOps basics: A guide for security professionals

by Jaikumar Vijayan

DevOps presents an opportunity for information security groups to integrate security earlier in the software development and deployment process--as long as they're willing to accommodate the cultural changes that come with the territory. This short guide on secure DevOps, also known as DevSecOps or rugged DevOps, is a great place to start for security professionals who want to make their jobs easier. With secure DevOps, you can embrace the DevOps mindset without compromising on security rigor.

Shift security left

At first glance, DevOps involves a culture of continuous software delivery and updates. For security organizations, this complicates the work of doing code analysis and other security routines on software before it's deployed in production.

But in reality, the DevOps delivery approach gives organizations an opportunity to reduce overall security risks in software, says Alan Shimel, an information security professional, and editor-in-chief of DevOps.com.

"DevOps is a great opportunity to get security right," he says. It offers security groups a chance to introduce security earlier in the development cycle so they can address issues earlier.

"When we look at the software development process, we read it left to right like a book. It starts with planning, coding, testing, releasing, and then deployment and monitoring," Shimel said. Security typically makes an entrance toward the end of this process, near the deployment phase, and is typically bolted onto the code, rather than being an integral part of it from the outset.

With DevOps, everything shifts left. The concept of shift-left simply means moving security tasks further ahead in the development timeline, Shimel says. Injecting code analysis tools and automated penetrating tests earlier in the development process makes it possible for organizations to identify and eliminate security issues at every step of the development process. By the time the software gets to the staging and deployment stage, all the things that need to be tested will have been tested.

Keys takeaways:

  • DevOps is an opportunity for security professionals, not just a challenge.
  • By moving security reviews and automated tests to an earlier point in the process, you save time and money by catching issues earlier and making them more solvable than they would be at the end of development.

Automation is your friend

The staging environment in a DevOps model is usually a mirror image of the production environment, where automated tests are run on the code to ensure that it's error-free. If the software passes these tests, it gets pushed into production without further security vetting.

More than the tools and actual processes, the biggest challenge with secure DevOps for security groups is cultural in nature, Shimel said. "My advice is not to be so afraid of change, and at least give new ideas the benefit, because you may be surprised."

To integrate security into the development cycle, the security group needs to be able to work with a cross-functional team. That means having a seat at the table with planning, development, and operational teams.

According to Shimel, the high degree of automation in DevOps is often its most radical aspect for security practitioners. "But the fact is that if you set the parameters right and the controls right, by automating you will actually have better security," he said. "You have less human error, less drift," because everything is configured to specifications that have already been proved secure.

Keys actions:

  • Give security professionals an equal seat at the table with a cross-functional team of planning, development, and operational teams.
  • Build a staging environment that you can trust to sandbox-test security issues, and allow code to move straight to production with no barriers if it passes security checks in staging.
  • Automate security checks properly to improve security by removing the possibility for human errors that might occur during a manual process, and configuration drift.

Change the cadence

Joshua Corman, chief technology officer of application security vendor Sonatype Inc said DevOps could be intimidating to security professionals who are used to a completely different rhythm and cadence. Typical security organizations, for example, might need four to five days to do a complete static and dynamic code analysis—maybe even longer for a full penetration test on code that needs to be deployed.

DevOps is the antithesis of that model. "These guys are reckless, going at 100 miles per hour." Worse, a lot of the automation and orchestration tools used in DevOps are still immature, at least from a security standpoint, he said.

The best tactic for information security groups is to approach DevOps the way the developers do. "The only way that security is going to scale is when you make the easy thing the safe thing" for developers to do, Corman said. Every developer wants to be on time and on budget, and the security group's role should be to try to enable that in a secure manner.

For instance, there's always a certain amount of unplanned and unscheduled work inherent in any software development project because of defective software components. Security groups can help address this issue by identifying and helping developers use safer components, Corman says. Numerous tools are available that help security groups identify vulnerabilities in popular software components and ensure a cleaner, safer supply chain for developers, he said.

Keys takeaways:

  • Information security teams need to make security checks (static, dynanic, interactive and runtime security testing) and penetration testing faster and more seamless with the process developers want to have.
  • Information security professionals need to research the tools their development team is using along with the rest of the tooling space so that they can meet with developers and make recommendations on safer components and libraries to use. Tools can help keep both teams up to date on software that needs security patches.

Bridging the communication gap

Equally vital is the need for security practitioners to be able to bridge the communication gap that exists between the security function and the rest of the organization. Security is often viewed negatively because people don't understand it.

To succeed in a world that's moving to DevOps, security groups need to be able to explain their concerns in language and terms that are relevant to the operational and development teams, Corman says. For example, instead of talking about a breach or a vulnerability, it's better to talk about a security risk in terms of project delays and unplanned, unscheduled work. When speaking to operations teams, it's better to talk about availability and mean response time rather than a security breach.

"Use the priorities that they care about and the words that they use. If you understand what they care about, you can help them be successful," he says.

Key takeaway:

  • Information security teams should not only have regular communication with development and operations, but should also learn how to speak those teams' language and understand their concerns before trying to persuade them.

If you make the effort to take these actions described above, you will have a much better chance of persuading developers and IT operations to meet you halfway and adopt more secure processes. Secure DevOps is about all groups of an organization meeting each other halfway, so each team needs to focus on putting in its part of the effort first, and then work with other teams that will hopefully uphold their end of the bargain as well.

Additional resources

For more about integrating security professionals into a DevOps team, see these resources: