SecDevOps and Containers: Kill the Candy-Related Analogies

Google “SecDevOps” and the results show that security teams are ready and willing to jump on the DevOps bandwagon. DevOps folks talk a lot about “shifting left,” i.e., addressing issues earlier in the development process. The phrase may be new to security folks, but the concept isn’t: Security professionals have advocated to “bake security in” to development processes independent of DevOps, and long before mega breaches became a headline staple.

A big driver fueling the SecDevOps movement is that DevOps has made the separation between development and security obsolete. In fact, the division between writing the code and securing the runtime platform is no longer necessary or sustainable. Development and security must come together and collaborate in a way that will efficiently move secure, well-built application stacks through the continuous delivery pipeline.

CloudNative Summit

Here are some steps organizations can take to bring development and security closer together:

  • Establish and communicate clear and consistent lists of approved base images, application components and coding practices.
  • Evaluate image security at development and adopt a practice that will fail the build if the image fails to meet vulnerability thresholds and other security standards.
  • Continue to evaluate the security of the images at each stage of the continuous delivery (CD) pipeline.
  • Restrict the ability to update existing images at rest, either on the registry or inside the Docker engine.
  • Make the security stance of running containers known to all stakeholders, from application owners to security and developers.
  • Establish a policy on container runtime practices: Do they run in VMs? Are they grouped by application? By trust level? What is the orchestration policy?

The above list is a set of guidelines for “how” to start fusing security and DevOps. While it might seem mind-numbingly obvious why an organization would want to shift security to the left (not to mention that plenty has been written on the topic), I wanted to put my own spin on it.

One of the most significant benefits that shifting security left offers is that it provides the opportunity to secure the application from within. Instead of applying security as an afterthought, when security “shifts left” to the developer, it allows for much more granular testing to be carried out on each component. It forces developers to consider application security and integrity in ways they have never had to before, and it forces security to think about why developers make the architectural decisions they make, how specific choices might impact security, etc.

Another benefit of shifting security left is that it provides visibility into application integrity prior to launch. Just as continuous improvement/continuous delivery (CI/CD) improves code quality, because every piece of code is immediately tested in context, it also improves security. Instead of looking at the entire application and trying to understand its potential flaws, the likelihood of such flaws being discovered before delivery is much higher. It also provides the ability to automate granular security checks into CI/CD process, and accelerates response times. When security is automated throughout the development process, when flaws and vulnerabilities are discovered, they can be rectified much faster.

Love or hate the “hard on the outside, soft of on the inside” analogy of corporate security (which, interestingly enough, topped off a list of the best and worst security analogies complied by Tripwire), it has, until now, defined corporate security. While the notion of a hard outside and a soft or chewy inside was usually applied to network security, application security processes were built around many of the same assumptions—mainly, that the application needed to be constructed first, and then hardened.

Experience has taught us that relying on humans alone for the rigorous application of security procedures delivers, at best, patchy results. Where possible, procedures should be automated. This has never been truer than in container-rich DevOps environments, where the speed of delivery and the number of changes are greater than ever before.

When running containers, development organizations find themselves with unprecedented influence over the application security posture of their organization. The time to shift security to the left is now, as container technology approaches the tipping point of mainstream adoption. It will provide the ability to automate security processes into the development cycle, which will reduce human error and improve risk and compliance management. It provides a once-in-an-era opportunity to harden applications from the inside out, providing inherently more secure applications and rendering candy-related security analogies obsolete once and for all.

About the Author / Amir Jerbi

AmirJerbiAmir Jerbi is co-founder and CTO of Aqua Security. Prior to Aqua, he was chief architect at CA Technologies in charge of the host-based security product line, and has 14 patents to his name. Connect with him on LinkedIn and Twitter.