DevSecOps: Slaying the Myths of Container Security

containers are clearly appealing for companies and development teams who want to deliver and iterate on their software faster and efficiently. this is achieved through more consistent, simple, and repeatable deployments, rapid rollback, and simpler ways of orchestrating and scaling distributed applications.

the survey shows, however, that security is very relevant to organizations that are looking to deploy containerized applications. though the question referred to concerns, we believe that security is relevant to containerization in both in the positive and negative senses. how do containers both introduce and solve common security challenges?

slaying the myths

there are a lot of myths about container security.  though there have been demonstrated exploits of people, for instance, breaking out of containers or attacking container daemons in various ways, we believe that when you consider both sides as above, containers are a net benefit for security-minded organizations. in principle, containerized applications give us tens of different ways of introducing new security approaches that reduce attack vectors and minimize attack surface areas.

what organizations do need is a lot of education — first, to put some of the myths to bed, and then to educate on how to achieve container security in an optimal way.

achieving container security

there are many approaches that teams can bring to the table to maximize security in a containerised environment.

least privilege

by default, containers add layers of protection and sandboxing around a process. these protections ensure that processes are not allowed to interact with other processes, or the underlying host operating system in any way other than that explicitly allowed. by default, container platforms are locked down, but there can be additional restrictions applied at the time that you start the daemon or container.

reducing attack surface

both containers and other pieces of the platform such as the daemon or orchestrator should also be configured with the minimal possible scope for attack.

container registry

companies want to ensure that rogue, untested, or unlicensed software is not entering the organization. to achieve this, companies will deploy an enterprise private registry as a central store of containers. these containers can then be validated, scanned, and configured with the proper access controls to ensure a single source of the truth.

container signing

container orchestration platforms will integrate container signing mechanisms to ensure that we are only running trusted code inside the organization's boundaries.

should the 88% be concerned?

the survey shows that 88% of people have some degree of concern around security of containers. hopefully, this short article has made the case that there are many myths leading to these concerns, and many options in how you deploy your container platform for adding security into your environment.

this blog is one of seven in a series providing expert commentary and analysis on the results from sonatype’s 2017 devsecops community survey. for access to all of the blogs in this series and the survey report, see here . benjamin wootton ( @benjaminwootton ) is the co-founder and cto of contino and is a guest blogger for sonatype's 2017 devsecops community survey.