SBOM Key Concepts

SBOM Automation

Your First Step On Your Cybersecurity Journey

What is SBOM Automation

SBOM (Software Bill of Materials) automation is the process of automatically generating a list of all the software components, libraries, and dependencies that make up a software application as part of your DevOps Pipeline and then consuming the data. Each time an object is rebuilt, a new SBOM becomes available. SBOM automation involves creating a step in your DevOps process that regenerates an SBOM for each new build and then consumes that information to track new open-source package usage, new licenses, and to highlight common vulnerabilities and exposures (CVEs).

Challenges with SBOM Automation

By now, most of us have heard about the importance of Software Bill of Material reports. From the May 2021 Biden Administration’s Executive order on SBOMs to security statistics coming from Sonatype’s “State of the Software Supply Chain,” the data is clear. According to Sonatype’s State of Software Supply Chain report, since 20221, the annual growth rate of malicious software supply chain attacks is an astonishing 742%. Automating the generation of SBOMs and consuming the SBOM data must be part of the DevOps pipeline.

SBOM automation must be included as part of your CI/CD workflow. The steps for adding SBOM generation to one workflow are fairly straightforward. But adding SBOM automation to every workflow is a much bigger task. If you are an enterprise with hundreds of workflow files, every single one will need to be modified. And what do you get from that effort? You get an SBOM that sits in the build directory, and you can check off a security box. So is updating every workflow worth it? Well, many teams would call this busy work. If the data from the SBOM is not consumed or used, is SBOM automation worth it?

Consumption of SBOM Automation Data

The information derived from an SBOM is a critical first step in understanding your software security profile. This is why SBOM consumption is essential. The SBOM exposes the open-source packages with attributes that are consumee and delivered to end users. But generating an SBOM alone does not provide you insights. The data must be consumed with SBOM management. To act upon the SBOM data, you need a collection and historical tracking method. This collection and historical tracking should be continuous, auditing every update to every version and the impact of those changes.

Using DeployHub and the Ortelius Command Line Interface for SBOM Automation

DeployHub is a unified ‘evidence store’ of all your security and DevOps intelligence resulting from your CI/CD process. It continually collects critical information, such as SBOMs, each time a new artifact is pushed across the pipeline. To continuously gather pipeline intelligence, DeployHub must become part of your pipeline. When you update your workflow to generate SBOMs, you can add DeployHub to collect and consume the data. Once centralized, DeployHub leverages the SBOM information to generate real-time CVEs. It can also aggregate your microservice SBOMs up to the ‘logical’ application level, a critical security requirement in a cloud-native architecture.

DeployHub integrates into your CI/CD process using the Ortelius Open-Source Command Line (CLI). The Ortelius CLI gathers supply chain data based on a single pipeline workflow at the build and deploy steps. The build step gathers Swagger, SBOM, Readme, licenses, Git data, Docker image, and other build output. The deploy step records when a release occurs, what was sent, and where the objects were sent to.

The Ortelius CLI is maintained by the Ortelius Open Source Community under the governance of the Linux Foundation’s Continuous Delivery Foundation.

For the most up-to-date information on the Ortelius CLI, visit the Ortelius GitHub Repository. You will find a complete list of parameters for collecting Swagger, SBOM, and other tool reports and results.

Using the Ortelius CLI Data Gathering .toml

The Ortelius CLI reads from a .toml file. The .toml file contains non-derived information for each artifact that you create at your build step. In DeployHub, an artifact is referred to as a Component.  A Component is a Container, DB Object, or file object (.jar, Lamda Function, Apex file, etc.). The .toml file will provide the ‘non-derived’ data for the Component you are tracking in DeployHub, which includes the Component name, owner, Component type, and owner contact details.  The Ortelius CLI will read the .toml file from the Git Repository associated with your pipeline. You will need a separate Component if you use a Mono Repository for your entire codebase.toml file for each Component managed in sub-directories.

In a cloud-native microservice architecture, there are many, if not hundreds, of Components. Organizing your Components within DeployHub is done in two ways. They are grouped based on a subject Domain and assigned to a logical Application. Not all Components need to be assigned to an Application, but they should be stored in a subject matter Domain so they can be easily found and reused.

A logical Application is a collection of Components that make up a complete software system consumed by an end user. Applications are composed of shared Components and Application specific Components, and are a logical representation of what Components need to be deployed for the software system to run.

Note: Once created, your .toml file does not need to be updated unless the non-derived information changes or you want to reorganize to which Applications or Domains the Component has been assigned. For example, a Component has been reassigned to a new owner and new team represented by a Domain or Application.

Perform the following steps to add your Components using the .toml file:

Step 1 – Define Your DeployHub Pipeline Variables

The following variables should be set at the beginning of your Pipeline for your SBOM Automation:

Variable Value Description
DHURL URL to DeployHub Login The URL used to access DeployHub
DHUSER UserID The ID used to log into DeployHub
DHPASS password The password used to log into DeployHub. This can encrypted based on the CI/CD solution.
DOCKERREPO Name of your Docker Repository For Components that are Docker Images. Not needed for non-docker objects.
IMAGE_TAG Tag for the Docker Image if used For Components that are Docker Images. Not needed for non-docker objects.


