Not always. Whether an SBOM needs an NDA depends on how much it reveals and who receives it. A high level component list may be fine to share openly, while a detailed SBOM with internal names and versions usually deserves confidentiality terms. This is a risk decision to make with your legal team, not legal advice.
What an SBOM can reveal
An SBOM is a list of ingredients, but a detailed one says more than people expect:
- Exact versions of open source libraries, which help an attacker match known vulnerabilities.
- Internal package names and registry addresses, which hint at your architecture.
- Build tool names and versions.
- File paths or hostnames, if the generator included them.
- The depth of your dependency tree, which shows how much third party code you rely on.
None of this is a secret in the way a password is. But it is information that helps someone plan an attack or understand a competitor's stack, so it is reasonable to control.
Decision guide by level of detail
| What you share | Typical handling |
|---|---|
| Statement that you produce SBOMs, with format and cadence | Public, no NDA |
| Top level component and license list | Often shared freely, with named recipient |
| Full SBOM with transitive dependencies and versions | Confidentiality terms advisable |
| SBOM plus vulnerability and exploitability status | Confidentiality terms and restricted access |
| SBOM with internal package names or paths | Redact first, then apply terms |
The more an SBOM is joined with unpatched findings, the more it behaves like a pentest report and the more careful you should be.
Practical steps
- Check existing paper. Your master agreement may already cover confidential information, in which case a separate NDA adds nothing. Ask legal.
- Classify the SBOM version you plan to send. Use the table above.
- Redact what the customer does not need. See can you redact an SBOM before sharing it.
- Name the recipients and set an expiry. See how long a share link should last.
- Add a handling line to the file or cover note, for example "Confidential, for evaluation by named recipients".
When customers push back on an NDA
Some large buyers will not sign vendor paper but will rely on their own terms. Others, particularly public sector buyers, may want an SBOM as part of a requirement and may be subject to disclosure rules. In both cases, pause and involve legal, rather than deciding in a sales thread.
If an NDA will take weeks, offer a lower detail SBOM now, such as a component and license list, and the full file once terms are in place. That keeps the deal moving without overexposing you.
Do not use confidentiality to hide defects
Confidentiality exists to protect against misuse, not to avoid answering. If an SBOM reveals a serious problem in a component, the customer may need to know about it. Handle that through your vulnerability communication process, not by relying on terms to keep it quiet. See customer asks were we affected.
Safeguard's SBOM and dependency scanning generates the inventory, and you decide the level of detail and the terms for sharing it. A free scan lets you see a sample inventory.
Quick check
Is an SBOM public information?
Only if you publish it. Many vendors share SBOMs with customers on request, under terms, and publish only a summary.
Can you share a top level SBOM without an NDA?
Often, yes, but that is your call with legal. Share to named recipients and keep the version and date visible.
Last reviewed: 19 October 2026.
