Yes, sharing an SBOM with customers is generally safe. It lists the components in your software, not your source code. Government guidance says attackers do not need it to cause harm, and that you can choose who gets it. Share it on purpose, with access controls that fit the customer.
TL;DR
- An SBOM lists parts, not code. It is an ingredient list, not a recipe.
- You do not have to publish it to the world. Sharing with a customer is a separate choice.
- The risk that attackers learn from it is real in theory, but guidance says defenders gain more.
- Use a sharing method that matches the audience, and keep it current.
Definition. An SBOM (software bill of materials) is a nested inventory, a list of the ingredients that make up software, as CISA and NTIA describe it.
Is an SBOM a roadmap for attackers?
This is the myth people raise most. If you publish your parts list, will attackers use it to pick on your weakest part?
NTIA's SBOM Myths vs. Facts sheet answers this directly. It says attackers can use the information in an SBOM, but "the defensive benefits of transparency far outweigh this common concern as SBOMs serve as a 'roadmap for the defender'." It makes three points:
- Attackers do not need SBOMs. Mass attacks like WannaCry show that "foreknowledge is not a prerequisite to cause harm."
- Attackers' tools can already identify components. For defenders, it is often hard and inefficient to find the same facts.
- Much of this is already visible. Licensing rules have required disclosure of many components for decades.
CISA's own SBOM FAQ says the same thing in similar words and begins with an honest "theoretically, yes." That is a fair framing. The information is useful to anyone. The question is whether the benefit goes to defenders at scale, and the guidance says it does.
This does not mean you should post everything everywhere. That brings us to the next myth.
Does an SBOM have to be public?
It does not. NTIA's sheet says: "An SBOM does not need to be made public. The act of making an SBOM is separate from sharing it with those who can use this data constructively."
It adds that Executive Order 14028, the 2021 order on improving the nation's cybersecurity, treats public posting as a choice. The order text it quotes says an SBOM can be provided to a purchaser "directly or by publishing it on a public website." CISA's FAQ says that for publicly available open source software it makes sense to make the SBOM public, and that other cases depend on sector rules and legal requirements.
So you have options, from open to private:
| Option | Who sees it | Good fit |
|---|---|---|
| Public web page | Anyone | Open source projects |
| Customer portal login | Customers only | Commercial software |
| Sent with each release | Whoever receives the release | Products shipped to customers |
| API with access keys | Approved partners | Large customers with tools |
| Under an agreement | Named parties | Sensitive environments |
CISA's FAQ lists several ways to share, including distributing the SBOM with the source or binary, posting it on the manufacturer's website, or using a trusted third party's website. The 2026 guidance adds that an SBOM can be accessible through a version specific URL, an application programming interface, or a public repository.
Does an SBOM expose my intellectual property?
An SBOM names components. It does not contain your code.
NTIA's sheet says "SBOMs are a summary of included software components and do not expose intellectual property (IP). Patents and algorithms are not included." It uses a simple image: "There is a difference between a list of ingredients and a recipe." And it says "Code is not included in an SBOM, just component references."
Two cautions are worth passing along.
First, the sheet notes that contracts or legal agreements may prohibit disclosing certain components. In that case, the SBOM can show a "known unknown" component. CISA's 2026 guidance agrees and says the author should state whether information is unknown or withheld, and should have a process for recipients to ask about redacted, security related information.
Second, the FAQ says some organizations try to claim that the list itself is a trade secret, and that your legal team is the right group to advise whether that claim holds up. This post is not legal advice. If you have a contract question, ask a lawyer.
Can I limit who gets to see my SBOM?
The 2026 minimum elements guidance has a practice called Distribution and Delivery. It says SBOMs should be available promptly to those who need them. It then says access controls "may limit the sharing of SBOM data with unauthorized parties but should not prevent information sharing between authorized parties or restrict organizations from integrating SBOM data into trusted security tools."
In plain terms, you can lock the door, but you should hand a key to the customers who need to come in.
How do I share an SBOM safely, step by step?
- Decide who the audience is. Public, customers, or a single buyer. The answer sets the method.
- Choose a delivery method. A login page, an API or an email attachment each work. Pick the one your customers can actually use.
- Keep one SBOM per release. The 2026 guidance says each version or update should have its own SBOM, and a corrected one should follow if you find errors.
- Review before first sharing. Look for internal names, private package names or anything covered by contract. Mark withheld items as withheld, not missing.
- Offer a contact route. Give recipients a way to ask about redacted or unclear entries.
- Sign it if you can. The 2026 guidance adds an SBOM Author Signature element so a reader can confirm the file is what the author made.
- Log who has it. Keep a simple record of who received which version, so you know whom to update.
- Pair it with context. Share a VEX statement if you want to explain flaws that do not apply.
For a deeper walk through of what to send, see what to send when a customer asks for your SBOM and signed SBOMs and attestations.
Worked example: a mid size software company
Names and numbers are invented to show the process.
A company sells a business app. Sales sends 12 SBOM requests a month, each by email. Support says it takes about 30 minutes to produce one by hand, so that is roughly 6 hours a month (12 times 30 minutes). Customers also complain that the files are out of date.
The company changes its approach:
| Before | After |
|---|---|
| SBOM built by hand on request | SBOM generated automatically at every release |
| Sent by email | Posted in a customer login area |
| Often out of date | Matches the release number |
| No record of who has what | Access log kept |
Per request, the manual work falls to a few minutes of granting portal access. Customers get the right version, and the company can tell exactly who received it. Nothing about the source code was shared at any point.
Try it yourself
Open the demo below and look at the kind of information a dependency inventory shows: names, versions and where each package came from. Notice that no source code appears anywhere.
Click through it at your own pace, or open it full screen.
How can Safeguard help?
Safeguard's SBOM and dependency scanning produces SBOMs for your projects in SPDX or CycloneDX, so you have a current file for each release. Reachability analysis helps you back up statements about which flaws apply. Compliance and evidence automation helps you keep records organized for customer reviews, though it does not by itself certify anything.
You can try a free scan at gold.safeguard.sh/scan. The Safeguard CLI can run the scan in your pipeline, and it can also write code if a dependency fix needs a small change.
Quick check
Does an SBOM contain my source code?
No. It contains component references such as names and versions. NTIA says code is not included in an SBOM.
Do I have to post my SBOM publicly?
No. Making an SBOM and sharing it are separate choices. You can share it with customers only, through a portal, an API or with each release.
Can attackers use an SBOM?
In theory, yes. Government guidance says the defensive benefits are larger, because attackers can already identify components, and defenders gain a fast way to answer "am I affected?"
Sources
- NTIA, SBOM Myths vs. Facts: https://www.ntia.gov/page/software-bill-materials
- CISA, SBOM FAQ: https://www.cisa.gov/resources-tools/resources/sbom-faq
- CISA and partners, 2026 Minimum Elements for a Software Bill of Materials (SBOM): https://www.cisa.gov/resources-tools/resources/2026-minimum-elements-software-bill-materials-sbom
Last reviewed: 19 October 2026.
