Software Bill of Materials: How to Create One

Updated 5 November 2026 · Standard formula, shown below

A software bill of materials (SBOM) is a structured inventory of the components inside a software product, including dependencies and their versions. Creating one helps teams understand what they ship, investigate newly reported vulnerabilities, and share component information with customers. Before starting, identify the product and release you want to document; an SBOM describes a particular build, not every version of a product at once.

What You’ll Need

The source repository, build files, lockfiles, and package manifests for the release.
Access to build or release records, including the target platform and build identifier.
An SBOM generator or software composition analysis tool that can inspect your languages and package ecosystems.
A way to validate and store the output, plus an owner responsible for updating it.
Where possible, component details from suppliers for proprietary or bundled software that automated tools cannot inspect.

Step-by-Step

Define the product and scope. Write down the product name, release version, build or commit identifier, and the platforms covered. Decide whether the SBOM will describe one executable, an installer, a container image, a full product suite, or several separately delivered artifacts. State whether you are documenting direct dependencies only or the complete dependency tree. For a commercial release, aim to cover the components actually shipped, not merely everything present in a developer’s workspace.
Choose an SBOM format and disclosure level. Common machine-readable formats include SPDX and CycloneDX. Choose a version supported by your generator, validator, and recipients, and keep the format consistent where practical. Decide how to handle confidential details, such as internal component names or repository locations. An SBOM should be useful without disclosing secrets; never include credentials, tokens, or private keys.
Inspect the release inputs. Locate manifests and resolved lockfiles for each relevant package manager, along with build scripts, submodules, and container or operating-system package inventories. Lockfiles usually record exact resolved versions and are more useful for a release inventory than broad version ranges in a manifest. Check whether vendored libraries, copied source, plugins, firmware, and bundled third-party tools are included in the shipped artifact.
Generate from a controlled build or artifact. Run an established generator against the release source and, where supported, the built package or image. Use the exact commit and build inputs used for distribution; record the command, tool version, and configuration so the result can be reproduced. Avoid scanning a changing working directory and presenting the output as the released product’s inventory.
Review component identification and relationships. Check names, versions, package URLs or other identifiers, supplier information, and dependency relationships. Confirm that direct and transitive dependencies are represented as intended. Look for duplicate entries caused by different package paths, and distinguish a product you develop from third-party components it contains. Add reliable supplier details for items the tool could not identify automatically; mark unknown information honestly rather than guessing.
Account for components scanners may miss. Compare the generated list with the final installer, container, or other deliverable. Review bundled binaries, vendored code, dynamically loaded modules, generated assets, and components obtained outside the main package manager. Ask relevant suppliers for component information when needed. If an item cannot be identified, document the gap, its scope, and who will resolve it.
Validate the document. Run a syntax and schema validator for the chosen format and version. Resolve errors such as missing required fields or invalid identifiers. Then perform a semantic review: make sure the product metadata refers to the correct release, versions are plausible, and the inventory matches the shipped artifact. A file that parses successfully can still be incomplete or describe the wrong build.
Attach and distribute the SBOM with release records. Store the file beside the corresponding artifact or in a controlled release system, with clear naming that links it to the product version and build. Follow your organization’s customer and supplier disclosure process. Preserve the original generated file and any reviewed, enriched version, and record which one was distributed.
Maintain it for every release. Regenerate the SBOM when the product’s shipped components change, rather than editing old versions to resemble the latest release. Keep historical SBOMs associated with their original builds. Assign an owner and include generation, validation, and review in the release workflow so omissions are caught before publication.

Common Mistakes

Scanning only direct dependencies: Vulnerabilities can occur in transitive libraries or bundled tools. Know what your selected tool includes and check its coverage.
Using a manifest as the final inventory: A manifest may allow version ranges and omit the versions resolved for a specific build. Use release lockfiles and artifact inspection where available.
Calling a source scan a complete product SBOM: Shipped binaries, vendor libraries, plugins, or operating-system packages may be absent from source metadata.
Leaving fields inaccurate or invented: Do not infer a license, supplier, or version from a similar package. Mark uncertainty and follow up.
Reusing one SBOM for multiple releases: Even small dependency updates can change the inventory. Tie each file to an identifiable build.
Publishing sensitive information: Review the output for secrets and internal details before sharing, while preserving the component information recipients need.

Tips

Generate the SBOM in the same automated pipeline that builds the release, then validate it before the release can be approved.
Keep both the machine-readable file and a human-readable review record, including known gaps and the person responsible for them.
Use a consistent naming convention that includes product, version, build identifier, and format.
Prioritize coverage of what customers actually receive. For a product with multiple installers or platform builds, create or clearly associate an inventory for each distinct deliverable.
Test the output with the tools or processes that will consume it, especially when a customer or internal team specifies a format version or required fields.

Troubleshooting

The generator reports no dependencies. Check that you are running it in the correct repository or artifact path and that manifests and lockfiles are present. Confirm the tool supports the ecosystem and file type. If dependencies are downloaded or bundled during a later build stage, scan the resulting artifact as well.

The SBOM is missing bundled components. Compare it with the installer or image contents and build configuration. Add supported scans for the relevant package or binary types, request component records from suppliers, and document anything still unresolved. Do not imply that an uninspected area is covered.

Validation fails. Confirm that the file format and schema version match the validator. Read the specific error, correct required metadata or malformed fields, and regenerate or validate again. Avoid changing the format version merely to suppress an error unless the receiving systems support that version.

The inventory differs between runs. Check whether dependencies are floating, the lockfile changed, the source revision differs, or the tool adds timestamps or unstable identifiers. Pin or record build inputs where appropriate, rerun against the release commit, and document unavoidable variation.

A customer cannot use the file. Ask which format and version their tooling accepts, then validate an export in that supported form. Preserve the original SBOM and make clear which product build the alternate file describes.

Frequently Asked Questions

What information does an SBOM contain?
An SBOM identifies a product and its software components, commonly including component names, versions, suppliers, identifiers, and relationships. The exact fields depend on the format and available data.

Which format should I use, SPDX or CycloneDX?
Both are established machine-readable formats. Choose based on recipient requirements and support in your generation, validation, and consumption tools; do not assume one is universally required.

Does an SBOM prove that software is secure?
No. It is an inventory, not a security certification or guarantee. It can help teams identify components to assess, but it may be incomplete and does not itself fix vulnerabilities.

Should I include proprietary components?
Include components that are part of the shipped product when your disclosure policy permits. Represent them accurately, protect confidential details, and never put secrets in the SBOM.

How often should I update an SBOM?
Create and review one for each release or build you distribute, especially when dependencies or bundled components change. Keep older files linked to the builds they describe.

Can a tool create the entire SBOM automatically?
Tools can automate much of the inventory, but they may miss vendored code, opaque binaries, supplier details, or components added outside recognized package systems. Review the result against the deliverable.

Method: the standard formula for this calculation, rounded as each result states. See how the calculators work or report an error.