A useful SBOM request to a vehicle software supplier asks for a machine readable list of components and versions for each delivered release, tied to a unit and a software version. It supports UN R155 monitoring and UN R156 records, because you cannot assess a new vulnerability without knowing what you ship.
Why suppliers matter here
UL notes that suppliers are covered alongside manufacturers under the UNECE obligations, and that OEMs and suppliers must design products to stay secure through their life cycle, continuously evaluating and acting on new vulnerability information. UL's page does not detail how supplier oversight should work, so the contract is where you spell it out.
Clause 8 of ISO/SAE 21434, as summarized by UL, requires manufacturers to continually check that risk assumptions and countermeasures remain up to date. A new vulnerability in a library is exactly the event that tests that.
What to put in the request
- Format. Ask for a standard machine readable format. Common choices are covered in the post on CycloneDX and SPDX.
- Scope. One SBOM per delivered release, per control unit variant, not one per company.
- Depth. Direct and transitive components, including the operating system, middleware and libraries linked into the image.
- Identifiers. Package identifiers and versions precise enough to match against vulnerability data.
- Link to your records. The SBOM should name the software version that matches your update records, which supports the R156 documentation UL lists, such as hardware and software versions per system.
- Update cadence. A new SBOM whenever the code changes, and a promise to tell you when a component they ship gets a vulnerability report.
- Exploitability statements. Ask for a way to say when a known vulnerability does not affect the product, so you do not triage the same noise twice.
What to do with them
- Load each SBOM into an inventory keyed by unit and software version.
- Match it against new vulnerability reports when they appear.
- Use the match to update your risk assessment entries and decide whether an update is needed.
- Keep the SBOM with the release record, since an auditor may ask what you knew at the time.
Limits
An SBOM tells you what is in the code. It does not tell you if the code is safe, whether a flaw is reachable or whether the build was clean. Treat it as the inventory that every other control builds on.
Click through it at your own pace, or open it full screen.
Where Safeguard fits
Safeguard offers SBOM and dependency scanning, and reachability analysis to separate flaws that can be exercised from ones that cannot. You can try a free scan at gold.safeguard.sh/scan.
Quick check
Is one SBOM per supplier enough?
No. Components change with every release and differ between unit variants, so ask for one per release and variant.
Sources
Last reviewed: 19 October 2026.
