Tern 2.0 Introduces Dockerfile Lock for Point-in-Time Software Bills of Material
At its core, containerization works to nullify the “it works on my machine” excuse that developers turned to for years. By packaging up an application’s code/binaries with the required configuration files, libraries, and dependencies required, containers have solved the issue of code running differently on different machines.
But as with any solution, new problems have arisen. One such problem for companies running containerized applications is that of security and compliance in relation to the numerous dependencies included in a container. Open source container inspection tool project Tern has recently released Tern 2.0 in its continued efforts to address this issue by providing users with a “software bill of materials.”
“What folks don’t realize is that when they install packages, they are also installing the packages’ dependencies. Usually, they bring in more packages than know that they’re pulling in, and so Tern aims to provide a complete list of packages that a Docker file may install in a container image using Docker build,” explained Tern maintainer Nisha Kumar in an interview. “The problem with containers is that you are essentially shipping a whole OS. This is something that OS suppliers know fully well and have historically done their due diligence for, but because containers not only contain a base OS, but they contain a host of other packages from all kinds of ecosystems, it gets more and more difficult to actually get an absolute list of dependencies for your app.”
With this list, Kumar explained, users can more easily make an assessment concerning a security posture, as well as make sure that the related licenses for the various packages are compliant with any related regulations and the company’s use of that software.
While this may sound relatively straightforward, there is yet another complication here — Dockerfiles, which automate the creation of a container image, do not explicitly list the packages and their versions. Instead, they might say to use the “latest version” of a particular package, which, depending on when the container image is built, may refer to a different version of that package.
To solve this issue, Tern 2.0 has introduced the “Dockerfile lock” feature, wherein Tern “creates a locked Dockerfile in which the base image is pinned to a digest and the packages installed for each subsequent layer are pinned to their versions, if they are known.” Essentially, Tern is creating a Dockerfile that is locked at a point in time, where it translates these dynamic variables into static values, including ARG and ENV variables. This not only makes it possible to have an accurate bill of materials, said Kumar, but also create more reproducible Docker images from their Dockerfiles to recreate a build at a later point in time.
“Dockerfiles are typically written in a very imperative fashion, so it’s very difficult to rebuild the same container image that you built maybe a month ago using the same Dockerfile,” said Kumar. “What the lock feature allows you to do is to be able to reproduce your container build. It acts the same way as a pip freeze or a gem log, wherein you get the exact image digest that you used to build your first container image, and you also get the packages that are pinned to their versions.”
The primary way Tern builds the software bill of materials is by interacting with a package manager to determine what dependencies are included, but a second way is with extensions, which allow external file scanners to scan the container image. With this release, Tern can now map the output of the Scancode-toolkit file scanner to its data model, explained Kumar.
“You can use Tern and Scancode together to basically do a fine level analysis of a container image and then Tern will produce the reports in different formats,” said Kumar, explaining that the software bill of material format that it supports is like a birds-eye view of what the container image looks like, and is available in JSON, YAML, and SPDX, an open standard created by the Linux Foundation for communicating software bill of material information, including components, licenses, copyrights, and security references.
Although Tern has released Tern 2.0, Kumar noted that the project uses semantic versioning, and is still in alpha testing and not generally available. Looking ahead, Kumar said the project would be focusing on getting running on both Mac and Windows environments, as well as adding support for language package managers and adding support for multistage Docker builds.
The Linux Foundation and VMware are sponsors of The New Stack.
Feature image by Denny Müller on Unsplash.
