What Is a Software Bill of Materials (SBOM)? A Practical Guide for Developers

Modern software is rarely built entirely from code written by one development team.

A typical application may depend on dozens or even hundreds of external libraries, frameworks, open-source packages, container images, and third-party components. Some dependencies are installed directly by developers, while others are pulled in automatically by the packages they use.

This makes software development faster, but it also introduces a security challenge: Do you actually know what components are inside your application?

Imagine that a security vulnerability is discovered in a popular open-source library. Your team needs to determine whether any of your applications use the affected version.

If you have a clear inventory of your software components, identifying affected applications becomes much easier. Without one, developers may need to investigate repositories, dependency files, container images, and deployment environments manually.

This is where a Software Bill of Materials (SBOM) becomes useful.

An SBOM provides a structured inventory of the components that make up a software product. It helps development and security teams understand their software dependencies, identify potential risks, and respond more effectively when vulnerabilities are discovered.

In this guide, we will explore what an SBOM is, how it works, why it matters, and how developers can generate one for their own projects.

1. What Is a Software Bill of Materials (SBOM)?

A Software Bill of Materials (SBOM) is a formal, structured record describing the software components used to build or deliver an application.

Think of it as an ingredient list on a food package.

A food label tells you what ingredients are inside a product. Similarly, an SBOM tells you which software components are included in an application.

For example, a Node.js application might contain:

• Express.js
• Axios
• Lodash
• JSON Web Token libraries
• Database drivers
• Other third-party dependencies

However, the inventory should not stop at packages explicitly installed by developers. It should also account for transitive dependencies, which are the packages required by other packages.

An SBOM can include information such as:

• Component name
• Component version
• Software supplier or publisher
• Unique component identifiers
• Dependency relationships
• Component licenses
• SBOM author and generation information

The exact fields depend on the SBOM format and the applicable requirements.

The goal is to create a machine-readable inventory that can be shared, analyzed, and maintained throughout the software lifecycle.

2. Why Does SBOM Matter?

Modern applications rely heavily on external software components.

A single application may contain hundreds of dependencies, making it difficult to track every component manually.

This becomes particularly important when a new security vulnerability affects a widely used package.

Consider the following scenario.

Your engineering team maintains several services. Each service uses different versions of the same open-source library.

A security advisory announces that version 2.4.0 contains a critical vulnerability.

Without an accurate dependency inventory, the team must investigate each repository and determine which services are affected.

With SBOMs, the team can search the component inventory across its applications and identify potentially affected versions more efficiently.

There are several important benefits.

Vulnerability Management

SBOMs help security teams identify which applications contain a vulnerable component.

When a new vulnerability is disclosed, the inventory can be used to identify applications that require further investigation.

This can reduce the time needed to understand the potential impact of a security issue.

Software Supply Chain Visibility

An application may depend on software maintained by many different organizations.

SBOMs provide visibility into these relationships, helping organizations understand where their software components originate.

This is particularly useful when evaluating third-party software, open-source dependencies, and externally maintained packages.

License Compliance

Open-source components are distributed under different licenses.

Some licenses have conditions that organizations must understand before using or distributing software.

An SBOM can help identify component licenses and support the legal and compliance review process.

However, the presence of license information does not automatically establish that a product is compliant. The applicable license terms still need to be evaluated.

Incident Response

When a vulnerability or supply chain incident occurs, teams need to understand which applications may be affected.

An up-to-date SBOM provides a starting point for investigation instead of relying entirely on manual dependency discovery.

3. What Information Does an SBOM Contain?

An SBOM is more than a simple list of package names.

It provides structured information that allows tools to identify components and understand how they relate to one another.

For example, consider a simplified dependency structure:

my-application
│
├── express
│   ├── accepts
│   ├── body-parser
│   └── cookie
│
├── axios
│   └── follow-redirects
│
└── lodash

Here, “express”, “axios”, and “lodash” are direct dependencies.

Other packages are transitive dependencies because they are required by those direct dependencies.

An SBOM should capture these relationships rather than simply listing the packages installed directly by the application.

Common information includes:

