Often it is fine, but not automatically. An SBOM lists components and versions, which can expose internal package names, private repository paths, product structure and unpatched versions. Check what is in the file, check the assistant's data terms, and strip anything you would not email to an outside contractor.
Why an SBOM is not just a parts list
A public open source library name tells an observer nothing. The rest of the file can. Depending on the generator, an SBOM may include:
- Internal package and namespace names
- Private registry or repository URLs
- File paths from a build machine
- Author names and email addresses
- The exact versions you run, including known vulnerable ones
- Supplier and licence data that hint at commercial relationships
OWASP lists sensitive information disclosure as a distinct risk for LLM use, including confidential business data and security credentials. Its mitigations include data sanitization and clear policies on retention, usage and deletion. An SBOM is business data, so those apply.
Decide by audience and purpose
| Situation | Reasonable approach |
|---|---|
| Public open source project SBOM | Fine to share, nothing secret |
| Internal product SBOM, assistant under a contract you reviewed | Share after a field check |
| Internal product SBOM, personal or unreviewed assistant | Do not share |
| SBOM that includes paths or repo URLs | Redact those fields first |
Steps before you paste
- Open the file and search for private hostnames, repository URLs and file paths.
- List which components are internal. Replace their names with neutral placeholders if the question does not depend on them.
- Confirm which account and plan you are using, and read what it says about retention and training use.
- Remove people's names and emails.
- Share the smallest slice that answers your question, for example the ten components in one service, not the whole product.
- Note in your ticket that an assistant was used, and which data went in.
What to ask once it is safe
Good uses are formatting, explaining licence obligations in plain words, grouping components by ecosystem, or drafting a summary for a non-technical reader. Weak uses are asking the model which components are vulnerable. It will answer from memory of past advisories, which may be stale. Vulnerability matching should come from a scanner reading current advisory data. See what not to paste into an LLM during security work for the wider list.
Keep the SBOM itself accurate
An assistant can also introduce errors if you ask it to edit an SBOM. Treat any edited file as untrusted, and regenerate from the build rather than hand-patching a model's output. If you need a refresher on inventory basics, the demo below shows how components are discovered.
Try it yourself
Click through it at your own pace, or open it full screen.
Click into a few components and notice which fields appear for each, then ask which of them you would hesitate to share.
Where Safeguard fits
Safeguard generates SBOMs and scans dependencies inside your own workflow, so the vulnerability matching step does not need you to paste inventory into a chat window. You can start with a free scan at https://gold.safeguard.sh/scan.
Quick check
Is a CycloneDX or SPDX file safe because it is just metadata?
Not necessarily. Metadata can contain internal names, URLs and paths. Read the file before you share it.
Should the model tell me which components are vulnerable?
Use a scanner with current advisory data for that. A model may recall old advisories and miss recent ones.
Sources
- OWASP GenAI, LLM02:2025 Sensitive Information Disclosure: https://genai.owasp.org/llmrisk/llm022025-sensitive-information-disclosure/
- OWASP GenAI, LLM09:2025 Misinformation: https://genai.owasp.org/llmrisk/llm092025-misinformation/
Last reviewed: 19 October 2026.
