If you ship an SDK or library, your dependencies become your customers' dependencies, so your SBOM matters more, not less. Produce one per released version, publish the dependency list with the release, and tell customers how you will announce advisories that affect a version they use.
Why it is different
A hosted service keeps its dependencies on your servers. A library travels. When a customer installs your package, your transitive dependencies come with it, and a vulnerability in one of them is now in their build. Their security team may ask about it, and they will expect you to know the answer first.
Tie each SBOM to a release
CISA's 2026 minimum elements guidance says each software version or update should have an associated SBOM, and that when a producer issues a new build or release, a new SBOM should be generated, including when builds integrate updated components (see Sources). For a library, this lines up with your package versions: one SBOM per published version.
Keep a clear mapping from package version to SBOM so a customer on version 2.4 can get exactly the one for 2.4.
What to include
- Runtime dependencies your package declares, with versions as resolved in your release build.
- Bundled code, if you vendor or compile anything in.
- Identifiers such as package URLs so customers can match advisories automatically.
Development and test tools generally stay out of the customer facing SBOM, or are labeled so nobody mistakes them for runtime components.
Delivery options
The guidance says an SBOM can accompany installation or be accessible through a version specific URL, an API or a public repository. For a library, practical choices include:
- Attaching the SBOM file to each release in your repository.
- Publishing it alongside the package on your documentation site.
- Providing it on request through support.
Since libraries are often public, many teams publish openly. Check that nothing sensitive is included.
Advisories that affect customers
Your response story needs a customer facing half. Decide:
- Where you will post notices, such as a security page or release notes.
- How you will indicate which versions are affected and which are fixed.
- Whether you will issue VEX statements when a dependency advisory does not affect your library.
The OpenVEX specification describes a format designed to be minimal and interoperable and independent of any one SBOM format, which can suit a library that wants to say "affected" or "not affected" simply (see Sources).
What to tell a buyer
"We publish an SBOM with each release, matching the package version. If a dependency advisory affects a released version, we post a notice naming affected and fixed versions."
Pitfalls
- Version ranges in your manifest hide what customers actually resolve. State the tested versions.
- Releasing a patch without regenerating the SBOM leaves the old one wrong.
- Forgetting older supported versions when an advisory lands.
Where Safeguard fits
Safeguard's SBOM and dependency scanning, reachability analysis and autonomous remediation with fix pull requests (off by default, every category on Manual) can help you track and update the dependencies your package ships. The free scan is a quick start.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how a fixed version is surfaced, since that is what you will want to point customers to.
Quick check
Should a library publish its SBOM publicly?
Often it makes sense, since the package itself is public. Review the file first for anything internal.
Do dev dependencies belong in the SBOM?
Not in the one customers rely on for runtime, unless labeled. Keep them separate or clearly marked.
Sources
Last reviewed: 19 October 2026.
