Container technology is widely viewed as revolutionizing the software industry. But as with any transformation from the status quo, the container revolution comes with both opportunity and risk. In fact, some of the most important benefits associated with containerization—speed, efficiency and lightweight design—are also responsible for creating new challenges when it comes to compliance and security. Here, we explore the rise of container technology as well as the challenges it creates for a secure software supply chain.
What Are Containers and Container Orchestration?
Containers are a packaging format in which applications are abstracted from the environment in which they actually run. Containerization does this by packaging an entire runtime environment—the application plus its dependencies (libraries and binaries, and other configuration files)—into one package, or container, that is decoupled from the infrastructure platform on which it was built. This creates a predictable environment isolated from other environments and their effects.
Conceptually, container technology is not new, and its roots actually stretch back to the late 1970s. But it was only with the open source releases of Docker and Kubernetes that containerization became viable at scale. Open sourced in 2013, Docker simplified the container build process and made easy containerization possible for the first time. However, Docker also engendered new challenges in terms of managing containers at scale.
These difficulties spawned various container orchestration platforms, of which Kubernetes quickly became the industry standard after being open sourced by Google in 2014. Kubernetes is a control plane for containers and automates all aspects of container management—from provisioning and deployment to load balancing and health monitoring—at scale. It is available both as an open source platform or as managed Kubernetes, in which a third-party provides, for example, Kubernetes on AWS as a service.
So, while Docker enables the packaging and distribution of an application, Kubernetes helps manage, scale, run and monitor that application. Without Docker and Kubernetes, the container revolution would have quickly fizzled.
What Are the Benefits of Containers?
Containers swept the software world due to a few clear benefits. Perhaps most significantly, an application container enables code to be written once and run anywhere. That means it performs equally well even if it begins life in a public cloud, like AWS or Azure, and is then deployed to an on-premise data center. Ultimately, this portability saves developers time because they no longer have to customize applications to deploy on various environments and can use the same open source tools across cloud providers.
The mobility of container workloads lends itself particularly well to cloud native development, as does the lightweight design of containers. Because they sit atop the OS kernel, containers are inherently smaller than virtual machines and reduce server costs, whether on-prem or in the cloud, as a result. That only further increases deployment flexibility and helps avoid vendor lock-in.
Just as importantly, containers facilitate faster, more consistent and agile application development through the microservices architecture approach. With microservices architecture, a given application is comprised of a collection of smaller, simpler containerized services—each of which can be managed by different developer teams. This reduced complexity and modular design improves reliability and creates high availability while dramatically accelerating all phases of software development. Because each microservice is able to be deployed, upgraded or otherwise altered independent of other container services, there’s no need to pursue a full application rebuild when changes are only needed to one module.
Containers, then, are responsible for ushering in a paradigm shift within software development, meaning they, along with container orchestration, cloud native and microservices, are really all part of the same narrative. Each advancement enabled the next, creating a clear revolution within the software industry. But while the container revolution solved many existing problems, it also created new ones in turn.
In fact, the benefits of containerization ironically create many of its drawbacks as well. To understand why, it’s first necessary to understand the software supply chain as it currently exists.
Containers and Software Supply Chain
Applications today are rarely built with proprietary code alone. In fact, 96% of applications audited by the 2019 Open Source Security and Risk Analysis report contained open source components, with many applications containing more open source than proprietary code. We’ve previously explored the rise of open source software but to summarize one part of its rise quickly, why reinvent the wheel when developers can instead use third-party components in the form of containers and build new functionalities atop them?
These third-party components create the software supply chain upon which the container ecosystem depends. This supply chain dramatically simplifies software development, making it faster and easier to develop new applications. Rather than build from scratch, developers download containers with the appropriate capabilities, bundle them together and create a new application in significantly less time.
But the desire to simplify software engineering—while more efficient and reliable in theory—also carries significant drawbacks. Developers often build atop software several layers removed from their own and into which they have very little insight. With the OpenSSL Heartbleed Security bug, for example, the real problem wasn’t with OpenSSH but with a lower level, more obscure cryptographic library, OpenSSL.
As it turns out, these tiny and relatively obscure open source components are actually much more common than big name projects like Linux, MySQL or Kubernetes. The Linux Foundation’s Core Infrastructure Initiative and the Laboratory for Innovation Science at Harvard found recently that tiny building block programs—sometimes less than a hundred lines of code—are actually the most widely used open source projects. Often, developers and end-users have little idea these programs even exist. And as you move further beyond the open source core, it becomes more and more difficult to understand the open source components present within an end-user application.
VMware Chief Open Source Officer Dirk Hohndel likes to highlight a quick experiment that further illustrates this trend. Dirk built a “Hello World” container that did nothing but print “hello world” and developed it in a naïve but fairly representative way. The resulting container application was more than 80 megabytes in size and contained nearly 100 different software packages. The lesson? Unless developers pay close attention, they end up with plenty of code within their containers that they simply do not expect nor understand.
So, while containers create a more efficient and faster software development process in theory, they also create significant risks when developers implicitly trust the containers they build upon and fail to examine the contents within. These risks take two forms:
- Compliance: Each component within a container may carry specific licensing obligations, but often, all an end user sees is the license attached to the container itself. This may open a company up to legal risk.
- Security: The components within a container may include backdoors or spyware. More likely, they contain obsolete software components with known vulnerabilities. And because many containers are effectively black boxes, it can be difficult to know if you are running a flaw and to update accordingly. Even if you do identify a flaw, it’s difficult to fix and often requires building a new container entirely.
What’s more, in pursuit of an even more lightweight design, meta information is increasingly being stripped from containers. This meta information details the packages within a container and their compliance obligations. Thus, its removal makes it even more onerous to inspect the contents of a container image.
A Solution for Securing the Software Supply Chain
Although this may seem like a technology problem, it’s actually one of infrastructure because, in a controlled environment, a solution already exists. At VMware, for example, we have processes and technologies in place to prevent “black box” and vulnerable containers from entering production. In fact, only a small number of base containers are approved for engineers to use. These are tracked via an internal registry to prevent vulnerabilities, and there exists a defined process for layering software atop them.
The question, then, is how to expand this level of control into a world in which thousands of random developers are uploading and using containers within their open source projects that then underlie other projects, and so on.
Open ledgers are one solution that could in theory solve this issue by creating a single authority that tracks but does not control container creation. Such a system would allow a central party to verify the components within a given container and thus provide companies the ability to put trusted containers into production.
But while this works conceptually, actually creating a single, distributed authority is difficult in practice. It requires a motivated software community that prioritizes safety and security over speed and simplicity.
At VMware, however, we believe that the vast majority of people do in fact hold the priorities of safety and security. The issue is not one of malicious actors but instead one of awareness, and as the open source community begins having these much-needed conversations, innovative solutions are assuredly just around the corner. Already, the Linux Foundation’s Automated Compliance Tooling project, of which the VMware-originated Tern is a part, has taken a strong step toward safer container best practices by formally consolidating open source compliance investment.
Ultimately, the container revolution is like any other revolution. Its first iteration is neither perfect nor final.
To learn more about open source and stay up-to-date on new open source projects and developments, explore our blog and follow us on Twitter (@vmwopensource).
