# A primer on the SBOM lifecycle for SBOM producers

> Streamline your Software Bill of Materials (SBOM) workflow with our comprehensive guide. Learn about SBOM generation, collaboration, and analysis best practices, and discover how to automate distribution with sbomify.

- **Updated:** 2026-10-28

The Software Bill of Materials (SBOM) lifecycle comprises three key stages: **Authoring**, **Distribution**, and **Analysis**.

![Diagram: lifecycle](https://sbomify.com/assets/images/d2/lifecycle.svg)

```d2
Authoring: {
  Generation
  Augmentation
  Enrichment
  Signing: {
      stroke-dash: 3
    }
  }
  Generation -> Augmentation
  Augmentation -> Enrichment
  Enrichment -> Signing
}
Distribution
Analysis
Authoring.Signing -> Distribution
Distribution -> Analysis
```

> **TL;DR:** If this workflow sounds overly complex, rest assured that sbomify automates the entire process for you. All you need is a few lines of YAML in your CI/CD pipeline using the [sbomify Action](https://sbomify.com/sbomify-action/).

---

## Generation (a.k.a Authoring)

Newcomers to SBOMs often underestimate the complexities involved in creating a complete SBOM (also known as 'authoring'). There are many [SBOM generation tools](https://sbomify.com/resources/#generation--authoring) available, so it might seem like it's just a matter of running one of these tools and you're done.

While this _might_ suffice for internal SBOM needs when starting out, the reality is far more complicated if you need to meet industry requirements, such as the NTIA Minimum Elements. But don’t worry – we’re here to help.

To produce an SBOM that complies with standards like the NTIA Minimum Elements, it's helpful to view the process in four phases.

![Diagram: generation](https://sbomify.com/assets/images/d2/generation.svg)

```d2
Generation
Augmentation
Enrichment
Signing: {
    stroke-dash: 3
  }
}
Generation -> Augmentation
Augmentation -> Enrichment
Enrichment -> Signing
```

### 1. Generate

In the generation phase, you produce the actual SBOM. Generally speaking, there are two main ways to generate an SBOM: from **source** (e.g., using a lock file like `requirements.txt`) or during **build** (e.g., after installing dependencies from the lock file). Technically, you can also generate an SBOM during **run** time, but this approach is far less common.

To meet the NTIA Minimum Elements, we generally recommend generating the SBOM during the build process. Whether you capture all **transitive dependencies** from the source depends on the ecosystem. Modern package managers like **uv** and **Poetry** for Python capture these dependencies, as do build tools for modern languages like **Rust** and **Go**. However, generating from source without a lock file (or using an older package manager) likely won’t capture all **transitive dependencies**. This is why tools like GitHub's Dependency Graph often cannot produce NTIA-compliant SBOMs.

### 2. Augment

After generating your SBOM, you often need to _augment_ it with information that the generation tool likely missed. This may include details like:

- Who are you?
- What is the software’s license?
- What version of the software is this?
  - Depending on the generation tool, this might already be set, but you may need to override it.
- Who is supplying the software?
- How can I get in touch with you?

Many teams do this manually by merging a metadata SBOM file into the original SBOM, often using `jq`. While labor-intensive and error-prone, `jq` (and now [`jd`](https://github.com/josephburnett/jd)) remain the standard tools for this task.

_If you want to avoid this step, our agent automates the entire process for you._

### 3. Enrich

Next is the _enrichment_ phase. Depending on the tool used to generate the SBOM, this step might be optional. Some tools automatically enrich the SBOM, typically by calling out to a third-party service (like PyPI) during generation to gather component details, such as licensing data.

For example, the [sbomify Action](https://sbomify.com/sbomify-action/) (which can be used either with sbomify or in standalone mode) automatically augments your SBOM with identity data and enriches it with metadata from [ecosyste.ms](https://ecosyste.ms) to create the most complete SBOM possible – all within your CI pipeline before upload.

### 4. Signing / Attestation

If you're serious about supply chain security, consider adding cryptographic signing and attestation to your workflow. This process involves not only generating an SBOM in your CI/CD pipeline but also cryptographically signing it. The primary security advantage is the ability to verify the SBOM’s integrity and authenticity at any time, reducing the need to blindly trust the distribution platform (like sbomify).

You can read more about this in our [blog post on attestation](https://sbomify.com/2024/10/31/github-action-update-and-attestation/).

---

## Distribution (a.k.a Transportation)

Each stage of the SBOM lifecycle is crucial to maintaining transparency and security within the software supply chain. Yet, effective collaboration remains a significant challenge. SBOMs must be shared efficiently with internal teams and external stakeholders, such as customers and partners – a process often referred to as "Transportation." Unfortunately, many organizations still rely on outdated distribution methods. Conversations with CTOs and CISOs reveal that email remains the primary sharing tool, reminiscent of how software patches were distributed in the 1990s. As a result, SBOMs are often stored haphazardly on internal file shares, leading to labor-intensive processes, disorganized storage, and outdated information.

The limitations of these traditional sharing methods pose real risks to supply chain integrity. The [CISA SBOM Sharing Primer](https://www.cisa.gov/sites/default/files/2024-05/SBOM%20Sharing%20Primer.pdf) underscores the need for streamlined SBOM “Transport” to improve visibility and reduce risk. The document advocates for automated, standardized processes, cautioning that manual methods create inconsistencies and errors that could compromise the entire ecosystem.

This is where sbomify transforms the landscape. sbomify automates the distribution and collaboration process, integrating directly into the Continuous Integration/Continuous Deployment (CI/CD) workflow to eliminate manual distribution and ad-hoc storage. Instead of relying on scattered email chains and file shares, sbomify ensures that stakeholders always have access to accurate, up-to-date SBOM data. By automating the process, sbomify minimizes manual work and significantly enhances security, reducing the risk of circulating outdated or incorrect information. You can learn more about this in our [SBOM Hub & Trust Center](https://sbomify.com/features/trust-center/) feature page.

A frequently overlooked but essential step in the SBOM lifecycle is the creation of a consolidated [SBOM hierarchy](https://sbomify.com/features/sbom-hierarchy/), which is especially valuable in complex software architectures. Take a basic SaaS product, for instance: with an API service running in a Docker container and a JavaScript-based frontend, you’ll quickly accumulate multiple SBOMs – for the backend, the Docker environment, and the JavaScript libraries.

![Diagram: sbom hierarchy](https://sbomify.com/assets/images/d2/sbom-hierarchy.svg)

```d2
product: Product SBOM {
  Smart Thermostat
}
component: Component Artifacts {
  Python SBOM
  Node SBOM
  Docker SBOM
  Yocto SBOM
  SOC 2 Type II
  CE Certificate
}
component.Node SBOM -> product.Smart Thermostat
component.Python SBOM -> product.Smart Thermostat
component.Docker SBOM -> product.Smart Thermostat
component.Yocto SBOM -> product.Smart Thermostat
component.SOC 2 Type II -> product.Smart Thermostat
component.CE Certificate -> product.Smart Thermostat
```

In such setups, merging the JavaScript and backend SBOMs might be feasible, but backend and Docker SBOMs remain distinct (at least in CycloneDX format). To maintain clarity, you can create a parent SBOM that links these individual SBOMs. The consolidation process, whether in CycloneDX or SPDX, often requires either complex scripts or a custom tool. With sbomify, this is built-in.

_If this sounds complex, reach out, and we can automate SBOM hierarchy generation for you._

As the software industry increasingly recognizes the value of SBOMs for security and transparency, the need for efficient, automated collaboration tools becomes critical. Solutions like sbomify address this need by modernizing SBOM workflows and aligning with CISA’s best practices. For organizations aiming to streamline SBOM processes and bolster their cybersecurity, implementing a solution like sbomify is not just beneficial – it’s essential.

---

## Analysis

The final phase in the SBOM lifecycle is the analysis phase. Generally, teams have two primary goals for an SBOM:

- **Security Audit:** Identify all CVEs in a given SBOM.
- **License Audit:** Ensure all software in the SBOM complies with internal policies.

There are many tools available that focus on different problem spaces (many are listed [here](https://sbomify.com/resources/#analysis)). Two popular open-source tools for SBOM analysis are [Dependency Track](https://dependencytrack.org/) and [guac](https://github.com/guacsec/guac).

![Diagram: store analyze enrich](https://sbomify.com/assets/images/d2/store-analyze-enrich.svg)

```d2
CI: {
  label: "CI/CD Pipeline"
  Generate: {
    label: "Generate"
  }
  Enrich: {
    label: "Augment & Enrich"
  }
  Sign: {
    label: "Sign"
  }
  Generate -> Enrich
  Enrich -> Sign
}
sbomify
Analysis: {
  label: "Analysis"
}
CI.Sign -> sbomify: Upload
sbomify -> Analysis: Sync
```

sbomify connects your SBOMs to vulnerability monitoring, triage and disclosure in your [Trust Center](https://sbomify.com/features/trust-center/), and integrates with your existing toolset. For instance, sbomify integrates with [Dependency Track](https://sbomify.com/features/integrations/#dependency-track) and [OSV](https://sbomify.com/features/integrations/#osv) for analysis, enabling you to export SBOMs directly to your analysis tools.

---

From sbomify: https://sbomify.com/features/generate-collaborate-analyze/