# SBOM in public procurement

What to require from the supplier, and how to follow it up

> An SBOM requirement in a procurement needs to state format, content, delivery and updates to be possible to follow up. This page covers what the requirement should contain, with example wording.

Updated: 5 October 2026  
URL: https://sbom.se/en/guides/public-procurement

An organisation that buys software takes over the risks in the components the software contains. With an SBOM from the supplier, the buyer can see what is included and monitor it against new vulnerabilities for the whole contract period.

From 11 December 2027 manufacturers must have an SBOM under the [Cyber Resilience Act (CRA)](https://sbom.se/en/cra/sbom-requirements). The regulation does not, however, require the SBOM to be handed to customers. Those who want it need to write that into the contract.

## What the requirement should contain

A requirement that only says the supplier must "provide an SBOM" cannot be followed up. State the following:

| Area            | What to state                                                                                                  |
| --------------- | -------------------------------------------------------------------------------------------------------------- |
| Format          | CycloneDX or SPDX, in a stated minimum version, as JSON                                                        |
| Content         | At least the [SBOM Minimum Elements](https://sbom.se/en/sbom/minimum-elements), including transitive dependencies             |
| Scope           | The whole delivered product, including components from subcontractors                                          |
| Timing          | An SBOM for every delivered version, at delivery at the latest                                                 |
| Delivery        | How the SBOM is handed over, for example through a portal, an API or a stated email address                    |
| Vulnerabilities | How the supplier communicates vulnerability assessments, for example as [VEX](https://sbom.se/en/vulnerabilities/what-is-vex) |
| Lifetime        | How long each version is supported with security updates                                                       |
| Confidentiality | Who at the buyer may access the SBOM and how it may be used                                                    |

## Example wording

> The supplier shall provide an SBOM for every delivered version of the product, in CycloneDX format (version 1.5 or later) or SPDX format (version 2.3 or later).

> The SBOM shall cover all components in the product, including transitive dependencies, and state supplier, name, version and a unique identifier (purl or CPE) for each component.

> Within ten working days of a vulnerability of high or critical severity becoming known in a component, the supplier shall state whether the product is affected.

The wording is an example and needs to be adapted to the procurement. Deadlines and versions are for you to decide.

## Follow up

* **Check every delivery.** Compare the SBOM against the requirements with a tool. [Why is SBOM quality important?](https://sbom.se/en/guides/sbom-quality) describes common gaps.
* **Monitor continuously.** New vulnerabilities are found in components that have already been delivered. The SBOM has to be compared against vulnerability data on an ongoing basis, not only at delivery.
* **Decide who owns the question.** Someone has to receive the SBOMs, monitor them and put questions to the supplier.

## Common objections from suppliers

* **"The SBOM reveals trade secrets."** An SBOM lists components, not source code. Confidentiality can be governed in the contract.
* **"We cannot create an SBOM."** There are [open-source tools](https://sbom.se/en/guides/create-an-sbom) that do it in the build. From December 2027 it is also a legal requirement for most products.
* **"The list of vulnerabilities will be misleading."** That is why VEX exists. The supplier can state which vulnerabilities do not affect the product.

## Support

The [Scale SBOM](https://sbom.se/en/resources/scale-sbom) framework contains content requirements for SBOM, VEX and VDR for both producers and consumers, and a model for roles and responsibilities.