Information	Description
Component Name	Name of the software package
Version	Specific component version
Supplier	Organization or publisher responsible for the component
Unique Identifier	Identifier such as a Package URL (PURL)
Dependency Relationship	How components depend on one another
License	License information associated with the component
Timestamp	When the SBOM was generated
Author	Entity responsible for the SBOM

The 2026 joint guidance on SBOM minimum elements from CISA, NSA, FBI, and international partners also emphasizes additional information such as component hashes, SBOM tool details, generation context, and SBOM signatures.

These additions help organizations improve the reliability and usefulness of software component inventories.

4. Understanding Direct and Transitive Dependencies

One of the most important concepts when working with SBOMs is the difference between direct and transitive dependencies.

A direct dependency is a package explicitly declared by your project.

For example:

{
  "dependencies": {
    "express": "^5.0.0",
    "axios": "^1.0.0"
  }
}

Your application directly depends on Express and Axios.

However, those packages may depend on other libraries to provide their functionality.

Those additional packages are transitive dependencies.

This distinction matters because a security vulnerability does not necessarily affect only packages that developers explicitly install.

A vulnerable transitive dependency can introduce risk even when your application never imports that package directly.

This is one reason why an SBOM should provide a comprehensive dependency inventory, including the relationships between components.

5. Common SBOM Formats: SPDX vs. CycloneDX

For an SBOM to be useful across different tools and organizations, it needs a standardized format.

Two widely used formats are SPDX and CycloneDX.

SPDX

Software Package Data Exchange (SPDX)

SPDX is an open standard originally developed to communicate information about software packages, particularly open-source license information.

It is maintained by the Linux Foundation and standardized as ISO/IEC 5962.

SPDX supports use cases including:

• Software component identification.
• License information.
• Copyright information.
• Dependency relationships.
• Software supply chain transparency.

Official documentation: https://spdx.dev/

CycloneDX

CycloneDX is an open standard maintained by the OWASP Foundation and published as Ecma International standard ECMA-424.

It focuses on software supply chain transparency and cybersecurity use cases.

Its capabilities include:

• Software component inventories.
• Dependency relationships.
• Vulnerability information.
• License information.
• Supply chain risk analysis.

CycloneDX also supports other types of Bills of Materials, including hardware, cryptographic assets, and machine learning models.

Official documentation: https://cyclonedx.org/

Which Format Should Developers Choose?

There is no universally correct choice for every project.

Consideration	SPDX	CycloneDX
Main focus	Software transparency and licensing	Software supply chain security
License information	Yes	Yes
Dependency relationships	Yes	Yes
Vulnerability-related capabilities	Yes	Yes
Common use cases	License compliance and inventory	Security analysis and dependency risk

Both are established standards and can be used to create machine-readable SBOMs.

The best choice depends on the tools, integrations, and requirements of your organization.

6. How to Generate an SBOM for Your Project

Developers do not need to manually create an SBOM.

Several tools can inspect source directories, package manifests, and container images to generate software component inventories.

One practical option is Syft, an open-source CLI tool maintained by Anchore.

Syft can generate SBOMs from:

• Local project directories.
• Container images.
• OCI images and registries.
• Filesystems and archives.

Step 1: Install Syft

On macOS, you can install Syft using Homebrew:

brew install syft

For other operating systems, follow the official installation instructions:

https://oss.anchore.com/docs/installation/

Step 2: Generate an SBOM

Navigate to your project directory and execute:

syft scan dir:. -o table

This scans the current directory and displays discovered software components.

The output provides an overview of the packages and their versions.

Step 3: Export an SBOM

To generate an SBOM in CycloneDX JSON format:

syft scan dir:. -o cyclonedx-json > sbom.cdx.json

Alternatively, generate an SPDX JSON document:

syft scan dir:. -o spdx-json > sbom.spdx.json

You now have a machine-readable SBOM that can be stored and processed by other security tools.

Step 4: Generate an SBOM from a Container Image

Generating an SBOM from source code is useful, but it does not always represent everything included in the final deployed artifact.

For containerized applications, you can also inspect the actual container image.

For example:

syft scan my-api:latest -o cyclonedx-json > image-sbom.json

This helps identify software components included in the image, including operating system packages and application dependencies.

Scanning the final image is particularly useful because the deployed artifact may contain components that are not obvious from the application source repository alone.

7. How SBOM Fits into a CI/CD Pipeline

