Securing a connected vehicle supply chain means knowing every software component from every supplier, requiring evidence of their security practices, and keeping the ability to patch after sale. UN Regulation 155 already makes carmakers demonstrate supplier risk management as a condition of vehicle type approval in covered markets.
What does UN Regulation 155 say about suppliers?
The text of UN Regulation No 155, published in the EU Official Journal, covers vehicle cybersecurity and the cybersecurity management system (CSMS). An approval authority or technical service checks, by document review, that the manufacturer has taken measures to collect and verify information through the supply chain so as to demonstrate that supplier-related risks are identified and managed.
The same text expects the manufacturer to document risk assessments, test results and the mitigations applied to the vehicle type. Where supplier information is covered by intellectual property rights, the manufacturer or supplier must still make enough available for the checks to be done, and it is treated as confidential.
I did not fetch the other standards often cited in this field, so check them directly if your contracts reference them.
Why is a vehicle a hard case?
A modern vehicle is a network of electronic control units with firmware from many suppliers, and each supplier pulls in its own libraries, operating systems and open source. The carmaker integrates but rarely wrote most of the code. A flaw in a shared library can sit in several ECUs from several tier 1 suppliers at once, and vehicles stay on the road for many years.
CISA and its partners say in the 2026 SBOM minimum elements that components can include traditional software, firmware, AI systems and SaaS. That framing fits vehicles: the parts list should reach down to firmware.
What should the contract and the evidence include?
- A parts list per delivery. The 2026 minimum elements say each software version or update should have an associated SBOM, regenerated when a build changes or errors are corrected.
- Explicit unknowns. Suppliers should state what they cannot list, instead of leaving gaps silent.
- Advisory feeds. A way to learn that a component in a delivered ECU has a known flaw, ideally with exploitability status.
- Update ability. A defined path and support period for shipping fixes, since the regulation looks at the whole lifecycle.
What does a worked example look like?
Constructed example: a carmaker's infotainment supplier ships a firmware image containing an open source media library. A flaw in that library is announced. With a per-delivery SBOM the carmaker's security team searches its inventory, finds the library in two ECU variants from two suppliers, asks each for exploitability status and schedules the update for the model years affected. Without the SBOMs, the same question means emailing every supplier and waiting.
What makes the long life of a vehicle a security issue?
A phone gets replaced in three years. A vehicle may be driven for fifteen or more, and the software inside it is frozen at build time unless an update path exists. Components that were fine at release will collect advisories for the rest of the vehicle's life.
That shifts the question from "is this component clean today?" to "will we know when it stops being clean, and can we fix it?" Knowing needs the parts list per delivery. Fixing needs a tested update mechanism and a supplier still contractually bound to help. Both should be settled before production, because they are hard to add afterwards.
What to do
- Map your ECUs and the supplier of each one's software.
- Add SBOM delivery, per release, to supplier contracts, in SPDX or CycloneDX.
- Require suppliers to flag unknown or withheld components.
- Store SBOMs in one searchable inventory keyed by vehicle program and ECU variant.
- Subscribe to advisories for the components you find, and ask suppliers for exploitability statements.
- Test your update path before you need it, including rollback.
- Keep the evidence trail that your approval authority will ask for.
Safeguard's SBOM and dependency scanning and reachability analysis can handle the software component side of this inventory work. Vehicle-specific engineering, hardware and approval processes sit outside it.
Quick check
Does the regulation require an SBOM?
Not by that name in the text we fetched. It requires supplier risk to be identified and managed with verified information, and an SBOM is a practical way to produce that evidence. Check your approval authority's expectations.
Who is responsible, the carmaker or the supplier?
The regulation puts the demonstration burden on the vehicle manufacturer. Contracts decide how much of the evidence suppliers must provide.
Sources
- UN Regulation No 155 (EUR-Lex, 2021/387)
- CISA, 2026 Minimum Elements for a Software Bill of Materials (SBOM)
Last reviewed: 18 October 2026.
