What is an SBOM?

A software bill of materials (SBOM) is a list of components that make up your software applications. It includes all the components, libraries, and modules used within a software product, presented in a format that other software can read. Think of this as a list of ingredients that make up your software recipe. 

Explore Lightwell

Most modern software is built by assembling multiple pre-made, third-party components (like code libraries). When you weave a large number of components together, things can get complicated. 

Creating and maintaining an SBOM helps keep track of the versions, licenses, dependencies, and changes made to those components over time. An SBOM is a living document that acts as a source of truth, helping to identify and avoid security risks and satisfy compliance demands. 

By providing transparency into a product’s digital makeup, an SBOM is useful to people across every stage of the software lifecycle. This includes people who:

• Develop or manufacture software: Builders can make sure components are up to date and fit their needs.
• Select or purchase software: Buyers can evaluate risk before buying by analyzing the internal makeup of the software.
• Operate software: System administrators and IT teams can check their software against common vulnerabilities and exposures (CVE) lists.
• Use software: End users and consumers indirectly benefit from higher baseline security measures.

An SBOM lists every third-party component, library, and module in a software application, alongside the attributes that define them. Under standard industry frameworks, like the National Telecommunications and Information Administration (NTIA), an SBOM should at least include:

Component name and supplier name: The name of the software module and the entity, vendor, or open source maintainer that created it

Version number: The release or build version, which helps identify whether a specific piece of code carries a known flaw

Unique identifiers: Standardized reference keys (package URL of common platform enumeration) that help automated tools match components against global vulnerability databases. (This alerts you if any part of your code carries a known vulnerability.) 

Dependency relationships: A map showing how components fit together and what’s dependent on what 

Licensing information: The open source or commercial license that governs each piece of code (like the Apache 2.0 or MIT license)

Author and timestamp data: Metadata recording when the SBOM was created and who was responsible for generating it 

The United States Cybersecurity and Infrastructure Security Agency (CISA) has expanded on these requirements and released an updated list with additional guidance. 

SBOMs are created during the software build process. An SBOM is made with software composition analysis (SCA) tools that are integrated into continuous integration/continuous deployment (CI/CD) pipelines. This process uses automated scanning to identify, manage, and track open source packages and third-party components within a codebase, then exports that data into a machine-readable format. 

Deploying an SBOM means attaching the inventory metadata (descriptive data that identifies, labels, and tracks each component within a piece of software) to the software release so others can read it. 

You can locate an SBOM file in a repository where it should live alongside the compiled code binaries or container images. For commercial software, SBOMs are delivered to enterprise users through application programming interface (API) endpoints, customer portals, or directly to security teams.

An SBOM is a snapshot that can be viewed at any point in time but is constantly evolving. Every time a developer commits new code, updates a library, or pushes a new production build, a new SBOM version is generated. 

Maintenance also includes monitoring. Monitoring an SBOM means using dedicated management tools to continuously cross-reference what’s in the inventory with databases like the National Vulnerability Database (NVD). This setup alerts security teams when new vulnerabilities are discovered, so they can act quickly.

SBOMs are structured so automated tools can instantly scan software updates for vulnerabilities. This means they need to be formatted in a way that makes it easy for a machine to process. The main SBOM standards include:

CycloneDX (OWASP): With a focus on application security and real-time vulnerability management, CycloneDX is best for fast-moving DevOps teams who want lightweight solutions for their modern build pipelines. 

Software Package Data eXchange (SPDX): With a focus on open source license compliance and deep legal auditing, SPDX is best for corporate compliance officers and legal teams who are looking for the most detailed SBOM format. 

Software Identification (SWID): With a focus on software asset management (SAM) and endpoint inventory tracking, SWID is best for IT system administrators who want to track what commercial applications are installed on devices across a network. 

An SBOM organizes software dependencies (external, pre-written code that an application relies on to perform a task) into structured, searchable data, allowing for automated risk detection. Specifically, SBOMs improve cybersecurity response across several areas:

Zero-day response: When a major vulnerability happens (like Log4j or Heartbleed), teams can run a single query against their SBOM inventory to highlight every affected application in seconds. 

