When my company launched in October 2015, few security folks even knew what software containers were. We might as well have been securing shipping containers!

Development and DevOps teams, on the other hand, already were enthusiastically embracing software containers because of the speed and agility they bring to the application delivery process. Plus, containers enabled them to transition to a much more modular, efficient and automated method for building new applications (called microservices).

However, due to the prevalence of data breaches, corporate leaders have (understandably) become more risk-aware and risk-averse when it comes to IT. As a result, the introduction of a new technology such as containers may be perceived as risky, even if it offers the chance to improve the organization’s cybersecurity posture.

DevOps teams have been on board to risk assess the security and compliance posture of container environments and applications, but few people outside the dev team currently know what containers are.  So out of necessity, Development and DevOps teams became responsible for container security.

However, we are slowly seeing that change as we move into 2018, and the sooner that security leaders familiarize themselves with the cultural norms and technology ecosystems that surround containers, microservices, and DevOps, the better. Simply put, containers offer a clean slate to bake security into the fabric of next generation applications, instead of bolting it on after the fact.

For those of us who have been in cybersecurity for some time, this is a hugely appealing proposition. We’ve been chasing endless gaps created in applications and runtime environments, piling on more and more point tools to fill a seemingly bottomless pit of security vulnerabilities, structural flaws and inefficient processes. The added complexity and cost and chronic IT skills shortages, combined with the sense of not being able to catch up with the bad guys, have left CISOs in need of innovative approaches to these formidable application security challenges.

Containers allow for one simple but powerful innovation, known in DevOps parlance (and hopefully increasingly in security circles) as enabling security to “shift left” to the beginning of (and throughout) the development lifecycle. So, what exactly does that look like? At a high level, best practices for full-lifecycle container security can be divided into five main components:

  • Managing vulnerabilities in container images – Ensuring that images are signed and originate from a trusted registry are solid security best practices, and vulnerability scanning enables DevSecOps teams to vet and validate the code that container images encapsulate.
  • Reducing the container attack surface – While #1 is a powerful example of reducing the attack surface, containerization has specific structural and operational elements that require special attention. Mainly, the underlying shared kernel architecture of containers requires attention beyond securing the host; it requires maintaining standard configurations and container profiles.
  • Separation of Duties at the container level – This enables users to be assigned role-based constraints on what changes or commands a user can execute based on application context. This makes it much easier to define and enforce standard processes such as separation of duties and other controls that ensure governance, compliance and assurance throughout the software development lifecycle.
  • Hardening the host – One of the key benefits of containerization is that it isolates an application and its dependencies within a self-contained unit that can run anywhere. However, security needs to set policies as to what these self-contained units can and can’t access and consume. This is done by making sure key OS attributes (namespaces and control groups in Linux, for example) are appropriately and consistently configured, and in accordance with security policies.
  • Automating the container security process – DevOps prescribes the use of automation and a spirit of collaboration to push the speed of agile development “to the right,” across the application lifecycle. Security, which currently sits at the end of the development cycle (as far to the right as right gets), can use the same DevOps methods and tools (such as continuous integration(CI)/continuous delivery (CD) and orchestration tools) to “left shift” and work towards automating these processes over time.

If we do this right, the next generation of applications will be inherently more secure. They may not be hack proof (nothing is, really), but “baking in” security controls at multiple points across the dev pipeline with the goal of having those controls become increasingly automated will greatly reduce application attack surfaces compared to today. It also will streamline and/or eliminate broken application security processes (such as code drift, and late stage patching), and provide a way to bridge the skills gap by “enlisting” all developers to deliver more secure code. But left shifting security requires full support from both DevOps and Security.

We believe that a new cross-functional team that fuses experts from both sides needs to work in lockstep with DevOps and Security to make that shift happen. Gartner coined the phrase DevSecOps to describe this emerging discipline. We believe succeeding at DevSecOps is key to delivering better application security, and that containers provide a development platform that that is optimized for transitioning to a DevSecOps-driven approach. Our vendor neutral Container wiki is one of many free, useful resources that DevOps and Security pros can access to get up to speed quickly–and there are plenty of other resources for DevSecOps teams.

Some of the most effective organizational tactics that forward-thinking organizations are using to transition to a DevSecOps model are:

  •  Creating a bilateral task force – A joint DevOps/AppSec task force can start addressing pressing matters right away, or tackle more basic DevSecOps issues like defining a joint set of measurements that facilitate continuous collaboration.
  • Training DevOps in security – To help DevOps team members better understand their new security colleagues, encourage them to learn more about security. From practices to jargon – there is no shortage of online resources or conferences that can promote DevSecOps coexistence.
  • Adding security to the DevOps mix – Security thinking is very different to DevOps thinking. To jump-start what will hopefully become a smooth-running team effort, add security staff to your DevOps team. By breaking down the internal cultural barriers, you can smooth and expedite the integration of these two teams into a cohesive DevSecOps group.

 We are already seeing this on the ground. A large software vendor with many business-critical SaaS applications recently defined their process as one that “allows the cloud security team to set policy and monitor its enforcement, while collaborating with the DevOps teams to agree on implementation.”

Think about it…how often are security professionals presented with a clean slate to completely re-engineer security into business critical applications according to best practices? That’s what containers, microservices, and DevSecOps bring to the table.

How cool is that?