Often yes, but not for the reason people expect. A small company may not be legally required to produce one, yet an SBOM is the cheapest way to answer what you ship, and customers increasingly ask. Generate it from your lockfile, keep it current, and use it to check new advisories.
What an SBOM is
CISA describes a software bill of materials as a nested inventory, a list of ingredients that make up software components. It is a file that lists each package, its version and where it came from, including packages your packages pull in. Two open formats are widely used, CycloneDX and SPDX.
Does your company need one?
This is a decision, so use a short guide.
| Situation | Need an SBOM? |
|---|---|
| You sell software to businesses that run security reviews | Likely yes, buyers ask |
| You sell to public sector or regulated buyers | Check the contract and procurement terms |
| You ship an internal tool only | Optional, still useful for advisories |
| You publish an open source library | Helpful for your users |
| You are pre revenue with a single app | Do the inventory now, formalize later |
Check your own contracts. This post is not legal advice, and requirements differ by customer and country. Where a requirement matters, confirm the exact wording with the buyer or a lawyer.
Why it helps even if nobody asks
When a new advisory lands, the first question is whether you use the affected package. With an inventory, that is a search. Without one, it is an afternoon of grepping across repositories. The SBOM also shows packages nobody remembers adding, which is usually the first useful surprise.
How to produce one in a small team
- Commit your lockfile. It is the most accurate source of resolved versions.
- Generate an SBOM from it using your code host or an open source generator. GitHub's documentation says you can export an SBOM from the dependency graph for a repository.
- Store it with your release, one file per release.
- Regenerate on every release, not once a year.
- Scan it again regularly, because a clean SBOM today can match a new advisory next month.
For container images, generate one from the built image as well, since base images add packages your lockfile does not list.
Common mistakes
- One time export. An SBOM from last spring describes last spring.
- Only direct dependencies. The indirect ones carry much of the exposure.
- Sending it without context. A raw list invites questions. Add a short note on how you review it.
- Treating it as proof of safety. It is an inventory, not an assessment.
Our guide to generating CycloneDX and SPDX from an npm lockfile has the commands.
What to do with it
Match it against advisory data, then rank findings by exploitation evidence and by whether your code reaches the vulnerable function. That second step is what keeps a small team from drowning.
Safeguard generates SBOMs and scans dependencies, with reachability analysis on top. The free scan at https://gold.safeguard.sh/scan is a quick way to see your own inventory.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Is an SBOM the same as a vulnerability report?
No. An SBOM lists components. A vulnerability report matches those components to known issues. You need the first to produce the second.
How often should an SBOM be regenerated?
With every release at minimum. The list changes whenever dependencies change, and the vulnerability match changes whenever new advisories are published.
Sources
- CISA, Software Bill of Materials (SBOM)
- CycloneDX, Specification overview
- SPDX, About
- GitHub Docs, Dependency graph
Last reviewed: 19 October 2026.
