Wayne Gibbins, chief commercial officer, Wercker
Wayne Gibbins, chief commercial officer, Wercker

It's been hard to avoid talk of software containers this year. Docker-based container technology has been adopted across the industry from small startups to enterprise goliaths like Goldman Sachs. According to research from the Cloud Foundry Foundation, 16 percent of organisations are now using containers in production.

This may sound low, but the same survey also suggested that another 64 percent of companies are expecting to move into production-level containers in the coming year. Another study, from ClusterHQ, suggests that container usage for production workloads jumped 96 percent over the last year.

This rapid move into production workloads has rightly raised concerns over the security of software containers compared with more traditional and established technologies such as virtual machines and hypervisors.

Containers: a crash course

Containers are in many ways a logical continuation of what's gone before. Developers first moved away from working with ‘bare metal', ie being limited in their software's capacity by the hardware it would be installed on, by using virtual machines. Virtual machines allow developers to abstract away the underlying hardware by using a hypervisor to emulate hardware capabilities such as CPU, storage, memory and networking. This allows software tasks to be run simultaneously on multiple virtual machines for each physical machine.

We can think of containers as lightweight versions of virtual machines, with a few key differences. Instead of a hypervisor, containers are hosted on the underlying operating system kernel. This makes containers far smaller than virtual machines, because they no longer need a full operating system to be saved within them.

Containing threats

Containers can have positive and negative implications for software security, depending on the local environment.

Many companies, particularly in the enterprise sector, are still working within the monolithic software paradigm, meaning that common internal tasks such as authentication, error handling and UI are all interwoven and co-dependent. With containerised applications, developers are encouraged to break their code into modular components, or micro services, that can be removed and replaced without affecting the overall application.

The security benefits from such a progression are clear - software weaknesses and breaches in the code can be identified and rectified more quickly. Developers can spend less time picking through a tangle of dependencies and more time isolating and resolving the problem.

This is articulated clearly by Gartner analyst Joerg Fritsch, who wrote this year that “applications deployed in containers are more secure than applications deployed on the bare OS… They greatly limit the damage of a successful compromise because applications and users are isolated on a per-container basis so that they cannot compromise other containers or the host OS”. In short, containers open up the possibility for immutable deployments.

Risks vs rewards

As with any new development methodology, containers have drawbacks as well as benefits. Developers have to approach containers with their eyes open, and keep working to the same security best practices.

A large number of containers include third party Linux or other open source-based code, and so it's key for developers to screen their code for potential malware or vulnerabilities. A variety of tools are already receiving attention in this area - this year CoreOS announced the first full release of their Clair container image security analyser, meanwhile earlier in October 2016, Anchore, a startup which says that it can ensure software containers are safe, announced it had secured US$ 5 million (£4 million) in seed funding.

Another factor to remember is that containers, unlike VMs, all share the same underlying kernel. This can create some security risks that must be accounted for: attackers have a faster route to disrupt the host kernel via creating a kernel panic, or causing a container to monopolise resources on one container causing a denial-of-service. These kinds of attacks are unlikely, but IT teams must be prepared to mitigate against them.

Ultimately, containers offer huge potential for expediting current software development practices. While denial-of-service attacks or corrupted open-source software are certainly issues to be aware of, I'd argue that software compartmentalisation and the enhanced developer velocity delivered by containers can mitigate against these risks.

Contributed by Wayne Gibbins, chief commercial officer, Wercker