Generate a Software Bill of Materials: A Practical Workflow
To generate a software bill of materials (SBOM), identify the software release you need to describe, collect component data from source manifests and build outputs, then validate and export it in a recognized format. The result is a machine-readable inventory of software components and related details; it helps teams understand what is inside a release, but it is not automatically a security audit or proof that every component has been found.
What an SBOM contains
An SBOM is a structured inventory of components in a software product. Depending on the format and the data available, entries can include a component name and version, supplier, package identifier, relationships between components, and checksums or licensing information. An SBOM may cover direct dependencies—the packages a project names explicitly—and transitive dependencies pulled in by those packages.
Two common machine-readable formats are SPDX and CycloneDX. Both can represent software component information, but their models and supported fields differ. Choose a format that your organization, customers, or downstream tools can consume, and follow the requested version and profile when one is specified. A plain list of package names is useful for a quick check, but it is not necessarily a complete or interoperable SBOM.
A practical generation workflow
- Define the subject. Specify the product, release, build, and scope. Decide whether the SBOM describes an application, a container image, a firmware package, or another deliverable. Record an unambiguous version or build identifier so the inventory cannot be confused with a later release.
- Gather authoritative inputs. Collect dependency manifests and lockfiles, source repositories, build records, and the final packaged artifact. A manifest can state the dependencies a project intends to use; a lockfile often records resolved versions. Neither alone necessarily describes everything copied into the shipped product.
- Run suitable discovery tools. Use tools that can inspect the project’s package ecosystems and, where relevant, scan the built artifact. Configure the output format and scope. For example, a project using a JavaScript package manager might be inventoried from its lockfile, while a container release may also need inspection of the image layers and operating-system packages.
- Combine and reconcile results. Compare findings from source-level and artifact-level discovery. Resolve duplicate entries and inconsistent names where possible, but preserve identifiers and provenance. Do not silently treat a package with a similar name as the same component; package URLs or ecosystem-specific identifiers can help distinguish components.
- Validate the document. Check that the file parses in a format-aware validator or consumer, required fields are present for your use case, relationships make sense, and the document identifies the product release. Review unresolved components, unknown versions, and findings that may be false positives.
- Publish and maintain it. Store the SBOM with the corresponding release, make it available to the people or systems that need it, and regenerate it when the shipped contents change. Keep the tool settings and source inputs with build records so later updates can be compared meaningfully.
Choosing tools and an output format
There is no single generator that is best for every software stack. A useful tool should support the languages and package managers in use, explain what it scans, export the format you need, and provide a way to validate or inspect results. For packaged software, check whether it can inspect the final artifact rather than only source files. For multiple ecosystems, teams may combine tools, then normalize or merge their findings.
Before adopting a tool, test it against a release whose contents are already understood. Look for missing operating-system packages, vendored libraries, generated code, or dependencies installed outside the usual package manager. Also check whether the tool records its own version and scan configuration: those details help explain why two inventories differ.
- SPDX is a standard for communicating software bill-of-materials and related licensing information.
- CycloneDX is an SBOM standard designed to represent software components and related supply-chain data.
Neither format guarantees accuracy on its own. Format selection is about how information is represented and exchanged; completeness depends on scope, discovery coverage, and review.
Validation, accuracy, and common gaps
Generation is not the same as verification. A tool can only report what it can detect from the inputs it receives. Compare the generated inventory with the actual release contents, especially if the build downloads dependencies dynamically, bundles files, includes vendor code, or adds packages during image construction.
Common gaps include scanning a manifest but not a lockfile, overlooking operating-system packages in a container, missing libraries copied into the repository, and reporting a dependency without a resolved version. Some tools infer components from file signatures or metadata; these detections can be uncertain. Treat confidence and evidence as review items rather than assuming every result is definitive.
Check for stale or mismatched inventories, too. If a release changes after the SBOM is generated, the document may no longer describe what ships. Tie the SBOM to a specific build or artifact digest where practical, and make the release process regenerate it from the same build inputs. If a customer requires a particular set of fields, validate against that requirement instead of assuming a syntactically valid file is sufficient.
Using the SBOM after generation
An SBOM is most valuable when it is maintained and connected to operational processes. Teams can use it to investigate whether a newly disclosed vulnerability may affect a shipped component, review third-party dependencies, answer customer inventory requests, and track licensing information. Such uses still require judgment: a component match does not by itself establish that a vulnerability affects the product or that the vulnerable code is reachable.
Keep a clear association among the SBOM, release identifier, and artifact. When a new version ships, produce a new inventory and compare it with the previous one. A change report can make added, removed, and upgraded components easier to review. Avoid treating an old SBOM as a live inventory of all deployed copies; organizations may have several releases in use at once.
Frequently Asked Questions
Can I generate an SBOM from source code alone?
Often, but source-only discovery may miss components added during packaging, operating-system packages, or files included without a recognized manifest. For a release inventory, compare source findings with the built artifact where feasible.
Is an SBOM the same as a vulnerability scan?
No. An SBOM describes components and relationships. A vulnerability scanner may use an SBOM or other evidence to check component versions against vulnerability data, but the inventory itself does not determine exploitability or risk.
Should I include transitive dependencies?
Usually, if the goal is to describe what the product contains. Transitive dependencies can be relevant to security and maintenance, but the appropriate scope may depend on the product and the recipient’s requirements.
Which SBOM format should I use?
Use the format requested by the recipient or supported by your workflow. SPDX and CycloneDX are widely used options; confirm the required version and fields, then validate the generated file with a compatible tool.
When should an SBOM be regenerated?
Generate one for each release or build whose contents may differ. Regenerate after dependency updates or other changes to shipped contents, and ensure the document remains tied to the exact release it describes.
Related
Method: the standard formula for this calculation, rounded as each result states. See how the calculators work or report an error.