Keeping up with SBOM: SPDX, Syft and Grype

Aliza Adnan
6 min readNov 25, 2022

--

In the last few years, there’s so much development in the IT industry that every software needs to keep itself updated and release its version more frequently than ever before. Abiding by this need, the software becomes more prone to the threat of risks and vulnerabilities as it is using third party resources and containers to provide the customers with the best service. But what is it that brings us to the transparency of the supply chain in order to avoid cyber security threats? This question leads us to SBOM.

In this blog, I’ll be covering the following topics:

  1. Introduction to SBOM
  2. Introduction to SPDX
  3. Main functions of SPDX
  4. Introduction to ko
  5. ko Tutorial
  6. Introduction to Syft
  7. Syft Tutorial
  8. Introduction to Grype
  9. Grype Tutorial
  10. References

What is SBOM?

SBOM or Software Bill of Materials, is an inventory or a log of components and resources needed for an application or a software. It includes third party and open-source components such as dependencies, code, programming language frameworks and libraries in its list of ingredients in order to make the software viable, up-to-date and protected. It provides us with the complete lineage of where the components are coming from and where they are getting used or in other words, it comprises of a dependency tree of resources and components.

Now, in order to make SBOM usable and easy to read, a format or a standard is required according to which it remains consistent and uniform throughout the industry and this brings us to SPDX.

What is SPDX?

SPDX is an open standard managed by Linux for communicating SBOM information, including provenance, license, security, and other related information. It helps in maintaining the easy and the readability, or else a lot of time would be wasted in reformatting and understanding the SBOM information.

Taken from https://www.synopsys.com/glossary/what-is-spdx.html

Main functions of SPDX

Taken from https://www.linux.com/audience/iso-establishes-sbom-standard-for-open-source-development-with-spdx/

SPDX tries to achieve its objectives by:

  • Maintaining consistency and readability by standardizing a format for the supplier and consumer, thus preventing inefficiency and time, bandwidth and resource wastage in making the SBOM readable.
  • Raising awareness whenever it encounters issues with licenses of softwares or files used from other sources.

There are multiple libraries and tools that are used for SPDX based SBOMs, but here I’ll target ko for generating SBOMs for Go language.

Introduction to ko

ko is a fast image builder from containers and it also generates SPDX or CycloneDX formatted SBOMs by default.

ko Tutorial

You can install ko from its source by running this command. This command runs for Go 1.16+.

go install github.com/google/ko@latest

To generate SPDX or CycloneDX formatted SBOM with ko, we have to download and use cosign for it. Run the following command for building images and generating SBOM with ko by default:

cosign download sbom $(ko build ./cmd/app)

ko build ./cmd/app command build the image, pushes it and prints the resulting image digest to stdout. In this example, ./cmd/app must be a package main that defines func main(). The executable binary that was built from ./cmd/app is available in the image at /ko-app/app -- the binary name matches the base import path name -- and that binary is the image's entrypoint.

In simple words, this whole command builds the binary and puts it on top layer of base image, makes binary image as entry point and pushes it directly to the registry along with the SBOM from its binary. This command can be run without having Docker on your machine. Along with this, it shares the cache which means it will be reusing the build cache by default.

Now we have generated the SBOMs, but it becomes difficult to manually find the vulnerabilities from the provided information. To save the day, I present to you Syft and Grype!

Introduction to Syft

Syft is a CLI tool and Go library for generating a SPDX, CycloneDX or Syft’s own formatted Software Bill of Materials (SBOM) from container images and filesystems maintained by Anchore. It is exceptional for vulnerability detection when used with a scanner like Grype which sets it apart from ko. It can also create signed SBOM attestations(validation that SBOM comes from trusted source) using the in-toto specification.

Syft Tutorial

In order to install and use syft, execute the following command:

curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh -s — -b /usr/local/bin

/usr/local/bin should be writable by user or else you can choose any other directory.

To create an image with Syft, we can type in:

syft <image> -o <format>

Insert in the container name in place of <image>and the format in place of <format>such as cyclonedx-json, spdx-json etc.

Here comes the second part where we can test vulnerabilities within the produced image using Grype.

Introduction to Grype

Grype is a vulnerability scanner for container images and filesystems which works best when combined with Syft. The best part of Grype is that it doesn’t need to scan images again and again, we just need the SBOM file created by Syft(as shown above). It can find the vulnerabilities within the major operating system packages along with language-specific packages.

Grype Tutorial

We can install Grype by following command:

$ curl -sSfL 
https://raw.githubusercontent.com/anchore/grype/main/install.sh | sh -s -- -b /usr/local/bin

/usr/local/bin should be writable by user or else you can choose any other directory.

Now we can use Grype to find the insecurities within the image. By executing the following command, vulnerabilities will be listed along with their type, severity, available fixes etc.

Thus, keeping a SBOM is imperative to solve rapidly the security, license, and functional dangers that can go with open-source software use.

You can check out my other blogs on Supply Chain Security too!

--

--

Aliza Adnan

I am a data enthusiast and I sometimes write blogs on Artificial Intelligence and DevOps.