Containers and the question of trust
Containers and the question of trust
The security risks associated with containerised software delivery has become a hot topic in the DevOps community, where operations teams are under pressure to identify security vulnerabilities in their production environments.  

As the use of containers becomes standard practice, existing software development and security methodologies may need to be modified to better support a new way of developing, running, and supporting applications made possible by containerisation. 

For example, an important operational difference due to the nature of containers is that, contrary to how virtual machines are maintained, vulnerabilities identified within containerised applications shouldn't simply be patched with the latest software update. Instead, patches to container images are made by rebuilding the Docker image with the appropriate patches, and then replacing the existing running containers with the updated image. This change in paradigm often requires enterprises reassess their patching processes.

Given the level of adoption of open source technologies in container infrastructure, a key to protecting your applications in production is maintaining visibility into your open source components and proactively patching vulnerabilities as they are disclosed. And if you assume from the outset your containers will be compromised, you can prepare by making changes that make it much harder to mount an attack from a compromised container. 

Identification of risk is a crucial component of security, and risk is a function of the composition of a container image. Some key questions operations teams need to answer in order to minimise risk include:

What security risks might present in that base images used for your applications, and how often are they updated?

If a patch is issued for a base image, what is the risk associated with consuming the patch?

How many versions behind tip can a project or component be before it becomes too risky to consume?

Given my tooling, how quickly will I be informed of component updates for dependencies which directly impact my containers?

Given the structure of a component or project, do malicious actors have an easy way to gain an advantage when it comes to issues raised against the component?

Defining a container security strategy

You can't rely on traditional security tools that aren't designed to manage the security risks associated with hundreds—or thousands—of containers. Traditional tools are often unable to detect vulnerabilities within containers, leading to a false sense of safety. Periodic infrastructure security scans don't account for the pace of container application development, nor do they account for the rate of security disclosures. Organisations need to adopt container-specific vulnerability management tools and processes to minimise the potential for compromise. 

One critical attribute of any container security solution is its ability to identify new containers within the cluster and automatically attest to the security state of the container. The desired security state will of course vary by application, and solutions need a policy framework which allows “at a glance” identification of any containers violating policy. The most advanced tools will enable this enforcement by providing a method to prevent containers with security vulnerabilities from being deployed and include centralised reporting and monitoring of the compliance state of each image to preventing non-compliant images from being run.

Most enterprises operate under governance regulations requiring continuous monitoring of infrastructure. This requirement exists for containerised applications as well, but the immutability of container images and the fact that containers are replicated from those images leads to a change in paradigm. Container images should be monitored continuously because new security vulnerabilities are being discovered every day. But with hundreds or thousands of containers running at the same time, finding and remediating every newly discovered vulnerability in each container can be a challenge. Identifying an issue in a container image means that same issue will be present in all running containers replicated from that image. An image created with fully up-to-date components may be free of known vulnerabilities after its creation, but at some time vulnerabilities will be discovered in one or more image components.

Be proactive with container security
The bottom line is you need to be proactive about container security to prevent breaches before they happen. While containers help speed software delivery, they also pose new risks to application security. The security risk associated with vulnerabilities in containers must be controlled. The most effective and proactive way of controlling that security risk is by finding and removing vulnerabilities in base images. Deploy and use a dedicated container security solution capable of preventing, detecting, and responding to threats aimed at containers.

Tim Mackey, senior technical evangelist, Black Duck Software

*Note: The views expressed in this blog are those of the author and do not necessarily reflect the views of SC Media UK or Haymarket Media.