Generating an SBOM once is useful, but maintaining it throughout the software lifecycle is much more valuable.

A practical approach is to generate an SBOM automatically during the build process.

For example, a typical CI/CD workflow might look like this:

Developer pushes code
        |
        v
CI pipeline starts
        |
        v
Install dependencies
        |
        v
Build application
        |
        v
Generate SBOM
        |
        v
Run security and vulnerability scans
        |
        v
Publish build artifacts
        |
        v
Deploy application

In this workflow, the SBOM becomes part of the build artifact.

When a new vulnerability is announced, security teams can use the stored SBOMs to identify which application versions may contain the affected component.

For larger engineering organizations, SBOM generation can be integrated into existing security and release management processes.

A useful practice is to generate and retain an SBOM for each released version rather than relying on a single inventory that is continuously overwritten.

This makes it easier to investigate older releases and understand what was actually included in a particular build.

8. Does Having an SBOM Mean Your Software Is Secure?

No.

An SBOM improves visibility, but it does not automatically make software secure.

It tells you what components are present, but it does not independently guarantee that those components are safe.

For example, an SBOM may identify a dependency that contains a known vulnerability.

However, additional analysis is required to determine:

• Whether the vulnerable code is actually present in the deployed artifact.
• Whether the application uses the affected functionality.
• Whether the vulnerability is reachable in the application’s execution context.
• Whether a security patch or mitigation is available.
• Whether the vulnerability creates an exploitable risk in your environment.

An SBOM is therefore one part of a broader software security strategy.

It should complement other practices such as:

• Software Composition Analysis (SCA).
• Dependency vulnerability scanning.
• Secure dependency management.
• Software artifact verification.
• Code security reviews.
• Continuous monitoring.

For example, Syft can generate an SBOM, while another tool such as Grype can analyze software components for known vulnerabilities.

These tools serve different purposes and can work together.

An inventory tells you what is present. A vulnerability scanner helps identify known security issues associated with those components.

Both are necessary for an effective dependency security workflow.

9. Practical Recommendations for Engineering Teams

Organizations do not need to implement a complicated SBOM program immediately.

A gradual approach can provide meaningful benefits without creating unnecessary operational overhead.

Here are some practical recommendations.

Start with critical applications.

Prioritize applications that handle sensitive information, support important business operations, or have significant external exposure.

Generate SBOMs during builds.

Automating SBOM generation helps keep inventories consistent and reduces reliance on manual processes.

Include transitive dependencies.

Do not rely exclusively on package manifests. Make sure your tooling captures the dependency relationships and relevant components.

Scan the final artifact.

For containerized applications, generate an SBOM from the final image to understand what is actually being deployed.

Store SBOMs by release version.

Keep historical inventories so teams can investigate vulnerabilities affecting previously released software.

Connect SBOMs with vulnerability management.

An inventory becomes significantly more useful when it can be analyzed against vulnerability intelligence and security findings.

Review the quality of generated SBOMs.

Automated tools can miss components or produce incomplete inventories depending on the scan target and available metadata. Validate coverage and keep the generation process up to date.

Conclusion

Modern software development depends heavily on third-party components, open-source libraries, and external dependencies.

As applications become more complex, understanding what goes into a software product becomes increasingly important.

A Software Bill of Materials provides a structured way to answer that question.

It helps developers and organizations identify software components, understand dependency relationships, investigate vulnerabilities, and improve software supply chain visibility.

However, an SBOM is not a replacement for vulnerability scanning, secure development practices, or proper security reviews.

Its real value comes from combining an accurate software inventory with processes that continuously monitor, assess, and respond to risks.

For development teams looking to improve software supply chain security, generating an SBOM during the build process is a practical first step.

You cannot effectively manage the risks of software components if you do not know what your software contains.

---

References

1. CISA – 2026 Minimum Elements for a Software Bill of Materials (SBOM)
2. NIST – Software Security in Supply Chains: Software Bill of Materials
3. NTIA – The Minimum Elements for a Software Bill of Materials
4. Anchore – Syft SBOM Generation Documentation
5. SPDX – Official Documentation
6. OWASP CycloneDX – Official Documentation
7. CISA – Recommended Practices for SBOM Consumption