Continuous security monitoring: Scanners continuously cross-reference an SBOM against global vulnerability databases and automatically alert teams if a component becomes unsafe. 

Transitive dependency visibility: Software relies on components that rely on other components. This creates a series of layers and (transitive) relationships that need to be exposed in order to be analyzed. SBOMs can help map out these links and expose how connections fit together, which makes it easier to evaluate code.

Learn about Red Hat Advanced Cluster Security and SBOMs

A software composition analysis (SCA) tool analyzes software dependencies and generates an SBOM as part of that process. After the SCA creates the SBOM, the SCA continues to monitor the SBOM and query external databases to help scan for vulnerabilities.

Remember, the SBOM is a storage file—it doesn’t actively scan anything. The SCA does the heavy lifting and uses the SBOM as a source of information.

Read the documentation for Red Hat Trusted Profile Analyzer

SBOMs keep track of critical information and provide transparency, but there are some challenges to adopting them:

Tooling inaccuracies and missing information: Automated scanners aren’t perfect. They can miss deeply nested dependencies and obscured details, which can result in an incomplete software inventory. 

Alert fatigue: Security tools can flag non-critical vulnerabilities and overwhelm teams with false alarms. 

Inconsistent naming: Different tools and software vendors might name the same software library in different ways. This can make it more difficult for automated scanners to accurately identify and match components against vulnerability databases.

Vendor and intellectual property concerns: Some commercial software vendors may be fearful of publishing a complete SBOM for their clients because they don’t want to accidentally expose trade secrets or proprietary information. 

Lack of expertise: Interpreting the data and deciding how to act on vulnerabilities requires specialized DevSecOps knowledge. 

To make the most of what an SBOM can offer, teams need to adopt an approach that prioritizes automation and standardizes the software development lifecycle:

Automation and monitoring

• Integrate SCA tools directly into CI/CD workflows so SBOMs are automatically generated with every build. 
  • See how Red Hat uses AI agents to fix CI/CD pipeline failures
• Get in the practice of automatically generating an SBOM whenever software is updated, re-compiled, or re-packaged. Don’t rely on an outdated snapshot.
  • Learn how to secure your Jenkins pipeline with Red Hat Advanced Developer Suite
• Route generated SBOMs into automated vulnerability platforms that can continuously monitor components and look for matches against live security databases.
  • Learn how to send SBOMs to Red Hat Trusted Profile Analyzer for continuous monitoring
     

Standards, formats, and metadata

• Include minimum baseline elements in your metadata, like supplier name, component name, version number, and direct/transient dependencies.
• Attach standardized identifiers like Package URLs (PURLs), Common Platform Enumerations (CPEs), and cryptographic hashes to prevent naming ambiguity.
• Adopt industry-standard, machine-readable formats like CycloneDX or SPDX.
• Mandate JSON or XML formatting across internal products to make processing uniform.

Get a practical guide to software supply chain security

Storage, security, and governance

• Store each SBOM version in a repository (like JFrog Artifactory or GitHub Releases) and link it directly to its specific code release.
• Require cryptographic signatures when SBOMs are created and altered.
• Establish policies that automatically flag or reject third-party vendors who deliver software with incomplete or redacted data.
• Clarify operational ownership so each team (security, legal, DevSecOps) can monitor and access what it needs within the SBOM.

Read the documentation for Trusted Artifact Signer

Defending a software supply chain means having verifiable evidence that demonstrates how software was created and delivered.

When you’re integrating AI elements into the software supply chain, make sure to:

• Treat AI in CI/CD as a new principle with its own credentials and scope.
• Assume any text reaching an AI agent could be a prompt injection.
• Generate SBOMs and AIBOMs for every release, not just regulated ones.
• Use AI to scan for known patterns at scale.
• Name a security owner. “Everyone” means no one.

At the same time, make sure to avoid: 

• Treating AI-generated pull requests as low risk.
• Confusing “AI scanned it” with “a human reviewed it.”
• Skipping signatures.

Enhance supply chain security with Red Hat Trusted Artifact Signer

