Security: The value of SBOMs

Project post originally published on Flux’s blog by Daniel Holbach

Flux – built with security in mind

You don’t get to re-architect a successful project very often, but we did about two years ago. The Flux project was already off to a great start and had many happy adopters and many of its design principles we kept at the forefront of our mind:

• Pull vs Push: if you haven’t read this great blog post from 2018 about why you want Pull – all it says still holds true.
• Least amount of privileges.
• Reusing best practises, libraries and tools, e.g. client-go and helm APIs.
• And more we will explain further down the line.

Why did we re-architect and rewrite Flux? Flux Legacy (v1) had been started Mid-2016 and while it worked great and still does, it didn’t quite benefit from more recent developments in the Kubernetes space like controller-runtime because it pre-dated them significantly.

Also rewriting Flux as a set of very targeted controllers was a unique opportunity to reduce the scope (and thus attack surface) of these individual sub-projects and make testing and debugging a lot easier. Re-usability as well.

All of this said, we believe that a blog series about Flux and its security considerations and features is in order and we will kick it off talking about SBOMs.

What is a SBOM?

Since Flux release 0.26 we publish a SBOM for each of the individual controllers. We reported about this in the accompanying monthly update blog post.

So what is a SBOM? It’s short for Software Bill of Materials. Wikipedia defines it as

A software bill of materials (SBOM) is a list of components in a piece of software. Software vendors often create products by assembling open source and commercial software components. The SBOM describes the components in a product. It is analogous to a list of ingredients on food packaging: where you might consult a label to avoid foods that may cause allergies, SBOMs can help organizations or persons avoid consumption of software that could harm them.

The concept of a BOM is well-established in traditional manufacturing as part of supply chain management. A manufacturer uses a BOM to track the parts it uses to create a product. If defects are later found in a specific part, the BOM makes it easy to locate affected products.

For the Flux project we publish a Software Bill of Materials (SBOM) with each release. The SBOM is generated with Syft in the SPDX format.

The spdx.json file is available for download on the GitHub release page e.g.:

curl -sL https://github.com/fluxcd/flux2/releases/download/v0.25.3/flux_0.25.3_sbom.spdx.json | jq

Inspecting the JSON data, you will see that for each of the files and libraries required for building and shipping the release you can verify the license, origin, version and checksum.

What might seem like a lot of overhead and unnecessary bookkeeping, quickly turns out as useful information because it allows you to

• Verify the origin and integrity of artifacts
• Inspect the dependencies easily for CVEs and known security issues
• Get a holistic view of your complete supply chain, so which other dependencies and Open Source projects now become part of your stack

Because it is structured data, all of the above can be done in an automated, programmatic fashion.

Big organizations, corporate or governmental, already keep track of SBOMs and make decisions based on the information provided there. Some started requiring SBOMs for software in-use. A good example of this is the government of the USA requiring SBOM from software suppliers.

Possible use-cases for SBOMs

Here are a couple more concrete examples of what the SBOMs for Flux allow you to do:

• Security alerts of dependencies will be the most obvious use-case. If a CVE is detected, you can inspect your SBOM and see if the components you are using are in any way affected.
• It will be easy to identify when a certain component was created and how. In addition to that, having the licensing information of all the pieces, you better know what you can do with it (redistribute, change, etc).
• Automation allows you to send alerts, if a compliance issue is detected, e.g. if the licensing of updated/replaced dependencies changes.
• Missing components or required build files. Incompatible licenses and more.

One example of automating all of this could be to store SBOMs in https://grafeas.io/. This way you could search across your Estate for:

• Images that are built from a particular Github commit that is known to have introduced a security problem.
• Find all images that were built by a certain version of a certain builder when that builder is known to have been compromised.
• Find all images in my project that are impacted by CVE-1234.

For policy enforcement, kritis can be used to leverage the information provided by SBOMs inside Grafeas to enforce policies inside of a cluster, enabling auto-blocking of applications that are vulnerable to a specific CVE for example.

If you have read this far and you are using SBOMs in your organisation, let us know what you get out of them as well!

What’s more

If you would like to know more about the history of SBOMs and their development, you might want to read this excellent article from ChainGuard about the subject.

At the time of writing this, Syft does not yet classify licenses based on the file contents, but it is being considered.

Here is the table of SBOMs for all the latest Flux controllers and CLI (as of 2022-02-09).

This is just one more measure we are taking to keep you more secure.

Talk to us

We love feedback, questions and ideas, so please let us know how you are using SBOMs today. Ask us if you have any questions and please

• join our upcoming dev meetings
• find us in the #flux channel on CNCF Slack
• add yourself as an adopter if you haven’t already

See you around!