Software Bill of Materials (SBOM), What It Is and Why It Is So Important

Over time, having a reliable Software Bill of Materials (SBOM) has
become a fundamental part of the security strategy of DevSecOps teams.
Why? That’s the topic we are going to address in this article.

What is an SBOM

Let’s start by defining what an SBOM is. In simple terms, a Software
Bill of Materials (SBOM) is a structured list that includes all the components, libraries, and modules used to compile an application
Moreover, the SBOM should also include the supply chain relationships between those components, whether open-source or proprietary, free or paid.

Although the definition SBOM seems simple, in practice, it’s used in a much broader context.

Today, it has become a priority that SBOMs can be shared frictionlessly between teams and organizations as a fundamental part of software management transparency. This transparency is not only supported by the ISO through its OpenChain Specification, but it’s
also part of an effort to improve security in the digital industry, as evidenced by the 2021 Cyber Security Executive Order signed by President Biden.

You may be wondering, why all the fuss over something like a list of components? This is exactly the point we will discuss below.

Why is an SBOM so important?

Beyond complying with the recent Executive Order related to cybersecurity, actively using an auditable SBOM that uses zero-trust technologies is in the best interests of the software supply chain.

Today, developers and organizations are reusing an increasing number of both open-source and proprietary components in their applications. This complexity has been a cause for alarm for some time now since
identifying each software component is crucial to understand if there may be a vulnerability in it. This is because "one bad apple can spoil the bunch", as evidenced by the high-profile hacking of SolarWinds.
In this sense, SBOMs are an invaluable tool, as they allow an audit of licenses, libraries, modules, applied patches, and other components for weaknesses. However, for such an audit to reliably trace the components used to build the software, the SBOM must have certain attributes.

  • Unique identities for each software component

  • Separate identities (independent of those used internally in the
    organization) to identify each machine and user involved in the
    development process

  • Timestamps to facilitate traceability of each change or component

Additionally, from a security point of view, a key element for the reliability of the SBOM is to prevent "unauthorized changes" on it. And the most effective way to do this is by using an immutable ledger that records a history of when each change was made. Once the
reliability of SBOM is assured, DevSecOps teams can use it as part of their threat scanning toolbox and therefore improve software security.

SBOM open Standards (SPDX, CycloneDX)

Having established the importance of SBOMs, it remains to discuss how to implement them. A decade ago, developers did not have the infrastructure to facilitate the analysis of software components or the collaboration tools that we have today. This led to the creation of specifications,
the two most outstanding being the Software Package Data Exchange (SPDX) backed by the Linux Foundation and the CycloneDX specification managed by the CycloneDX Core working group, which has its origins in the Open Web
Application Security Project
(OWASP) community.

SPDX Standard

The SPDX provides a standard language that can be used to communicate key components such as licenses, copyrights, and security information
related to the various software components. Moreover, thanks to this specification, developers and organizations can associate SPDX documents
to a specific software component or group of components. For this, they can use different formats or even a code snippet.

The enormous flexibility of the SPDX specification for sharing critical software component information recently earned it the status of an internationally recognized standard for SBOM, which
demonstrates its undeniable relevance.

CycloneDX Specification

The CycloneDX specification defines itself as "a lightweight softwarebill of materials (SBOM) standard designed for use in application security contexts and supply chain component analysis".

In this sense, while the SPDX standard provides a format that facilitates the communication of third-party and open-source software components, CycloneDX provides the tools to analyze the SBOM for potential vulnerabilities. In other words, the CycloneDX specification
addresses the safety aspect of SBOM components – undoubtedly crucial for DevSecOps teams.

How to create an SBOM of an existing project

Manually creating a Software Bill of Materials is a daunting task.
Fortunately, there is both open-source and proprietary tooling that can help you generate an SBOM conveniently.

This is possible since most of the open-source (and proprietary) components used in today’s cloud-native applications have metadata files that use the SPDX format.
This makes it possible to automate actions that generate or update the SBOM as you can do with the Codenotary Cloud CLI (vcn bom).

Another alternative is to use state-of-the-art solutions to protect your software development pipeline from supply chain attacks like the one offered by CodeNotary, which is 100% compatible with CycloneDX and SPDX.
Furthermore, CodeNotary has integrations for Go and Java that allow it to collect dependencies from existing software binaries to recreate a BOM making it even easier to generate a reliable SBOM for your project.

What to keep in mind with new projects

