In CISA's automotive example, each tier writes an SBOM for its own software, passes it to the next tier's portal, and a tier one supplier bundles the upstream files with its own for the carmaker. The carmaker ends up with SBOMs for its parts without asking each upstream supplier. The example is illustrative, not a rule.
The chain in CISA's example
CISA's SBOM Sharing Primer uses a traditional automotive chain to show the distributor role.
- A tier 3 supplier produces an open source library.
- A tier 2 supplier uses it, in part, to make a GPS application. Under its contract it generates an SBOM internally and gives it to the tier 1 supplier with the product. The tier 2 supplier acts as SBOM author.
- A tier 1 supplier builds the ready-to-install infotainment system. It creates SBOMs for software it wrote, then bundles the tier 2 SBOMs with its own and makes them available to the automaker. It acts as both distributor and author.
- The OEM, the automaker, acts as SBOM consumer.
The primer notes that almost every supplier is also a consumer. It also says SBOM operations in the industry are still at an early stage of adoption, with a growing consensus that SBOMs will join the documents routinely exchanged.
How it works in practice
CISA describes an upstream supplier uploading SBOMs to the downstream tier 1 supplier's or the OEM's portal or secure document exchange. Each portal is unique to the supplied part. The OEM can then see SBOMs for its parts without requesting access from every upstream firm, using what the tier 1 supplier uploaded. An SBOM request may sit beside existing contract documents such as NDAs and cybersecurity interface agreements.
CISA rates this pattern as medium for discovery, high for access control (the upstream supplier has effectively delegated authentication to the OEM) and medium for transport.
Where chains get stuck
The primer lists cautions that match what teams report:
- Duplicated effort. Each OEM may require its own format or portal.
- Confidentiality. SBOMs for proprietary components are unlikely to be public.
- Quality along the chain. A footnote notes that bundling raises the question of verifying SBOM data from upstream, and then places it out of scope.
For a connected vehicle, add a practical issue: the SBOM must map to a vehicle software version that is actually in the field, or it is little help in a recall. See how to scope a vehicle software recall with an SBOM.
What to do as a supplier
- Keep one SBOM per delivered software version, with a record of which customer received which.
- Agree format and portal in the development interface agreement before delivery.
- Mark unknowns honestly. A missing upstream SBOM should be shown as unknown, not hidden.
- If you bundle upstream SBOMs, say so, and record who authored each.
For questions to put to suppliers, see SBOMs for vehicle software: what to ask your suppliers for, and for the US rule on connected vehicles see the connected vehicle rule explained.
Quick check
Who is the SBOM author at tier 2 in the example?
The tier 2 supplier, which generates an SBOM for its own software under its contract.
Does the OEM have to request each SBOM from upstream tiers?
In the example, no. The tier 1 supplier bundles and uploads them, so the OEM can reach them through the portal.
Sources
Last reviewed: 19 October 2026.
