Author: Tom Geller

Licensing compliance is often forgotten in containers — but an initiative brings help.

“Don’t ship that container!” — at least, not without bringing it into compliance with the licenses it contains. That was the cry VMware’s Chief Open Source Officer Dirk Hohndel brought to the Open Compliance Summit in Yokohama last December. In a stunning display there, he showed how even simple container files can draw in dozens of projects with a mixture of licenses — licenses that are rarely audited.

“It’s just common sense. Being able to understand what you ship is really important.” – Hohndel

As he told Swapnil Bhartiya, Editor-in-Chief of TFIR, in a video interview shot at KubeCon in Seattle a few days later, “It’s really, really hard to actually know what’s inside your image. So how can you know it’s secure? How can you report the correct licenses, give the correct copyright notices, or provide the corresponding sources?”

Unknown contents, unknown liability

The result could be a “rude awakening” when “a copyright troll or concerned copyright owner [starts] to enforce their rights.” As an example, he mentioned Alpine Linux that “contains BusyBox, which has very strong feelings about how you have to provide the corresponding source. If you run an Alpine container, do you actually have access to the exact corresponding sources that according to the copyright holders you have to ship?”

Part of the problem, he said, is in how people use containers. “You’ll find this in a ton of Docker files: downloading a random binary from a user’s account of GitHub, making an executable, and running it in your container. That is a compliance and security nightmare.”

He believes changes in the software engineering landscape are partly to blame. “One of the shifts over the last decade has been from software development as an engineering profession to something that almost feels more like a trade,” he said.

“[Engineers] will use these building blocks, but they don’t always understand what’s inside the building blocks. And they no longer spend as much time as we did a decade or two ago in figuring out: What is all the code that is now running? How does this all work together? The technologies are solid and strong,” said Hohndel. “This is not the criticism of containers or Docker or Kubernetes or anything. It is a comment on how we are putting these solutions together.”

While he doesn’t fault the technologies per se, he believes containerization has led to a shift in responsibility from project maintainers to individual developers.

“In a Linux distribution you have the maintainers who look at all of these components and find versions that work with each other,” he said. “They test across different projects and different packages. And then you simply install an application on top. Whereas today in the cloud-native world, there is a lot more assembly of components from different sources by the application developer — by the end user, basically. Security and maintainability and compliance and such are no longer things that the engineers have at the top of the mind as they create these solutions.”

Tools to the rescue

To help, The Linux Foundation announced the Automated Compliance Tooling (ACT) project at the Yokohama conference, including VMware’s Tern along with  FOSSology, QMSTR (“Quartermaster”), and SPDX Tools as its inaugural components. As Hohndel said, “The goal of [the ACT] project is to help you understand: What’s inside of my container? What am I shipping? What are the implications of compliance and security perspectives?”

But Hohndel also suggests a simple trick to stop remote packages from going into your container: Turn off Internet access when you build. “It’s fascinating to see how many things break. You installed something from Node.js and unbeknownst to you, three packages down, something downloads a binary from the Internet and installs it into the file system. And if you look at the bill of material at the top level, it all looks [the] same. But what happens during installation is what matters.”

Fortunately, he’s found that the community has been receptive to his warnings. “Every single time I give this presentation, the feedback that I get is, ‘Oh wow, I hadn’t thought about it this way. I need to talk to my IT people. I need to talk to our product people. I need to talk to the security people. This is fascinating, this is interesting, we need to take action to get ahead of this.”

Aside from security and compliance concerns, Hohndel finds this response logical. “It’s just common sense. Being able to understand what you ship is really important.”