An AI bill of materials (AIBOM) extends the traditional SBOM to include details pertaining to model weights, training data sources, fine-tuning steps, and inference dependencies. If your project ships, embeds, or fine-tunes a model, you need an AIBOM. 

Organizations in a variety of industries can benefit from maintaining an SBOM. By turning code into manageable, transparent data, SBOMs are a critical means of defending against supply chain breaches and regulatory penalties. In many instances, they can also help build trust and collaborative efforts between multiple parties. Here are some examples of how SBOMs can help protect data:

Healthcare 

• The Health Insurance Portability and Accountability Act (HIPAA) requires continuous risk assessments for all systems handling Electronic Protected Health Information (ePHI). An SBOM provides the granular inventory needed to scan health IT software for vulnerabilities.
• Medical device manufacturers need to submit SBOMs to prove devices like pacemakers, infusion pumps, and MRI systems don’t contain vulnerable code before hitting the market. 

Finance

• Security teams for mobile banking and trading applications use SBOMs to monitor software components and protect customers from risks like financial fraud and personal data exposure. 
• When financial institutions onboard third-party vendors, like fintech partners and payment gateways, SBOMs help block risky, unvetted code from being integrated into core financial networks.

Government

• SBOMs help verify the origin and integrity of software deployed in military equipment and satellite systems. This information can defend against supply chain tampering and help government agencies locate software vulnerabilities that bad actors could otherwise exploit.
• SBOMs can be used to monitor components inside industrial control systems that power things like municipal water supply, energy grids, and transit networks. 

Technology

• Companies that sell Software-as-a-Service (SaaS) share SBOMs to speed up the security auditing process and get deals signed faster. 
• Scanning SBOM metadata during development can catch restrictive licenses before code is compiled and exposed to legal liability.

Creating and maintaining an SBOM is no longer optional for companies looking to compete in the global software economy. Regulatory frameworks like the European Union Cyber Resilience Act (EU CRA) require software supply chain transparency for all digital products sold in the EU. Under these regulations, manufacturers must report vulnerabilities to EU cybersecurity authorities within 24 hours. Maintaining automated SBOMs is the most practical way engineering teams can monitor their code fast enough to meet this deadline. 

As speed and transparency expectations rise from a regulatory perspective, the technology industry is working to keep pace. More specifically, we see this play out with:

Automated SBOM generation
Modern software development has outpaced any team’s ability to keep up with manual inventories. For that reason, organizations are investing in tools that automatically create SBOMs at every stage of the software build process. 

Continuous verification, auditing, and governance
Rather than treating an SBOM as a 1-time compliance checkpoint, industries are adopting SBOM-centric workflows to continuously govern their software supply chain. 

AI-driven automated vulnerability remediation
An SBOM can help you locate a vulnerability, but it cannot fix it. Historically, finding a vulnerability in your code meant taking an application offline and waiting for a community or team to patch it. Today, hackers use AI to exploit vulnerabilities faster than human developers can write fixes. To match this speed, industries are looking to AI to automatically identify risks and remediate them in real time. Often, this involves something called backported security patching.

Just as you might use a new piece of fabric to fix a tear in a jacket, backported patches use newer, stronger material to mend something broken. 

A backported security patch extracts a piece of code (that acts as a security fix in a newer version of software) and fits it into an older version of software. This solution is less disruptive than updating to a newer version and keeps software architecture more stable since no new features or API changes are introduced. 

Red Hat’s experience in creating, managing, and automating SBOMs allows us to help organizations safeguard their software supply chains and meet evolving compliance standards. Red Hat continues to advance software supply chain security through strategic security initiatives like Lightwell.

Lightwell is a joint initiative between Red Hat and IBM, focused on securing the open source software supply chain. It acts as a continuous delivery and trust verification layer for your SBOM. Lightwell uses AI-driven engineering to generate, validate, and deploy code fixes for open source code. It extends Red Hat’s proven model of enterprise open source maintenance by sending out backported security patches, signed compliant artifacts, and updated SBOM documentation without forcing version upgrades. 

Learn more about Lightwell