Create a Software Bill Of Materials (SBOM).

In simple terms, a Software Bill of Materials (SBOM) is like a detailed inventory list for software and IoT devices. It helps you understand what your software consists of, which is important for security, licensing compliance, and meeting regulatory standards.

Think of the SBOM as a formal record that contains all the information about the different components used to create a software product. At its core, it’s just a list of these components.

The SBOM is like a map that businesses can use to understand the software supply chain. Whether they create, purchase, or use software, the SBOM provides the necessary details to better understand what goes into the software.

The process of creating an SBOM begins when a development team selects a software component to include in their coding and building process. These components can be open-source software, third-party commercial libraries, or modules developed internally.

Select a format

The first step is to select an SBOM format. Which one to choose depends on your environment, tooling, the supply chain, and your partners and customers. There are several tools to transform between formats, so interoperability should not be a big issue.

 The two leading formats are:

  • SPDX, a project of the Linux Foundation, is “an open standard for communicating software bill of material information, including components, licenses, copyrights, and security references.”
  • CycloneDX, the OWASP project, is a “full-stack bill of materials” standard.

Content

What information should an SBOM document contain? The formats above are, as expected, thoroughly specified with structures, elements, and identifiers. In reality, SBOMs are not seldom a diverse set of automatically generated documents of poor quality containing elements with incorrect or contradictory data or unspecified mandatory information.

What shall the SBOM be used for? What shall we focus on?

  • To follow how the application/product develops continuously, you’ll need the information to identify the product and version.
Example from CycloneDX, json:
"component": {
"type": "library",
"name": "juice-shop",
"version": "11.1.2",
:

  • The SBOM is an excellent target for vulnerability scanning and other security-related checks. Then it’s essential to be able to identify each component with name, version, and type or vendor.
Example from CycloneDX, json:
{
"bom-ref": "pkg:npm/elastica@0.0.0?package-id=f3cf07f6b0de981a",
"type": "library",
"name": "elastica",
"version": "1.0.0",
"description": "Build tools for the Elastica extension.",
"cpe": "cpe:2.3:a:gigwell:elastica:1.0.0:*:*:*:*:*:*:*",
"purl": "pkg:npm/gigwell/elastica@1.0.0",
:

  • If you want to check for updates on the component, a reference to the software repository will be of great help.
Example from CycloneDX, json:
"externalReferences":
[ {
"type": "website",
"url": https://github.com/jshttp/content-type#readme
},
{
"type": "vcs",
"url": "git+https://github.com/jshttp/content-type.git"
} ]
:

  • To verify the license compliance before releasing the product. Then the license and copyright information is essential.

As you can see, the use case is an important starting point for deciding on the requirements for the content of your SBOMs.

Create an SBOM

Start creating your SBOMs:

  • Manually
  • SBOM generator tool
  • Build plugin
  • Dynamic tool

Manually

The most basic way to make an SBOM is to create a document manually, either through an online tool or just by editing a computer file. A manual process is simple but can be problematic for several reasons:

  1. Complexity and Scale: Modern software often includes hundreds or even thousands of components. Identifying and documenting each component, its version, its source, and its relationship to other components manually can be a gargantuan task.
  2. Error Prone: The manual process can be prone to errors due to oversight, data entry mistakes, or misunderstandings. These errors can then lead to problems like license non-compliance, overlooked vulnerabilities, or other security issues.
  3. Time-Consuming: Manually creating an SBOM can be incredibly time-consuming, which can delay other parts of the software development process.
  4. Inconsistency: Manual SBOM creation may lead to inconsistencies, especially if multiple people are involved in the process, each with their own interpretation of how to document components.
  5. Outdated Information: With the speed at which software development happens, manually created SBOMs can quickly become outdated if not continuously maintained.
  6. Lack of Standardization: There might be inconsistencies in the structure, format, or level of detail in the SBOMs created manually, which makes it hard to analyze and compare them.

For these reasons, automated processes for generating SBOMs are often the better choice. They can quickly and accurately identify and document software components, reduce errors and inconsistencies, save time, and keep up with the pace of modern software development.

Generator tools

The SBOM generator tool scans the application’s codebase and dependencies, assembling a comprehensive list of all components, including their versions. This list encompasses libraries, frameworks, and other third-party components.

There are various commercial Software Composition Analysis (SCA) tools that can be seamlessly integrated with CI/CD pipelines. These tools give a detailed view of all the software components and their dependencies. Alternatively, open-source tools can be used to generate SBOMs. These are often operated from the command line, making them ideal for projects that need to blend with existing CI/CD pipelines.

Open-source tools, examples:

  • Syft (https://github.com/anchore/syft)
  • Trivy (https://github.com/aquasecurity/trivy)
  • sbom-manager (https://pypi.org/project/sbom-manager)
  • sbom-tool (https://github.com/microsoft/sbom-tool)
  • CycloneDX CLI (https://github.com/CycloneDX/cyclonedx-cli)

Some tools (Syft and sbom-tool) can generate SBOMs from container images. Docker has an internal command to generate SBOMs (currently experimental).

Build plugins

Creating the SBOM at build-time with a plug-in as part of the build system creates the most accurate information about what goes into a binary. By using a plugin in your build environment, you can easily create SBOMs with every release of your binary as part of your CI/CD pipeline

For example, at the CycloneDX tools center (https://cyclonedx.org/tool-center) you can find build system plugins supporting most ecosystems.

A build plugin has several advantages:

  1. Automation: A build plugin can automatically generate an SBOM as part of the software build process. This removes the need for manual effort and significantly reduces the risk of human error.
  2. Accuracy: Build plugins are designed to accurately identify and record all the components in a software product, along with their relevant information, like version numbers, sources, and licenses.
  3. Efficiency: Generating an SBOM as part of the build process ensures that it’s always up-to-date, reflecting the current state of the software at the time of each build.
  4. Integration: Build plugins work directly with the build tools and environment that your development team is already using. This means they can be integrated into your existing software development lifecycle (SDLC) with minimal disruption.
  5. Consistency: Because the build plugin follows a predefined process to generate the SBOM, you can be assured of consistency in the SBOM’s format and content, regardless of changes in the software or the development team.
  6. Security: By integrating SBOM generation into the build process, you can more easily track and manage vulnerabilities linked to your software components. This leads to improved software security and can assist in meeting compliance requirements.

The process

A continuous and automated Software Composition Analysis (SCA) program can help your developers spot and fix security issues early in the software development process, preventing disruptions.

Automating the creation of Software Bills of Materials (SBOMs), checking them against your policies, and securely sharing them (along with any related security reports and certifications) can save time and reduce the chance of errors that can occur with manual work. The outcome? You get to innovate and bring products to market quicker, and you can provide accurate SBOMs to your supply chain partners.