Exploring open source license compliance for Docker containers

Open Source Software (OSS) Compliance is all about giving credit where credit is due and following the terms of use. Not doing so destroys others’ trust in you. Complying is as easy as: Find your software’s build/run dependencies Find licenses for them Do what the licenses tell you to do Sounds pretty straight forward, right? Enter […]

Written By Dasha Gurova

On July 30, 2019
"

Read more

Solve the challenges of large-scale data, once and for all.

Open Source Software (OSS) Compliance is all about giving credit where credit is due and following the terms of use. Not doing so destroys others’ trust in you.

Complying is as easy as:

  1. Find your software’s build/run dependencies
  2. Find licenses for them
  3. Do what the licenses tell you to do

Sounds pretty straight forward, right? Enter the complicated world of containers!

Don’t get me wrong, we love them. Zenko is a distributed application packaged in Docker containers and orchestrated by Kubernetes. This architecture makes it possible to deploy your software almost anywhere, benefit from agile development workflows and ensure continuous uptime. But with great power comes great trouble, too.

Anatomy of a container

In established areas of open source software, it is well known that distributing software means inheriting all the license obligations of the dependencies. But when it comes to cutting-edge technology like containers it is almost like the “wild wild west” out there. Why is the landscape of tools and practices for OSS compliance in containerized applications so limited?

Although we have been using containers to ship applications for a relatively small period of time, the adoption of it was so fast that the compliance part has been almost ignored. The ghosts of failing to comply with OSS are now coming back to haunt us.

I covered Docker container security issues in last week’s post, and I think those two issues (security and OSS compliance) are related and have similar challenges. Both security vulnerabilities and failing to comply with open source licenses come from the same place – the shady nature of container images.

How a Docker container is usually created:

  1. We download some images from a public repository to use as a base. At that point, all that gives us is a collection of tarballs containing files.
  2. We copy our application to the container (probably the only files that we know anything about).
  3. We execute scripts to install dependencies, build binaries, etc..
  4. We upload the resulting image to a repository.

This image is now shipped to the customer or other users. Now we are distributing not only our application but everything inside this image, and we are responsible for complying with all the licenses.

OSS compliance for containers

You should set up your compliance strategy from at least two angles.

Angle 1 – Control the process of creating and building images

Use only “known-good” OS base images, where you know you can get the list of all installed software along with licenses and sources (for example, Debian’s package manager can do that). On top of that, use build manifests to install the software you need and keep track of it. Avoid using Docker multi-stage build functions, as they are not reproducible.

Angle 2 – Employ scanning tools

I want to make one thing clear right away – there is no tool that will take care of everything. You need to put a process in place that combines scanning  Docker images with manual checks and research.

Tools from Linux Foundation

The Linux Foundation recently launched the Automated Compliance Tooling (ACT) project in an attempt to drive and help with OSS license compliance. There are four projects that are part of ACT you should check out:

  • FOSSology – an open source license compliance toolkit letting users run and export license and copyright scans.
  • QMSTR – this tool creates an integrated open-source toolchain that implements industry best practices of license compliance management.
  • SPDX Tools – Software Package Data Exchange (SPDX) is an open standard for communicating software bill of material information including components, licenses, copyrights and security references.

Container compliance scanners

  • VMware also donated its Tern project to ACT to help cover compliance automation in the container space. It offers a couple of different formats for the scan results. Deployment options: Docker, Vagrant, Linux.
  • Another tool I came across is Container-diff – it analyzes images in a similar way as Tern, but offers a comparison between two images. You can use this to keep track of changes made to different versions of your images. Deployment options: Linux, macOS, Windows.

Container security scanners

Security scanners are another set of software that can help you with container images. The variety of tools in this domain is more robust, maybe because security breaches are can get far messier than OSS compliance. You can use these scanners not only to check against known vulnerabilities but also as a way to produce a very thorough SBOM (software bill of material). These tools in their essence are scanners that decompose container images to building blocks (dependencies).In my humble opinion, those are leading the pack:

To learn more and see the longer list, check out my previous post on Docker container security tools.

What did we learn?

We should be more mindful when reusing Docker images and building on top of them. It is also necessary to create a workflow that includes some automation tools (scanners) and manual checks.

With more developers and leaders talking about the importance of open source compliance, hopefully, we will soon see shipping fully compliant containers as a normal, more streamlined practice. As it happens, tooling will evolve automating the process and making it easier.

Share your thoughts or ask a question on the forum.

Simple, secure S3 object storage software for modern applications