Throughout this article, the importance of SBOMs for software security has been emphasized. To this end, it is essential to bear in mind some key aspects when starting new projects:

  • Understandably, the pressure to deliver frequent releases justifies reusing software components in your project. However, initiatives such as those undertaken by the government make it more important than ever to reuse components that meet accepted specifications,
    such as SPDX and CycloneDX.

  • It is in the best interest of your organization to adopt a holistic approach to SBOMs, as they have gone from being a legal formality to avoid licensing issues to a key component in detecting software vulnerabilities.

  • When choosing tools to implement SBOM in your organization properly, keep in mind that solutions like CodeNotary not only provide you with a tamper-proof SBOM to secure your software supply chain but also allow you to immutably track all changes in your software pipeline and even add important evidence files (i. e. vulnerability scanner results) thanks to its tamperproof immutable ledger.

Start a free trial and start protecting your DevOps process to:

  1. Massively reduce time (from days to minutes) to find and elimate unwanted code, dependencies, or container images

  2. Comply with the Cybersecurity Executive Order

  3. Instantly answer the question where a certain artifact has been used or is currently being used.

Codenotary Cloud


Trusted CI/CD, SBOM and artifact protection with cryptographic proof. One CLI to manage all.
Our highly scalable service already processes tens of millions of transactions every single month.


Subscribe to Our Newsletter

Get the latest product updates, company news, and special offers delivered right to your inbox.

Subscribe to our newsletter

Use Case - Tamper-resistant Clinical Trials


Blockchain PoCs were unsuccessful due to complexity and lack of developers.

Still the goal of data immutability as well as client verification is a crucial. Furthermore, the system needs to be easy to use and operate (allowing backup, maintenance windows aso.).


immudb is running in different datacenters across the globe. All clinical trial information is stored in immudb either as transactions or the pdf documents as a whole.

Having that single source of truth with versioned, timestamped, and cryptographically verifiable records, enables a whole new way of transparency and trust.

Use Case - Finance


Store the source data, the decision and the rule base for financial support from governments timestamped, verifiable.

A very important functionality is the ability to compare the historic decision (based on the past rulebase) with the rulebase at a different date. Fully cryptographic verifiable Time Travel queries are required to be able to achieve that comparison.


While the source data, rulebase and the documented decision are stored in verifiable Blobs in immudb, the transaction is stored using the relational layer of immudb.

That allows the use of immudb’s time travel capabilities to retrieve verified historic data and recalculate with the most recent rulebase.

Use Case - eCommerce and NFT marketplace


No matter if it’s an eCommerce platform or NFT marketplace, the goals are similar:

  • High amount of transactions (potentially millions a second)
  • Ability to read and write multiple records within one transaction
  • prevent overwrite or updates on transactions
  • comply with regulations (PCI, GDPR, …)


immudb is typically scaled out using Hyperscaler (i. e. AWS, Google Cloud, Microsoft Azure) distributed across the Globe. Auditors are also distributed to track the verification proof over time. Additionally, the shop or marketplace applications store immudb cryptographic state information. That high level of integrity and tamper-evidence while maintaining a very high transaction speed is key for companies to chose immudb.

Use Case - IoT Sensor Data


IoT sensor data received by devices collecting environment data needs to be stored locally in a cryptographically verifiable manner until the data is transferred to a central datacenter. The data integrity needs to be verifiable at any given point in time and while in transit.


immudb runs embedded on the IoT device itself and is consistently audited by external probes. The data transfer to audit is minimal and works even with minimum bandwidth and unreliable connections.

Whenever the IoT devices are connected to a high bandwidth, the data transfer happens to a data center (large immudb deployment) and the source and destination date integrity is fully verified.

Use Case - DevOps Evidence


CI/CD and application build logs need to be stored auditable and tamper-evident.
A very high Performance is required as the system should not slow down any build process.
Scalability is key as billions of artifacts are expected within the next years.
Next to a possibility of integrity validation, data needs to be retrievable by pipeline job id or digital asset checksum.


As part of the CI/CD audit functionality, data is stored within immudb using the Key/Value functionality. Key is either the CI/CD job id (i. e. Jenkins or GitLab) or the checksum of the resulting build or container image.

White Paper — Registration

We will also send you the research paper
via email.

CodeNotary — Webinar

White Paper — Registration

Please let us know where we can send the whitepaper on CodeNotary Trusted Software Supply Chain. 

Become a partner

Start Your Trial

Please enter contact information to receive an email with the virtual appliance download instructions.

Start Free Trial

Please enter contact information to receive an email with the free trial details.