How do you know what’s changing in a new bootc (Bootable Container) image?
Since bootc is a standard OCI/Docker container image, it is simple to use container tooling to generate a Software Bill of Materials (SBOM). This can show changes with the software versions inside the container image.
What is an SBOM?
From Wikipedia:
A software bill of materials (SBOM) declares the inventory of components used to build a software artifact, including any open source and proprietary software components. It is the software analogue to the traditional manufacturing BOM, which is used as part of supply chain management.
Generate SBOM from bootc image
I like using the open source tool Syft to easily generate the SBOM. It’s as easy as running it from a Podman/Docker container or directly running syft after installing the binary:
syft scan -o syft-json="./sbom/fedora41-20250221.sbom.json" docker:bootc-fedora41Now you have an SBOM file as json for the newly created bootc image.
Parse SBOM using jq
Using a tool like jq to parse the json, a simple csv file can be created with some useful data pulled out from of the SBOM:
jq -r '.artifacts[] | select( has("name") == true) | [ .name, .version, .type ] | @csv' "./sbom/fedora41-20250221.sbom.json" | sort -u > "./sbom/fedora41-20250221.sbom.json.csv"Side note: You are missing out if you don’t use jq.
See changes from previous bootc image
Then simply run the diff command with the previous bootc image’s SBOM to see what’s changed, for example:
# diff fedora41-20250120.sbom.json.csv fedora41-20250221.sbom.json.csv || true
< "kernel","6.12.9-200.fc41","rpm"
< "kernel-core","6.12.9-200.fc41","rpm"
< "kernel-modules","6.12.9-200.fc41","rpm"
< "kernel-modules-core","6.12.9-200.fc41","rpm"
---
> "kernel","6.12.15-200.fc41","rpm"
> "kernel-core","6.12.15-200.fc41","rpm"
> "kernel-modules","6.12.15-200.fc41","rpm"
> "kernel-modules-core","6.12.15-200.fc41","rpm"Fun note about diff: adding "|| true" to the end of the command, always returns an exit code of 0 since diff returns a non-zero exit code when there’s a difference, which could break your image building pipeline, etc.
Conclusion – bootc SBOM
Using the open source tool Syft, an SBOM is created from a bootc image. Then jq can parse the SBOM and diff shows what’s changed from a previous image. Now you know what is changing when you upgrade your server using a new bootc image. Bonus points if you publish this SBOM/diff csv as an artifact and then also automatically compare the previously built bootc image.
Another benefit (and arguably the main purpose) of creating SBOMs is to know what vulnerabilities exist in the software packages. Since possibly hundreds of my Linux servers were created using the same bootc Docker image, I can simply scan one SBOM using another open source tool called Grype (which is from the company Anchor, the same company that created Syft). Now I’ll know all the software vulnerabilities of every server using that bootc image.