A modern vehicle, autonomous or not, runs software built from many suppliers and open source components. A flaw in one can affect safety, which is why vehicle regulators now ask manufacturers to show how they manage cybersecurity, including risks that come through suppliers. UN Regulation No. 155 is the main example.
What does UN Regulation 155 require?
UN Regulation No. 155 covers uniform provisions for approving vehicles with regard to cybersecurity and cybersecurity management systems. It was published in the EU's Official Journal (OJ L 82, 9.3.2021). We read the text on EUR-Lex for this article.
Two features stand out. First, manufacturers need a Certificate of Compliance for their Cybersecurity Management System (CSMS), issued by an Approval Authority after assessment. Second, the process for a vehicle type approval checks 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 are managed." The text also asks for documented risk assessments, test results and mitigations, cybersecurity measures in the design, and a description of how the supply chain was considered with respect to cybersecurity.
The regulation covers vehicles in general, not only autonomous ones. We are not aware of a source we could verify that sets out a separate software supply chain rule for self driving systems, and this article does not claim one.
Why does this matter for dependencies?
Because a vehicle's software stack is assembled. An infotainment system, a driver assistance module and a telematics unit may each come from different suppliers and contain open source libraries. If a library has a flaw, the manufacturer is expected to know that it is present and manage the risk, not only the supplier.
Standards and guidance reflect the same idea. Other frameworks commonly referenced in automotive security, such as ISO/SAE 21434, were not accessible for us to fetch, so check them directly for details. In general software terms, the NIST Secure Software Development Framework and the CISA SBOM guidance describe the inventory and verification practices that make "identify and manage supplier risk" achievable.
How do you make supplier risk concrete?
Move from promises to artifacts.
- A software bill of materials per supplied component, updated per release.
- A vulnerability disclosure contact and an agreed response time.
- A statement of how updates are delivered and verified.
- Evidence of testing, which the regulation asks to be documented.
- A way to tell, for a newly published flaw, whether the vulnerable code is present and reachable in a given component.
Reachability matters more than count. A long list of library issues is mostly noise. The few that can be triggered in your configuration need action.
What to do
- Require an SBOM from every software supplier and store it with the build it belongs to.
- Add vulnerability response terms to supplier contracts, including time limits.
- Match supplier SBOMs against new advisories continuously, not only at approval time.
- Record, for each match, whether the code is reachable and what you decided.
- Keep test results and risk assessments in a form you can show an assessor.
- Include update delivery in your threat model, since it is also an attack path.
- Read the regulation text and work with your approval authority on what evidence they expect.
Quick check
Does UN Regulation 155 apply to autonomous vehicles specifically?
It applies to vehicles within its scope, covering cybersecurity and cybersecurity management systems. It is not limited to autonomous driving.
Is an SBOM required by the regulation?
We did not find the term in the sections we read. The regulation requires that supplier related risks are identified and managed, and an SBOM is a practical way to evidence that.
Sources
- UN Regulation No 155, Official Journal 2021/387, via EUR-Lex
- NIST SP 800-218, Secure Software Development Framework
- CISA, Software Bill of Materials (SBOM)
Last reviewed: 18 October 2026.
