SBOM in software supply chains
How SBOMs are shared between supplier and customer
A software supply chain is every link that contributes to the finished product: in-house code, open source, commercial components, build tools and the suppliers behind them.
The comparison with a list of ingredients is common. Someone ordering food can have many reasons to want to know what it contains. In the same way, an organisation can have several reasons to want to know what a piece of software contains: known vulnerabilities, components that are no longer maintained, licences that cannot be combined with the use, or suppliers that its own policy does not allow.
Why the supply chain is attacked
An attack on a component that many use reaches everyone who uses it.
- SolarWinds (2020). Attackers inserted malicious code into an update of the Orion monitoring software, which was then installed at thousands of customers.
- Log4Shell (2021). A vulnerability in the Log4j logging library affected a very large number of products that contained the library, often without the manufacturer knowing.
- xz Utils (2024). A backdoor had been inserted into the xz compression library by a person who had built up trust in the project over a long time. It was discovered before it spread widely.
What needs to be shared
An SBOM alone is not enough. Three kinds of information need to pass between supplier and customer:
| Information | Answers | Changes |
|---|---|---|
| SBOM | What does this version contain? | With every new version |
| VEX | Is the product affected by a specific vulnerability? | When vulnerabilities become known or are reassessed |
| Lifecycle dates | How long is the version supported with security updates? | When support changes |
Both roles at once
Most organisations are both customer and supplier. They receive SBOMs from their suppliers and hand their own to their customers. When a subcontractor's SBOM is brought into your own, the customer gets a record that covers the whole product.
How it works in practice
Today SBOMs are often sent as email attachments or placed in a customer portal. That works for single deliveries but becomes unmanageable with many suppliers, many versions and information that changes over time.
What is needed is:
- A fixed place per supplier and product, holding the current SBOM and older versions.
- Automatic delivery from the supplier's build pipeline, so that every version gets its SBOM.
- Access control, so that each customer only sees what concerns it.
- Traceability, so that you can show what was shared and when.
Ecma is working on a standard for exchanging such documents, the Transparency Exchange API. The Scale SBOM framework describes roles, responsibilities and content requirements.
Trust Repository from Bytesafe, which runs this site, is a tool for collecting SBOMs, VEX and lifecycle dates from suppliers and publishing your own to customers.
Getting started
- Create an SBOM for every version of your own software. See How to create an SBOM.
- Ask your most important suppliers for SBOMs, and write it into new contracts. See SBOM in public procurement.
- Monitor all SBOMs against new vulnerabilities. See SBOM and vulnerability management.