As we know by now, “every company is a software company”, and it is a safe bet, that (almost?) all organizations rely on open source and third-party software, yet lack basic visibility into the quality, security or creator of the software components. This lack of transparency makes the software supply chains susceptible to attacks. To combat this, President Biden’s Executive Order on Improving the Nation’s Supply Chain recommended adopting Software Bill of Materials (SBOMs) as a way to identify and describe software components.

The concept of a “bill of materials” (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 at a later point in time defects are found in a specific part, the BOM makes it easy to locate affected products.

So how can we transfer this to the software development lifecycle and secure our software supply chain ?

A Software Bill of Materials (SBOM) is basically machine-readable metadata that shows the full list of “ingredients” contained in an application, detailing all the proprietary and open source libraries and the relationship across all components and dependencies — this inventory enables us to track and trace components used through the software supply chain and identify vulnerabilities.

SBOM Key Elements

The National Telecommunications and Information Administration (NTIA) defined the minimum elements for SBOMs as:

• identifying the supplier of the software component
• identifying details about the version of the component
• component unique identifiers
• any component dependency relationships
• a timestamp of when and by whom the SBOM report was created

Since SBOMs are intended to be shared across companies and communities, having a consistent format (that is both human and machine readable) with consistent content is required. Let’s look into existing SBOM-standards.

SBOM Specifications and Tooling

There are numerous standards for SBOM that organizations and the community work on. The NTIA guidelines approved CycloneDX , SPDX and SWID . These three specifications were developed by different open source projects and government agencies to solve use cases that precede the Executive Order. Although all three specs satisfy the minimum SBOM requirements, they differ in terms of process, output and scope of coverage. For a comparison, see Software Bill Of Materials: Formats, Use Cases, and Tools .

There are various tools to generate SBOMs for different programming language ecosystems, often provided by the SBOM-specification implementations, e.g. CycloneDX or SPDX, or the community.

Recently, Docker introduced experimental support for the docker sbom command, that aims to generate the SBOM for container images, which includes the operating system packages that are installed (for example, ca-certificates) along with language-specific packages that the software depends on (for example, Log4j).

Example UseCase with CycloneDX

As we wanted to continuously monitor our software supply chain with OWASP Dependency Track , the format required for our SBOM is CycloneDX .

The CycloneDX project provides specifications for the SBOM in XML, JSON, and Protocol Buffers, as well as a growing collection of official and community supported tools that create or interoperate with the standard: Maven, Gradle, Npm, Go mod, .NET, PHP, Rust,…

In our example we enable the SBOM generation for a Gradle project.

This is rather simple, just add the following plugin in your build.gradle:

plugins {
  ...	
  id "org.cyclonedx.bom" version "1.5.0"
}

After this, you can execute the task cyclonedxBom:

./gradlew cyclonedxBom

The SBOM is generated in JSON and XML format and written to build/reports/bom.json and build/reports/bom.xml as result.

Example bom.json:

{
  "bomFormat" : "CycloneDX",
  "specVersion" : "1.3",
  "serialNumber" : "urn:uuid:6ef3a830-edab-4edd-9385-58477ae8be76",
  "version" : 1,
  "metadata" : {
    "timestamp" : "2022-03-16T10:06:39Z",
    "component" : {
      "group" : "eu.attempto.lab",
      "name" : "some-project",
      "version" : "1.0.0-SNAPSHOT",
      "purl" : "pkg:maven/eu.attempto.lab/some-project@1.0.0-SNAPSHOT",
      "type" : "library",
      "bom-ref" : "pkg:maven/eu.attempto.lab/some-project@1.0.0-SNAPSHOT"
    }
  },
  "components" : [
    {
      "group" : "jakarta.activation",
      "name" : "jakarta.activation-api",
      "version" : "1.2.2",
      "hashes" : [
        {
          "alg" : "MD5",
          "content" : "1cbb480310fa1987f9db7a3ed7118af7"
        },
        ...
      ],
      "licenses" : [
        {
          "license" : {
            "name" : "EDL 1.0",
            "url" : "http://www.eclipse.org/org/documents/edl-v10.php"
          }
        }
      ],
      "purl" : "pkg:maven/jakarta.activation/jakarta.activation-api@1.2.2?type=jar",
      "modified" : false,
      "type" : "library"
    },
    ...

As you can see, the relevant data for the software and it’s dependencies is captured in the SBOM and can be now analyzed and continuously monitored by appropriate tooling.

Conclusion

SBOM are easy to generate and contain the relevant metadata about the software this SBOM belongs to, the tool that generated the SBOM itself and - most importantly - all the dependencies with version, hash and license information.

In the next article we analyze the generated SBOM with Dependency Track and show how to automate this process with Github Actions.