Do you know what’s in your containers? No, the question has nothing to do with those mystery containers in your fridge. But if you don’t know what’s in those lovely Docker containers which are all the rage, you could be in store for just as rude a surprise as discovering what might be hiding deep in your fridge.
Seriously, this has everything to do with basic data center hygiene—knowing the software present in your environment. Executables are made to be run, and if there’s one which you don’t expect to be run, and it does run, things could become problematic quite quickly. This is the lesson of modern malicious software: Stuff that shouldn’t be present gets exploited. And containerized applications are no different from any other software platform.
The first step in understanding what’s in a container is to understand how something gets into a container in the first place—a fairly simple process.
Container images are immutable, read-only versions of a container. Until they are executed, they are nothing more than a binary file stored in a container registry. To get them into a running state, a container orchestration system like Kubernetes, OpenShift, or Docker Swarm is used. The container orchestration system first “pulls” the container image from the specified registry to a server node. There are many possible registries—some private, some public, and many run by third parties. Once the image has been pulled to a given server node by the orchestration system, it can then be executed.
While the container image typically defines an application to start by default, in reality any executable in the image can be started, and more than one process may be running. Put in security terms, unless you limit what can run in the image, assume everything can. The best way to limit what can run in the image is to limit what’s present—but that requires an understanding of what is present, of course.
In the realm of DevOps, there is a strong desire to move everything to the left—that is to say, toward the developer. While it’s true the best place to fix an issue in software is as close as possible to where the code is used, the risks of consumption are to the right of where a container image is being created. Put another way, the best a container image author can do is scan their image when it is pushed into an image registry. Unfortunately, when the time comes to run that same image, the security risk could easily have changed.
In short, any container security scanning solution must be able to scan container images regardless of the source registry. Due to the latency between when an image is pushed to a registry and when it is used, any scan occurring prior to when the image is used should be considered suspect. This also means that regardless of how much you trust the registry and any scanning it might have performed, if the scan wasn’t done when you consumed the image, the scan results may be incorrect.
From a regulatory perspective, we’re in a period where applications of all forms need to have continuous monitoring in place. For some, the term “continuous monitoring” means that a network security solution is in place. But history provides us with many examples of how a lack of awareness of what’s in an application and what’s running on a system led to a security breach.
Periodic scanning using network scanning tools as a proxy for continuous monitoring also doesn’t work well. This is due to an issue of locality of reference and perspective. When you look at a system from the outside and an attacker looks at it from an adjacent internal system, the two views can be quite different. Continuous monitoring demands an understanding of the risks present in the system and ongoing validation that those risks haven’t increased.
Put another way:
These are important considerations for anyone placing containerized applications into production. And if your container security solution can’t automatically scan everything regardless of source, and continuously monitor for new security threats while alerting on continued usage of vulnerable images, then you probably need a new solution. As it happens, we have such a solution in our portfolio.
I encourage you to find Synopsys at RSA and ask for me—Tim Mackey—by name. I’ll be happy to help you build a more secure data center using container technologies.
Tim Mackey is the Head of Software Supply Chain Risk Strategy within the Synopsys Software Integrity Group. He joined Synopsys as part of the Black Duck Software acquisition where he worked to bring integrated security scanning technology to Red Hat OpenShift and the Kubernetes container orchestration platforms. In this role, Tim applies his skills in distributed systems engineering, mission critical engineering, performance monitoring, large-scale data center operations, and global data privacy regulations to customer problems. He takes the lessons learned from those activities and delivers talks globally at well-known events such as RSA, Black Hat, Open Source Summit, KubeCon, OSCON, DevSecCon, DevOpsCon, Red Hat Summit, and Interop. Tim is also an O'Reilly Media published author and has been covered in publications around the globe including USA Today, Fortune, NBC News, CNN, Forbes, Dark Reading, TEISS, InfoSecurity Magazine, and The Straits Times Follow Tim at @TimInTech on Twitter and at mackeytim on LinkedIn.