The ultimate guide to SBOM generation

/ SBOM, Uncategorized / By

In today’s complex digital landscape, ensuring the security and integrity of your software is more critical than ever. A key component in this process is the Software Bill of Materials (SBoM), a detailed inventory of all components within a software application. Whether you’re a seasoned cybersecurity professional or new to the field, understanding how to effectively generate and manage SBoMs is essential for safeguarding your software supply chain. This ultimate guide to SBoM generation will walk you through everything you must know. 

¿What is a SBoM file? 

SBoMs describe the inventory of software components and services and the dependency relationships between them. A complete and accurate inventory of all first-party and third-party components is essential for risk identification. SBoMs should ideally contain all direct and transitive components and the dependency relationships between them. 

A few high-level use cases for SBoM include:  

  • Product security, architectural, and license risk  
  • Procurement and M&A  
  • Software component transparency  
  • Supply chain transparency  
  • Vendor risk management 

SBoM Formats 

There are three standard SBOM formats: 

  • Software Package Data Exchange (SPDX) – while it was originally developed to improve license compliance, its original use case for open source license management has since expanded to include software supply-chain visibility and security. 
  • Software Identification (SWID) Tagging – with a first version published in 2009, SWID is a way to tag software with metadata that describes it. They were created to allow organizations to transparently track the software installed on their managed devices. The SWID standard describes a lifecycle for software tracking: a SWID tag is added to an endpoint during the installation of a software product and is removed through the product uninstallation process. While SWID contains the minimum seven elements required for SBOM, it does not offer the in-depth information provided by the other two formats. 
  • CycloneDX – the latest of the three formats, CycloneDX was released in 2017 by OWASP.  The standard has multiple use cases including inventory, identification of known vulnerabilities, integrity verification and much more. The standard extends beyond the local machine dependencies to include runtime service dependencies and it provides rich data beyond the seven minimum requirements of SBOM. 

 

SBoM Creation tools 

  • Syft: Syft is a CLI-based SBoM generation tool from Anchore, a software composition analysis (SCA) provider. Syft can generate SBoMs for container images, file system paths, and compressed archives. It’s capable of detecting the majority of package formats, including programming dependencies installed in C, C++, Dart, Go, Java, JavaScript, PHP, Python, Ruby, and Rust projects, among others. Syft also supports OS packages for Alpine (apk), Debian (dpkg), and the Linux kernel (ko/vmlinuz). Syft supports the SPDX and CycloneDX SBoM standards. 
  • CycloneDX Generator: CycloneDX also has its own SBOM generation tool, CycloneDX Generator (cdxgen). This is a fully-featured solution that supports the production of SBoMs for both source directories and container images. It supports a wide variety of programming languages such as: node.js, java, python, go Ruby… All output produced by the tool uses the CycloneDX format. This makes it interoperable with other ecosystem components that understand the CycloneDX specification.  

 

SBoM Generation using Syft (anchore/syft: CLI tool and library for generating a Software Bill of Materials from container images and filesystems (github.com)) 

Generating a Software Bill of Materials as part of the DevOps process is essential for securing the software supply chain. 

  1. Choose your SBOM generation tool – we’ll use Syft here 
  1. Download and install Syft 
  1. Determine the SBOM output format you need 
  1. Run Syft against the desired source: syft <source> -o <format> 

Steps: 

  1. Installation:  

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

  1. Validate installation 

syft version 

Once Syft is installed and available, creating an SBOM is simple. Syft supports multiple sources to scan when generating an SBOM using both the local filesystem and container images. 

3.a) Scanning Images 

To generate an SBOM for a Docker or OCI image – even without a Docker daemon, run: 

syft <image> 

By default, output includes only software included in the container’s final layer. To include software from all image layers in the SBOM, regardless of its presence in the final image, use the –scope all-layers option: 

syft –scope all-layers <image> 

3.b) Scanning the Filesystem 

To generate an SBOM for the local filesystem, use the dir: and file: prefixes with either absolute or relative paths. For example to scan the current directory: 

syft dir:. 

Or a specific file: 

syft file:/my-go-binary 

  1. Choosing output format 
  1. Cyclone DX format:  

syft <source> -o cyclonedx-json

  1.  SPDX format 

syft alpine:latest -o spdx-json 

 

Not sure which SBOM creation tool is right for your environment? Orbik Cybersecurity can assist you in the SBOM creation process. Reach out to us at info@orbik-cybersecurity.com. 

Get A Quote
Get A Quote