SBOM in Practice: Embedding Compliance Into the Software Delivery Lifecycle

Behind every application lies a web of components, libraries, and dependencies it relies on to function. Modern applications are built on layers of dependencies, including libraries, frameworks, third-party packages, and open source components, that most teams have only a partial view of. A Software Bill of Materials (SBOM) changes that. It is essentially a detailed record of a structured, machine-readable inventory of every component, library, and dependency that makes up an application.

Compliance mandates across industries are increasingly requiring organizations to produce and maintain SBOMs. Teams that reduce this to a compliance checkbox will struggle when it matters most. If done right, an SBOM practice does more than satisfy an auditor. It fundamentally improves how an organization understands and manages software risk.

SBOM Structure

An SBOM is a formal record containing the details and supply chain relationships of components used in building a piece of software. A well-formed SBOM typically includes component names and versions, unique identifiers such as Package URLs (PURLs), dependency relationships between components, licensing information, and known vulnerabilities associated with each component at the time of generation.

The two dominant formats today are SPDX (Software Package Data Exchange) and CycloneDX, which was purpose-built for security use cases. Both are widely supported by tooling and accepted by most compliance frameworks. Choosing between them is less important than committing to one and generating SBOMs consistently.

Here is what a minimal CycloneDX SBOM looks like in practice:

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.4",
  "components": [
    {
      "type": "library",
      "name": "spring-boot",
      "version": "3.1.0",
      "purl": "pkg:maven/org.springframework.boot/[email protected]",
      "licenses": [{ "license": { "id": "Apache-2.0" } }]
    }
  ]
}

Each component carries its name, version, a unique PURL identifier, and license information. This machine-readable structure is what enables downstream tooling to automatically cross-reference components against vulnerability databases and license compliance policies.

For teams that prefer SPDX, here is an equivalent representation:

{
  "spdxVersion": "SPDX-2.3",
  "SPDXID": "SPDXRef-DOCUMENT",
  "name": "test-service",
  "packages": [
    {
      "SPDXID": "SPDXRef-spring-boot",
      "name": "spring-boot",
      "versionInfo": "3.1.0",
      "licenseConcluded": "Apache-2.0",
      "externalRefs": [
        {
          "referenceCategory": "PACKAGE-MANAGER",
          "referenceType": "purl",
          "referenceLocator": "pkg:maven/org.springframework.boot/[email protected]"
        }
      ]
    }
  ]
}

SPDX is more verbose than CycloneDX and uses SPDXID references to uniquely identify each package within the document. It was originally designed with license compliance in mind, which is reflected in the prominence of the licenseConcluded field. Both formats capture the same essential information; the right choice often comes down to what your compliance framework or downstream tooling expects.

Common Challenges

Generating an SBOM for a single application on demand is straightforward. The real challenge is doing it reliably, at scale, across an entire portfolio of applications, and keeping those SBOMs accurate over time. The following are some of the challenges:

Transitive dependencies: Direct dependencies are easy to track. The libraries your libraries depend on, and the libraries those depend on, are where most vulnerabilities hide. A complete SBOM needs to capture the full dependency graph, not just the top layer.

SBOMs go stale fast: A snapshot taken at build time may be outdated within days as new vulnerabilities are disclosed against existing components. An SBOM that is not continuously monitored is a compliance artifact, not a security tool.

Mixed Tech Stacks: Most modern applications are not built in a single language or runtime. A typical microservices architecture might include Java services, Python scripts, Node.js frontends, and Go-based infrastructure tooling. Each ecosystem has its own dependency management conventions, and SBOM generation tooling needs to handle all of them consistently.

SBOM in the Delivery Lifecycle

The most effective approach is to treat SBOM generation as a non-negotiable step in the CI/CD pipeline, not a manual process triggered before an audit. Here is a practical framework for how to think about it:

Generate at build time: Every build should produce an SBOM as a build artifact, stored alongside the binary or container image it describes. This ensures the SBOM accurately reflects what was actually built, not what was declared in a manifest.

Attest and sign: An SBOM is only valuable if you can trust it. Use tools that support SBOM attestation, cryptographically linking the SBOM to the artifact it describes. Frameworks like SLSA (Supply Chain Levels for Software Artifacts) provide a good structure for thinking about this.

Store and version: SBOMs should be stored in a centralized repository with version control. This becomes critical during incident response when a new vulnerability is disclosed, and you need to quickly identify which applications are affected.

Continuously scan: Generating an SBOM is step one. Continuously running that SBOM against updated vulnerability databases such as the National Vulnerability Database (NVD) and Open Source Vulnerabilities (OSV) is what turns it from a static document into an active risk management tool.

The diagram below illustrates a sample of how SBOM generation fits into a typical CI/CD pipeline:

How to Proceed

Rather than tackling everything at once, a phased approach makes SBOM adoption manageable.

Phase 1: Inventory - Pick a few of the most critical applications and generate SBOMs for them today. Understanding the current state of dependencies comes before automating everything.

Phase 2: Automate - Integrate SBOM generation into the CI/CD pipeline for those applications. Establish where SBOMs are stored and how they are versioned.

Phase 3: Scale - Roll out the pipeline integration across the broader application portfolio. Establish a central SBOM repository and connect it to a vulnerability monitoring feed.

Phase 4: Operationalize - Define response playbooks. The speed of response to a newly disclosed critical CVE is what separates teams with a mature SBOM practice from those without.

Conclusion

SBOMs represent a meaningful shift in how the industry thinks about software supply chain risk. Treating SBOMs as a future concern is itself a risk. Organizations that build SBOM generation and monitoring into their delivery pipelines now will be far better positioned, both for compliance and for genuine security resilience, than those who treat it as a last-minute obligation.

Software supply chain risk does not wait for organizations to be ready. SBOMs are how teams get ready.