Share an SBOM in SPDX or CycloneDX, signed if possible, through a channel your customer can automate: delivered with the install, at a version-specific URL, through an API or from a public repository. Expect customers to ask about completeness, how fresh it is, and which listed vulnerabilities truly apply.
Which format should you use?
The 2026 CISA minimum elements name SPDX and CycloneDX as the two data formats widely used by ecosystem stakeholders, both open, international, machine-processable and human-readable. SPDX is also an ISO standard, ISO/IEC 5962:2021, and CycloneDX is Ecma standard ECMA-424. The guidance says organizations should accept any widely used, interoperable and machine-processable format, and avoid accepting SBOMs for new software in deprecated versions of a format.
Practical rule: produce one format as primary, convert to the other on request, and record the format name and version in the SBOM metadata, which the 2026 elements list as fields.
How do you deliver it?
The 2026 document says SBOMs should be available promptly to those who need them. Access controls may limit sharing with unauthorized parties but should not stop sharing between authorized ones or block integration into trusted tools. It lists these ways: with the installation, at a version-specific URL, through an API to a database, or in a public repository.
CISA's SBOM Sharing Primer gives examples in use today, from a proprietary vendor sending SBOMs by email to open source projects publishing in central repositories. Email works for a handful of customers. Past that, an API or portal saves time.
For hosted software, the document notes that high frequency change can overwhelm both sides if every deploy sends an SBOM, and says APIs can serve snapshots in CI/CD flows.
What should travel with the SBOM?
- A signature, so the customer can confirm it was not changed after you made it.
- The generation context and tool version, so they can judge quality.
- A statement of unknowns, so gaps are visible.
- Optionally a VEX or CSAF advisory, to say which listed vulnerabilities do or do not affect the product.
What will customers ask?
Plan answers to these.
- Is it complete, including transitive dependencies?
- How was it generated, from source, build or scan?
- How often is it updated, and how do I know a new one exists?
- Does it list a vulnerable component, and am I affected?
- Can I get it in my tool's format?
- Who can see it, and how is it protected?
- What do you do when it contains an error?
The guidance expects authors to correct errors promptly and customers to accept corrections.
What does this look like?
Constructed example: a vendor publishes for each release a CycloneDX file, a detached signature and an optional VEX file at a stable URL pattern with product and version. A customer's tool polls an index endpoint nightly. When a CVE lands, the vendor adds a VEX statement saying the component is present but the function is not reachable. The customer's tool downgrades the finding automatically.
What are common mistakes in sharing?
Sending an SBOM once at contract signing and never again. Sending a file with no version, so the customer cannot tell which release it describes. Changing the file after delivery without a new version number. And locking the SBOM behind a portal that customers cannot script against.
Each mistake undermines the point. The data should be tied to a release, be dated and versioned, and be easy for the customer's own tools to fetch.
What to do
- Choose a primary format and a conversion path.
- Fill the metadata fields: author, tool, format, version, timestamp, generation context.
- Sign every SBOM and publish the verification method.
- Provide a stable URL pattern and an index endpoint for each product.
- Put access control in front of the data without blocking authorized customers.
- Publish advisory statements when new CVEs affect listed components.
- Write a short customer FAQ based on the seven questions above.
Safeguard's SBOM and dependency scanning supports generating inventory in standard formats. Your delivery channel and signing keys are yours to run.
Quick check
Is emailing a PDF of the SBOM acceptable?
A PDF is not machine-processable, which is the point of the format. Send SPDX or CycloneDX files so tools can ingest them.
Do we send a new SBOM every deploy?
For each version or update, yes, per the guidance. For high frequency hosted software, snapshots through an API can reduce the load.
Sources
- CISA, 2026 Minimum Elements for a Software Bill of Materials (SBOM), full PDF
- CISA, SBOM Sharing Primer
- CISA, Minimum Requirements for Vulnerability Exploitability eXchange (VEX)
Last reviewed: 18 October 2026.
