Open Source Summit + Embedded Linux Conference + OSPOCon 2021

A Software Bill of Materials or SBoM is a list of software components that comprise a software artifact, be it firmware, OS, a VM, and yes, a container. We can generate an SBoM for container images post build using image scanners like Claire, Trivy, Tern, and Syft. This method is not foolproof, however, as they rely on metadata existing in the container filesystem (such as package manifests) in order to report on them. If a container goes through a multistage build or tools like Docker-slim to reduce the attack surface of the container, all that metadata is gone. How do we get more accurate and consistent SBoMs for containers? We generate them at container build time. This talk demonstrates how we can do that with tools like Tern, Buildah, and the OCI specification. We will get back to the basics of building containers, learn about the OCI specification, and make a container builder which can generate an SBoM at build time.

Why should you care about this? Software Industry concerns like Software Supply Chain Security, Data and Legal compliance, and build repeatability, can be addressed with an SBoM. Although this is generally straightforward for software built from scratch, 99% of software used today relies on Open Source components. This is especially hard for container creators as containers are not patched, but rebuilt, are based on previously built containers, and are often exposed to the internet in order to make an application “work”. If the ecosystem could be repurposed to include accurate SBoMs at container build time, container developers will not need to rely on file level static analyzers or guess work in order to reason about the security and compliance posture and maintainability of their containers.