Share an SBOM in the way that matches who asks and what it reveals. Open source projects can publish openly. Commercial vendors usually gate access, by customer login or NDA. Per request sharing is fine at low volume, but it does not scale. Pick one default and write down the exceptions.
What an SBOM can reveal
It lists libraries and versions. That helps customers check exposure. It also tells an attacker which known flaws might apply. Weigh that against the transparency customers get, and decide on purpose, not by accident.
CISA's sharing guidance describes three roles: author, consumer and distributor. The distributor is whoever hands the file on, which may be you, a portal or a registry. Knowing which role you play tells you who controls access.
The four patterns
| Pattern | Who can see it | Good for | Cost |
|---|---|---|---|
| Public download | Anyone | Open source, products with low sensitivity | None, but you cannot see who reads it |
| Gated by login | Customers | Commercial products with many buyers | A portal and access rules |
| NDA first | Named parties | Regulated buyers, sensitive components | Legal time per party |
| On request | Whoever asks | Few customers, early programs | Manual work per request |
Steps to decide
- List audiences: public, customers, regulators, partners, auditors.
- For each, ask whether the SBOM shows anything that is truly confidential, such as an unreleased component or an internal package name.
- Strip or generalize those fields if you can, instead of withholding the whole file.
- Pick the pattern for each audience from the table.
- Decide who answers questions, and how fast.
- Publish a short statement of the policy so buyers know what to expect.
Keep these straight
- Share the SBOM for the version they run, not the latest.
- Update on release and when a component changes. State the date in the file.
- If you sign the file, tell recipients how to verify it. A signature proves the file was not altered, not that its content is complete.
- Pair an SBOM with VEX statements so recipients can see which listed flaws actually affect the product.
Whatever you choose, make the request path clear. A buyer should know where to ask, who answers, and how long it takes. A one page policy is enough: what you share, in which format, for which versions, and how often you update. It saves your security team from answering the same question differently for each customer, and it gives sales something accurate to say.
Quick check
Does publishing an SBOM make us less secure?
It exposes the component list. Whether that is an acceptable trade is your call. Remove anything truly confidential first.
Is an NDA required to share an SBOM?
That is your choice, driven by sensitivity, customer expectations and any contract terms.
Safeguard's SBOM and dependency scanning can generate and export SBOMs for the products you manage, and a free scan is available at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
