copyright & licensing

all content © VM (Vicky) Brasseur and licensed under CC BY-SA

📖 Software Bill of Materials (SBOM)

6 minute read

This is an excerpt from my upcoming corporate open source strategy book, being published by Pragmatic Bookshelf. All book excerpt content is early in the development process and therefore unedited; the errors are mine alone (and will be fixed before publishing 😉).

The rising awareness and use of software bills of materials may help to make your software composition analysis (SCA) process more streamlined and complete. According to both CISA and NTIA, a software bill of materials (SBOM) is defined as “…a nested inventory for software, a list of ingredients that make up software components.” When you receive a physical delivery of some sort, the bill of materials tells you what’s inside the box. Similarly, when you use software created outside of your organisation, the SBOM tells you what’s inside that software. The SBOM is a file that declares the software supply chain (SSC) for that specific piece of software.

The concept of an SBOM has been around for many years now, but it’s finally gaining mindshare and adoption as companies start to become aware of their software supply chains. This growth in mindshare and adoption got a big boost when US President Joe Biden released Executive Order (EO) 14028, which among other things mandates that vendors providing software to the United States government must start providing SBOMs as well as the software itself. While officially the scope of the EO is only companies working with the US government, in practice the EO was like a large rock thrown into a still pond. The ripple effects have inspired software providers around the world to start looking at their own software supply chains and investigate both receiving and creating SBOMs themselves. The NTIA, NIST, and CISA, despite being US Government agencies, have been hosting and fostering SBOM discussions with worldwide stakeholders. The SBOM guidance provided by these agencies therefore is largely applicable to software users and providers in any country on Earth.

An SBOM can contain a lot of information about each and every component in a piece of software’s supply chain, but the currently accepted minimum data for each component is a fairly short list:

  • Component name
  • Component supplier name
  • Component version
  • Other unique identifiers for the component: Software Identification Tags (SWID), Package Uniform Resource Locators (PURL), etc.
  • Component relationship to the software (dependency of…)
  • Author of the SBOM
  • Timestamp of SBOM creation

A provider can supply an SBOM in any number of different formats, including a file of comma-separated values (CSV) or an Excel spreadsheet. But while they can provide it in any format, there are two formats that are preferred and are best practice: SPDX, and CycloneDX. These appear to be winning the popularity race at the moment, but SBOMs and SSC awareness are rapidly evolving concepts, so perhaps some other format may take the lead at some point in the future.

SPDX is an open international standard (ISO/IEC 5962:2021) actively developed under the Linux Foundation. It defines a format for SBOM documents that are readable by humans and computers alike. Initially focused on gathering and communicating data necessary for copyright and license compliance, over the decade plus of its existence SPDX has grown to include all necessary data for a software supply chain. Here’s an excerpt from an example SPDX document:

