Can you send us a list of third party components in our deployment?

Yes, in most cases, scoped to the exact version and deployment the customer runs. Send a machine-readable SBOM for that release, state what it covers and when it was generated, and share it under an agreed channel rather than as a public file.

Scope it before you send

Customers often ask for "the list" without saying which one. Settle four things.

1. Product and version. Match the release the customer runs, not the latest build.
2. Deployment type. Hosted service, on premises package, container image or client application each have different component sets.
3. Layers. Application dependencies, container base image, and any bundled runtimes.
4. Purpose. Vulnerability checking, license review or procurement paperwork.

CISA describes an SBOM as a nested inventory of the ingredients that make up software components. Its minimum elements guidance sets a baseline of data fields that a useful list should carry.

Pick a format

SPDX and CycloneDX are the two widely used machine-readable formats. SPDX is an ISO/IEC standard (5962). Ask the customer which they prefer. If you can produce both, say so. Do not send a PDF screenshot of a table alone, because the customer cannot scan it.

Caveats to state in the cover note

• The date and tool that produced the list.
• What it excludes, such as internal build tools or hosted infrastructure.
• That presence of a component in the list does not mean a vulnerability is exploitable in the product.
• Who to contact with findings.

That third point prevents a flood of scanner reports. The posts on what to send when a customer asks for your SBOM and replying to a customer's findings cover the file and the follow up.

Cover note template

Attached is the component list for version X as deployed in your environment, in CycloneDX JSON, generated on date. It covers application dependencies and the container base image. It does not include internal build tooling. A listed component is not a statement of exposure. If your scanner raises findings, send them to the contact below and we will respond with exposure details.

What to leave out

Internal repository names, private package names that reveal architecture, and anything covered by a third party's confidentiality terms. Check before sending, because SBOMs can expose naming you did not intend to share.

Handling follow up findings

After you send the list, the customer's team may scan it and write back. Agree upfront on a contact and a response time. For each finding, reply with the component, whether the vulnerable code is present and reachable, and what you plan to do. Most scanner output is about presence, not exposure, so the reply that adds exposure analysis is the useful one.

Try it yourself

Click through it at your own pace, or open it full screen.

Look at how components are grouped by project and version. That grouping is how you produce a list per release.

Safeguard generates SBOMs per project, and you can try it with the free scan at gold.safeguard.sh/scan.

Quick check

Sources

• CISA, Software Bill of Materials
• CISA, 2025 Minimum Elements for a Software Bill of Materials
• SPDX overview
• CycloneDX specification overview

Last reviewed: 19 October 2026.