SBOM Generation Template

A software bill of materials (SBOM) is a machine-readable inventory of the components in a piece of software and how they depend on each other. This template is for engineering, AppSec, and product security teams that produce SBOMs for their own software or require them from suppliers. Use it when a customer, regulator, or procurement team asks for SBOMs, and to answer "are we affected?" within minutes when the next critical library vulnerability lands.

Two formats dominate: CycloneDX, an OWASP standard that also covers services, VEX, and cryptography, and SPDX, a Linux Foundation standard published as ISO/IEC 5962:2021. Both are widely supported; pick the one your tooling handles best and keep the ability to convert.

Minimum data fields

These are the baseline elements from the NTIA Minimum Elements for an SBOM:

• □ Supplier name of each component.
• □ Component name.
• □ Component version, so vulnerability matching is precise.
• □ Other unique identifiers, such as a package URL (purl) or CPE. Without them, automated matching to vulnerability databases fails.
• □ Dependency relationship (direct or transitive, and what includes what).
• □ Author of the SBOM data.
• □ Timestamp of when the SBOM was generated.

Recommended additional fields

• □ Cryptographic hash (SHA-256 or stronger) of each component, so consumers can verify integrity.
• □ License, expressed as SPDX license identifiers, for legal compliance.
• □ Generating tool and version, plus whether the SBOM came from source, build, or binary analysis. Build-time SBOMs are usually the most accurate.
• □ Known unknowns: explicitly mark components whose dependencies could not be resolved.

Generation steps

1. Generate the SBOM during the build from the resolved dependency graph (lockfiles and build tool output), not only from source manifests.
2. Include transitive dependencies, vendored code, and container base image and OS packages.
3. Output CycloneDX or SPDX JSON and validate it against the official schema in CI.
4. Sign the SBOM and bind it to the digest of the artifact it describes.
5. Publish it alongside the release in your artifact repository with appropriate access control.
6. Ingest it into a tool that continuously matches components against new advisories.
7. Publish VEX (Vulnerability Exploitability eXchange) statements so customers know whether a listed vulnerability actually affects your product.

Supplier requirements checklist

• □ An SBOM in an agreed format for every release, not a one-off document.
• □ A vulnerability disclosure and VEX process so you are not left triaging false positives.
• □ Build provenance for critical suppliers, ideally attested to a SLSA build level.
• □ Secure development practices aligned to the NIST Secure Software Development Framework (SP 800-218).

Common pitfalls

• SBOMs that are generated once and never regenerated as dependencies change.
• Source-only scans that miss statically linked, vendored, or container-layer components.
• Missing identifiers. An SBOM without purls or CPEs cannot be matched to vulnerabilities automatically.
• Treating the SBOM as a compliance deliverable instead of operational data that feeds vulnerability response.

For current US government guidance and community resources, see CISA's SBOM page.