# Application Name and Version
Application = “GLOBAL.Santa Fe Software.Online Store Company.Hipster Store.Prod.helloworld app”
Application_Version = “1”
# Define Component Name, Variant and Version
Name = “GLOBAL.Santa Fe Software.Online Store Company”
Variant = “${GIT_BRANCH}”
Version = “v1.0.0.${BUILD_NUM}-g${SHORT_SHA}”
# Key/Values to associate to the Component Version
DockerBuildDate = “${BLDDATE}”
DockerRepo = “${DOCKERREPO}”
DockerSha = “${DIGEST}”
DockerTag = “${IMAGE_TAG}”
DiscordChannel = “”
ServiceOwner= “${DHUSER}”
ServiceOwnerEmail = “[email protected]

Step 2 – Create your Component.toml file

Cut and paste the following into a component.toml file to perform you SBOM Automation. Update ‘your’ information, and commit/push it to your Git Repository.

# Application Name and Version – not required. If not used the Component will not be associated to an Application
Application = “GLOBAL.”your Application Name”
Application_Version = “your Application Version”
# Define Component Name, Variant and Version – required
Name = “GLOBAL.your Component Name”
Variant = “${GIT_BRANCH}”
Version = “vyour Component Version.${BUILD_NUM}-g${SHORT_SHA}”>
# Key/Values to associate to the Component Version
DockerBuildDate = “${BLDDATE}”
DockerRepo = “${DOCKERREPO}”
DockerSha = “${DIGEST}”
DockerTag = “${IMAGE_TAG}”
DiscordChannel = “your Discord channel” or SlackChannel = “your Slack Channel”
ServiceOwner = “${DHUSER}”
ServiceOwnerEmail = “your Component Owner Email”


export DHURL=
export DHUSER=Stella99
export DHPASS=chasinghorses
export IMAGE_TAG=1.0.0

Note: For SaaS users, you will have a second high-level qualifier that was created as part of your sign-up. This second high-level qualifier must be used as the start of your Application Name and Component Name.  For example: GLOBAL.Santa Fe Software.Online Store.

Step 3 – Add a step in your pipeline to run Syft for your SBOM Automation (Optional)

DeployHub can consume any SPDX and CycloneDX formatted SBOM. If you are already generating SBOMs, you will pass the name of the SBOM results to DeployHub is step 4 below. If you are not generating SBOMs as part of your pipeline process, you will need to add SBOM generation to collect the lower dependency data. Following is how to add Syft to your workflow to include the collection of SBOM data.

Syft SBOM will generate Software Bill of Material Reports for popular coding languages and package managers, including Docker images.


The following code example scans a Docker Image to generate the SBOM.  See Syft Options to scan other objects and coding languages.

# install Syft
curl -sSfL | sh -s — -b $PWD
# create the SBOM
./syft packages $DOCKERREPO:$IMAGE_TAG –scope all-layers -o cyclonedx-json > cyclonedx.json
# display the SBOM
cat cyclonedx.json

Step 4 – Run the Ortelius CLI to add Your Component and Create an Application.

To complete the process, you will need to install the Ortelius CLI where your CI/CD server is running. Refer to the Ortelius GitHub CLI Documentation for installation instructions. Execute the following calls to the Ortelius CLI as part of your workflow. It should be called after the build and SBOM generation:


With CycloneDX SBOM

dh updatecomp –rsp component.toml –deppkg “cyclonedx@name of your SBOM file”
dh updatecomp –rsp component.toml –deppkg “[email protected]


dh updatecomp –rsp component.toml –deppkg “spdx@name of your SBOM file. “

dh updatecomp –rsp component.toml –deppkg “[email protected]

Without SBOM

dh updatecomp –rsp component.toml


Once you have completed the above steps, you should see the following results:

1 – The Hello World Application shows one Dependency.

application component dependency versions SBOM Automation
2 – The HelloWorld Application Level SBOM and CVE results. Note: CVE Results may vary depending on the time of the scan.

application SBOM Automation with CVE

3 – Component Ownership and Detailmicroservice ownership
4 – Package Search Results

open-source package search

package search results

Start Automating SBOM Generation Today

Signup for DeployHub Team and Start Automating SBOM Generation Today for Free

Signup for DeployHub Team, the free SaaS software supply chain security platform. DeployHub Team is based on the Ortelius Open-Source project incubating at the Continuous Delivery Foundation.

Signup Today

Learn More SBOM Key Concepts

SBOMs and Cybersecurity

SBOMs play a key role in solving the cybersecurity challenge. Learn why generating SBOMs is essential to harden the software supply chain.

SBOM Management

SBOM management collects Software Bill of Material reports as they are generated across the DevOps pipeline with data aggregation.

SBOM Consumption

SBOM consumption is the process of analyzing and utilizing the data contained within an SBOM document.

Understanding SBOMs

Software Bill of Material has finally been recognized as an essential tool in the security toolbox. In this article, we review what to know about Software Bill of Materials.

SBOM Requirements

Learn the US Government’s SBOM requirements and how DeployHub can generate a federated SBOM in a decoupled environment to meet the standards.

Suggested Reading

This 4-step Proof of Concept guide will provide you with the information needed to implement the DeployHub open source software supply chain management catalog with SBOM generation into your CI/CD Pipeline.

Getting Started with DeployHub Team SaaS

Further Reading