When containers become a nightmare

Containers, certainly containers running on public clouds, are really old hat by now. These self-contained, lightweight software packages come with their own runtime environment and are relocatable from platform to platform, typically without significant changes to code. Containers include an application as well as its dependencies, such as libraries, other binaries, and configuration files needed to run them.

Containers are one of the most popular application development approaches, also supporting the “wrapping” of applications existing within containers, but there are flaws and vulnerabilities that are systemic to containers. This has made using them one of the scarier things for cloud security specialists and a preferred attack vector for wrongdoers.

[ Also on InfoWorld: No one wants to manage Kubernetes anymore ]

The core issue is that any exposures can easily include the other systems, applications, and data that are connected to the containers. Furthermore, defects in these components may provide an attacker with the ability to gain control of a system and any sensitive data that the system may have access to. This is when bad things happen.

What are the best approaches for detecting container vulnerabilities? More importantly, what can be done to minimize disruption to those who have to build using containers?

The answers are really in two parts: Scan for vulnerabilities and build to avoid vulnerabilities.

Scanning is the most common approach, considering that it’s part of a CI/CD (continuous integration and continuous delivery) pipeline. Scanning looks for security issues when the code is created, tested, reviewed, and deployed, as well as during operations. Automated scanning processes can spot vulnerabilities and, in some cases, automatically correct them without any developer interaction.

Registry scanning, or culling through a collection of repositories, looks over many container images at once. These become running containers when they are instantiated from the registry to a production system, whether in the cloud or not.

Runtime environment scanning is another method, which is all about scanning executing containers for security issues.

Your best bet is to leverage as many types of vulnerability scanning as you can and thus remove some (but not all) of the risk in building and deploying container-based applications.

Building to avoid vulnerabilities is often a matter of using common sense—considering vulnerabilities that can be introduced by doing dumb things, such as using base images from untrusted sources. Other issues would be leveraging tools that have been vetted by a security audit, only using code that has a known legacy, and providing special training for developers in terms of making the right choices when building for secure containers.   

Pick the right tools for scanning, and overdo scanning of containers being built, tested, staged, and deployed. Checking each stage for security issues really does not slow things down, and it just lowers risk.

This is not rocket science. You’re leveraging tools that are already around and proven. That said, many container developers are not using some of the most basic security tools and approaches. Given how dependent on containers most IT shops moving to the cloud are, we’re going to need to fix that.