A software bill of materials example is best read as an ingredient label for a specific software release. It is a formal, machine-readable inventory of the components used to build software and the supply-chain relationships among them. It can help a team locate a component after a vulnerability or license question emerges; it does not, by itself, say whether a product is exploitable. A VEX, or Vulnerability Exploitability eXchange, document is a separate attestation that states whether a product is affected by known vulnerabilities.
CISA calls an SBOM a nested inventory, while NIST describes it as a formal record containing component details and supply-chain relationships. The nesting matters: a product can contain indirect, or transitive, dependencies as well as packages its developers selected directly.
Software bill of materials example: one component record
The following is an illustrative component-level record, not a complete SPDX or CycloneDX document. The field types and the log4j example are supported by common SBOM guidance. The product name, dependency path, and checksum value are deliberately generic.
- Product: Acme Payments API, release 4.2.0
- Component name: log4j
- Component version: 2.14.1
- Supplier: Apache Software Foundation
- License: the license recorded for that package release
- Unique identifier: a Package URL, often called a purl, or another software identifier
- Checksum: a hash recorded for the package and version
- Dependency relationship: Acme Payments API depends on a framework; that framework depends on log4j 2.14.1
How to read the record
- Name plus version distinguishes one component release from another for later vulnerability, maintenance, or licensing analysis.
- Supplier identifies the organization associated with the package.
- License supplies information for reviewing the terms associated with a component.
- Identifier gives tools a less ambiguous handle than a display name. A purl or SWID tag can support matching across systems.
- Checksum records the hash associated with the package and version.
- Relationship shows the path by which a component entered the product, including indirect dependencies.
Build or packaging discovery can cover open-source libraries, third-party packages, internal components, transitive dependencies, and container base images and layers. A hand-written list of only top-level packages leaves out much of the point.
Worked sequence: from a build to a usable SBOM
Hypothetical inputs: a service release contains the application itself, one direct framework dependency, and log4j as that framework's indirect dependency.
- Discover components. During a build or packaging process, identify the application, framework, log4j, and other included components.
- Collect metadata. Gather the name, version, supplier, license, identifiers and, where available, checksums. Record dependency relationships.
- Generate a standard document. Write the inventory in a machine-readable SBOM format. NIST identifies SPDX, CycloneDX, and SWID as acceptable standard formats for federal supplier SBOMs.
- Validate it. Check completeness and accuracy before treating the output as a useful inventory.
- Distribute and retain it. Share the SBOM with internal teams, purchasers, or other intended consumers, and retain it in an accessible repository.
- Update with the release. Generate a new SBOM when the code, libraries, or dependencies change.
Result: the release has a record showing that its dependency chain reaches log4j 2.14.1. If a later advisory names that version, a consumer can identify potentially relevant releases and use vulnerability analysis or a VEX document to determine whether the product is affected.
Formats are transport, not a security verdict
SPDX, CycloneDX, and SWID provide machine-readable structures for SBOM producers and consumers. GitHub characterizes SPDX as suited to licensing and audit work, CycloneDX as security- and vulnerability-management focused, and SWID as oriented to asset inventory. NIST recognizes all three in the federal supplier context. The useful choice is the format the intended recipient can ingest and use.
A standard format does not fix incomplete source data. A study of 186 public repositories using SPDX- and CycloneDX-related generation tools found that only a limited fraction of SBOMs contained minimum or recommended information; few listed licenses, hashes, or suppliers. Machine-readable gibberish is still gibberish.
What production use can look like
Atlassian has described a commit-driven internal system that generates repository SBOMs from incoming commits. Its jobs clone repositories, run generators, and upload the resulting SBOMs to S3. The company says it runs multiple tools, including Syft, cdxgen, and a CycloneDX Maven plugin, because no single tool effectively addresses every technology stack. That is Atlassian's architecture, not an SBOM requirement.
A short quality check before sharing
- Is the SBOM machine-readable in a format the intended consumer can handle?
- Does it identify each component with a name, version, and usable identifier?
- Does it include supplier, license, and checksum information where available?
- Does it show direct and transitive dependency relationships?
- Was it generated during the build or packaging process where possible?
- Was it validated, stored with the release, and refreshed after dependency changes?
- Can the receiving team ingest, analyze, and act on it?
NIST's warning is worth keeping: an SBOM complements vulnerability management and vendor-risk assessment; it does not replace either. NIST also cautions that an SBOM generated retroactively may fail to reproduce the dependency list used in the original build. Treat it as release evidence that needs a reliable generation process, not as a compliance charm taped to a tarball.
Frequently asked questions
What fields should an SBOM include?
Useful fields include a component name, version, supplier, license, unique identifier, checksum, and dependency relationships. The schema varies by format, but the record should identify components well enough for automated consumption and later analysis.
What is the difference between an SBOM and VEX?
An SBOM inventories software components and their supply-chain relationships. A VEX document is an attestation that indicates whether a product is affected by known vulnerabilities.
Which SBOM format should I use: SPDX, CycloneDX, or SWID?
NIST identifies SPDX, CycloneDX, and SWID as acceptable standard formats for federal supplier SBOMs. GitHub associates SPDX with licensing and audit work, CycloneDX with security-focused workflows, and SWID with asset inventory. Choose a format the recipient's tools can ingest and use.
How should an SBOM be kept current?
Generate the SBOM during the build or packaging process, validate it, distribute it with or alongside the release, and regenerate it when code, libraries, or dependencies change. NIST cautions that retroactively generated SBOMs may not reproduce the dependencies used in the original build.
Sources
- Software Bill of Materials (SBOM) - CISA — www.cisa.gov
- What is an SBOM (software bill of materials)? - GitHub — github.com
- Software Bill of Materials (SBOM) | NIST — www.nist.gov
- Producing Software Bill of Materials a.k.a SBOMs for Atlassian — www.atlassian.com
- On the adoption of software bill of materials in open-source ... — www.sciencedirect.com