{
  "SPDXID" : "SPDXRef-DOCUMENT",
  "spdxVersion" : "SPDX-2.3",
  "creationInfo" : {
    "created" : "2022-10-23T15:44:16Z",
    "creators" : [ "Person: Gary O'Neall", "Tool: spdx-maven-plugin" ],
    "licenseListVersion" : "3.18"
  },
  "name" : "examplemaven",
  "dataLicense" : "CC0-1.0",
  "documentDescribes" : [ "SPDXRef-example" ],
  "documentNamespace" : "http://spdx.org/documents/examplemaven-0.0.1",
  "packages" : [ {
    "SPDXID" : "SPDXRef-junit",
    "copyrightText" : "UNSPECIFIED",
    "description" : "JUnit is a regression testing framework written by Erich Gamma and Kent Beck. It is used by the developer who implements unit tests in Java.",
    "downloadLocation" : "NOASSERTION",
    "filesAnalyzed" : false,
    "homepage" : "http://junit.org",
    "licenseConcluded" : "NOASSERTION",
    "licenseDeclared" : "CPL-1.0",
    "name" : "JUnit",
    "originator" : "Organization: JUnit",
    "summary" : "JUnit is a regression testing framework written by Erich Gamma and Kent Beck. It is used by the developer who implements unit tests in Java.",
    "versionInfo" : "3.8.1"
  }, {
    "SPDXID" : "SPDXRef-log4jslf4jbinding",
    "copyrightText" : "UNSPECIFIED",
    "description" : "The Apache Log4j SLF4J API binding to Log4j 2 Core",
    "downloadLocation" : "NOASSERTION",
    "filesAnalyzed" : false,
    "licenseConcluded" : "NOASSERTION",
    "licenseDeclared" : "NOASSERTION",
    "name" : "Apache Log4j SLF4J Binding",
    "summary" : "The Apache Log4j SLF4J API binding to Log4j 2 Core"
  },

(excerpt from SPDX Examples, CC0)

CycloneDX is an open BOM standard developed and maintained by the Open Worldwide Application Security Project (OWASP) Foundation. Like SPDX, it’s readable by humans and computers. Unlike SPDX, CycloneDX provides BOM formats for things like hardware and operations as well as software. An excerpt from an example of a CycloneDX SBOM:

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.2",
  "serialNumber": "urn:uuid:699b6458-60da-4f52-b1b3-34915dc01eb6",
  "version": 1,
  "metadata": {
    "timestamp": "2020-08-03T01:28:52.765Z",
    "tools": [
      {
        "vendor": "CycloneDX",
        "name": "Node.js module",
        "version": "2.0.0"
      }
    ],
    "component": {
      "type": "library",
      "bom-ref": "pkg:npm/lhc-vdm-editor@0.0.1",
      "name": "lhc-vdm-editor",
      "version": "0.0.1",
      "description": "A code and file editor for VdM scans.",
      "licenses": [
        {
          "license": {
            "id": "Apache-2.0"
          }
        }
      ],
      "purl": "pkg:npm/lhc-vdm-editor@0.0.1",
      "externalReferences": [
        {
          "type": "website",
          "url": "https://github.com/CERN/lhc-vdm-editor#readme"
        },
        {
          "type": "issue-tracker",
          "url": "https://github.com/CERN/lhc-vdm-editor/issues"
        },
        {
          "type": "vcs",
          "url": "git+https://github.com/CERN/lhc-vdm-editor.git"
        }
      ]
    }
  },

(excerpt from CycloneDX BOM Examples, CC0)

Most of the FOSS and commercial tools for SCA will export your SSC to create an SBOM document formatted as SPDX, CycloneDX, or both. The communities who maintain each of the formats also provide software libraries to integrate SBOM creation functionality into internally developed SCA tools and processes. All of these options make it considerably easier to generate and share SBOMs in standardised formats that other organisations and processes can ingest and understand.

Using SBOMs isn’t easy (yet)

However here we hit a bit of a snag: While there’s a fair bit of support out there for generating SBOMs in a standard format, the ecosystem is playing catch-up on supporting ingestion or using of SBOMs. This means that even if your company’s software vendors do provide you with SBOMs (for which you may need to ask…sometimes repeatedly), you may not be able to do much with those documents beyond storing them in an online shared drive in case you need to search them manually. Of course, I write that today but this is yet another situation where the ecosystem is evolving so quickly that it may not be true tomorrow. Eventually, it will be possible to ingest externally-provided SBOMs into your SCA tooling and generate reports and alerts based upon them.

While SBOMs are a promising development in the software supply chain world, they’re not a magic wand that you can wave and make everything better and easy. Relatively few commercial software vendors provide SBOMs at this point, even if requested. SBOMs are nearly unheard of in the FOSS world, so at the moment almost no open source components will come with an SBOM document. The tooling concerns I mention just above don’t help the situation, but there’s also the problem of formatting and interoperability. Despite the existence of two well-developed and -considered SBOM formatting standards, it’s still common for many of the few SBOMs you’ll find to be either in a proprietary format or to be formatted as CSV or Excel. This picture is changing, but it hasn’t changed yet. In the meantime, those who wish to incorporate SBOMs into their SCA and SSC processes must deal with the growing pains of an evolving ecosystem.

The excerpt content is copyright © The Pragmatic Programmers, LLC and used with permission. All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form, or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior consent of the publisher.

All other content of the post is Copyright VM Brasseur and licensed under CC BY-SA.