Containers can be traced back to 1979 with chroot but the advent of Docker has exponentially increased the popularity and usefulness of this technology. Any technology that becomes popular and useful also becomes a target for attacks.
Containers are designed to provide isolated environments rather than full virtual machines, but they make great targets for attackers because they are often not monitored as well as other assets in the IT environment.
It is imperative that organizations assess containers for vulnerabilities just like any other asset in the environment. Several vulnerability scanners can scan running containers and report vulnerabilities, but that is just part of the story.
Containers don’t run all the time; often they are only called to complete specific tasks then paused or shutdown until needed again. A traditional scanner may miss vulnerabilities unless the container is running during the instant of the scan.
Let’s use an analogy that is a little more physical and easier to grasp. Most organizations use laptops and scan these laptops for vulnerabilities. If a scan happens while the laptop is on the network, vulnerabilities will be found and reported, but if the laptop is powered off or hibernated, the vulnerability scan cannot assess the state of the laptop (assuming no wake on Lan functionality.)
The same holds true for containers; they must be on to be assessed by vulnerability management products.
That is, until now.
The Tripwire Vulnerability and Exposure Research Team (
VERT) has released ASPL-736 with new functionality to scan non-running (paused, stopped, created, exited, etc.) Docker containers. This supplements the coverage for running containers, thereby giving a full view into the state of containers in production.
Some people will think, "Cool! But why do I need that I scan non-running containers if they are all scanned before they go into production anyway?"
Let’s go back to the laptop analogy to answer this. Your organization probably uses a common image for all laptops with known good OS and approved apps. At the time it is given to the employee, it is in a known good state. The employee can then modify it by installing software or even exposing it to
malware. These threats can be missed since the laptop is not necessarily connected to the network during vulnerability scans.
It is not advisable to modify/patch containers in production. Instead, you should patch the parent image, test it, and replace the production container with the updated one. You would not do this for laptops, but we can still use the analogy because just as organizations can have many of the same laptop, they can also have many of same containers or components shared among containers.
When a patch is released for a vulnerability affecting the laptops, vulnerability scans are conducted to make sure all systems have been updated. Now consider the situation where you have a large number of containers and there is a patch needed for OpenSSL to keep them safe.
The base image would be updated, and the updated containers would be redeployed into production. If the
vulnerability management solution can only scan running containers, there is no way to verify all containers have been updated. This leaves a blind spot where containers may be resumed or started without any visibility into their true vulnerability status.
The ability to scan non-running containers gives security admins super x-ray vision into the state of these containers and eliminates this blind spot.
To find out more about this latest release,
click here.
