Yes, if you want it to describe what your users actually run. Generate the bundled npm packages from your lockfile, then add scripts loaded by URL as components and external APIs as services. Without those extra entries, the SBOM misses the code that changes without your deploy.
What most tools produce by default
Dependency based SBOM generators read a lockfile. That gives you every npm package and its exact version, which is valuable. npm's lockfile records version, resolved URL and an integrity hash per package, and is meant to be committed.
It does not include a script tag that points at a vendor URL, a vendored file in a folder, or a service your front end calls at runtime.
The CycloneDX model helps
The CycloneDX overview describes components as first and third party inventory, services as external APIs with endpoint URIs, authentication requirements, trust boundary crossings and data flows, and dependencies as direct and transitive relationships. Components can depend on services. That maps neatly to a web app.
| Front-end item | How to record it |
|---|---|
| Bundled npm package | Component from the lockfile |
| Library loaded from a CDN URL | Component with the exact version, source URL and file hash |
| Vendored file | Component with a note about origin |
| Analytics or payment script | Component for the script, plus a service entry for where it sends data |
| Backend API your app calls | Service with endpoint and data classification |
Steps
- Generate the SBOM from your lockfile as part of CI.
- Use your script inventory to list URL loaded scripts.
- Add those as components with exact version and the hash you pin with SRI where you have one.
- Add services for external endpoints, with the type of data sent.
- Store the merged SBOM with the release it describes.
- Regenerate on every release, since the lists change.
What you can say with it
A merged SBOM answers questions customers ask: which libraries and versions are in the front end, which third parties receive data, and what is affected when an advisory lands. See how fast can you answer are we affected.
Limits to be honest about
- Scripts that load other scripts at runtime will have children you cannot list in advance. Note the parent and the monitoring you have.
- A hash for a dynamic script goes stale. Date every entry.
- An SBOM is an inventory, not a verdict. It does not say a component is safe.
Where Safeguard fits
Safeguard generates SBOMs and scans dependencies for known issues, and you can try the free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how packages and versions are listed as one inventory.
Quick check
Will an SBOM tool find my CDN scripts automatically?
Lockfile based tools will not. You need to add them from a crawl or from your own script inventory.
Is a service the same as a component?
No. In CycloneDX a component is software you include, and a service is an external API your software calls.
Sources
- CycloneDX specification overview: https://cyclonedx.org/specification/overview/
- npm Docs, package-lock.json: https://docs.npmjs.com/cli/v10/configuring-npm/package-lock-json
Last reviewed: 19 October 2026.
