To create an SBOM, pick a format (CycloneDX or SPDX), run a generator against your lockfile or build output, check that the direct and transitive dependencies are all listed, and save the file with each release. Regenerate it on every build so it stays accurate.
Key takeaways
- An SBOM is a machine-readable inventory of the components in a piece of software.
- Generate from the resolved dependency tree, not from a hand-written list.
- CycloneDX and SPDX are the two formats most tools and customers accept.
- One SBOM per release, regenerated in CI, is worth more than a perfect one made once.
What is an SBOM and who asks for one?
An SBOM, or software bill of materials, is a list of the components that make up a piece of software. CISA describes it as "a nested inventory, a list of ingredients that make up software components."
Customers, auditors and regulators ask for them. In the EU, Annex I of the Cyber Resilience Act requires manufacturers to draw up an SBOM "in a commonly used and machine-readable format" that covers at least the top level dependencies. CISA has also published a 2026 update to its SBOM minimum elements guidance, which adds new data fields.
Step 1: What should an SBOM cover?
Decide the scope before you run anything. Pick one product or repository and decide who will read the file: a customer, an auditor, or your own security team.
Write down three choices. Which build do you describe, such as the released artifact? Do you include development dependencies? Do you describe a library, an application or a container image? Each answer changes what the generator should look at.
Step 2: Which SBOM format should I use?
Use CycloneDX or SPDX. Both are open standards and most tools read both.
- CycloneDX is developed by the OWASP Foundation and Ecma International. It supports JSON, XML and Protocol Buffers. Version 1.7 was released on 21 October 2025.
- SPDX is an international open standard, ISO/IEC 5962:2021. Version 3.0 is listed as current.
If a customer has not named a format, CycloneDX JSON is a sensible default. Switch when someone asks.
Step 3: How do I generate the SBOM?
Run a generator against the resolved dependency tree, ideally your lockfile or build output. Hand-written lists miss transitive dependencies, which is where most of the surprises sit.
For a Node project, the npm CLI can do it. npm sbom lists the dependencies of the current project in SPDX or CycloneDX format. You choose the format with the sbom-format setting, either cyclonedx or spdx, and the sbom-type setting says whether the project is a library, application or framework. Turning on package-lock-only reads only the lockfile.
For other ecosystems, use the generator for your package manager or an SBOM tool that reads your repository. Safeguard can generate SBOMs and also import ones you already have.
Step 4: How do I check the SBOM is complete?
Open it and compare it to reality. Three quick checks catch most problems:
- The component count is roughly what your lockfile shows, including transitive packages.
- Each component has a name, a version and an identifier that tools can match against advisories.
- Nothing you ship is missing, such as a vendored library or a base image.
If you only want a fast look at what your dependencies are, the free scan at gold.safeguard.sh/scan reads a dependency file in your browser. It needs no login, the file stays on your machine, and it covers up to 100 dependencies.
Step 5: Where do I store and share it?
Store one SBOM per release, next to the artifact it describes. Name the file with the product and version so nobody has to guess.
CISA's SBOM page points to resources on sharing, including an SBOM Sharing Primer and a description of the author, consumer and distributor roles. Under the CRA, the SBOM must be provided to a market surveillance authority on a reasoned request, and users must be told where to find it if you choose to publish it.
Step 6: How do I keep it current?
Generate it in CI on every build, not by hand. An SBOM goes stale the moment a dependency changes.
Then use it. Match each release's SBOM against new advisories so that when a CVE lands you can answer "which products contain this?" in minutes. The interactive demo below shows the generation flow.
Click through it at your own pace, or open it full screen.
Common SBOM mistakes
- Generating from
package.jsonalone instead of the lockfile, which hides the exact resolved versions - Producing one SBOM at project start and never again
- Leaving out the container base image or vendored code
- Treating the SBOM as a compliance file nobody reads
Frequently asked questions
Is an SBOM the same as a vulnerability scan?
No. An SBOM lists what is in the software. A scan compares that list to vulnerability data. You need the list first.
CycloneDX or SPDX, which should I pick?
Either is accepted by most tools. Use whichever your customer or regulator names, and default to CycloneDX JSON if nobody does.
Do I need to include dev dependencies?
Include what ships in the artifact. Development tools matter for build security, so record them separately if you track that risk.
How often should I generate an SBOM?
On every build or release. A stale SBOM gives wrong answers when you need it most.
Is an SBOM legally required?
Under the EU Cyber Resilience Act, manufacturers of products with digital elements must draw one up. Whether a given product is in scope is a question to settle with your own counsel.
Sources
- CISA: Software Bill of Materials
- CycloneDX specification overview
- SPDX specifications
- npm Docs: npm sbom
- Regulation (EU) 2024/2847 on EUR-Lex
- Safeguard Gold dependency scan
Last reviewed: 19 October 2026.
