A modern vehicle contains over 100 million lines of code. That number is growing as vehicles become more connected, more automated, and more software-defined. Every one of those lines -- and the open-source libraries, third-party components, and embedded firmware they depend on -- represents a potential vulnerability that could affect vehicle safety.
The automotive industry is waking up to this reality. UNECE WP.29 regulations, ISO/SAE 21434, and national cybersecurity requirements are forcing manufacturers to treat software supply chain security as a vehicle safety issue. This is a fundamental shift from how the industry has traditionally approached software.
The Automotive Software Supply Chain
Modern vehicles are rolling software platforms. The software ecosystem in a typical connected vehicle includes:
Infotainment systems. Built on Linux, Android Automotive, or QNX, these systems run hundreds of software packages and connect to external networks via cellular, Wi-Fi, and Bluetooth.
ADAS and autonomous driving. Advanced driver assistance systems rely on complex software stacks including sensor fusion, machine learning models, mapping, and real-time operating systems.
Powertrain and chassis control. Engine management, transmission control, stability systems, and braking systems all run on embedded software.
Body electronics. Door locks, window controls, lighting, and climate control are managed by software.
Telematics and connectivity. Vehicle-to-cloud, vehicle-to-vehicle, and vehicle-to-infrastructure communication systems depend on networking stacks, cryptographic libraries, and protocol implementations.
Each of these domains has its own software supply chain, from the RTOS kernel to application libraries to third-party middleware. A single vehicle might contain software from dozens of Tier 1 suppliers, each with their own supply chains.
UNECE WP.29: What It Requires
UNECE WP.29 regulations UN R155 (Cybersecurity Management System) and UN R156 (Software Update Management System) became mandatory for new vehicle types in the EU and other UNECE member countries in July 2022, with all new vehicles covered from July 2024.
UN R155 -- Cybersecurity Management System (CSMS)
R155 requires manufacturers to establish a Cybersecurity Management System that includes:
- Risk assessment covering the vehicle, its components, and the supply chain
- Cybersecurity measures throughout the vehicle lifecycle, from concept to decommissioning
- Supply chain management to ensure that cybersecurity risks from suppliers are identified and managed
- Incident monitoring and response for cybersecurity events affecting vehicles in the field
For software supply chain security, R155 means you must:
- Identify and assess risks from software components, including open-source and third-party libraries
- Require suppliers to implement cybersecurity measures for their software
- Monitor for and respond to vulnerabilities in vehicle software components throughout the vehicle's lifetime
UN R156 -- Software Update Management System (SUMS)
R156 requires manufacturers to manage software updates securely, including:
- Secure delivery of software updates to vehicles
- Validation of update integrity and authenticity
- Management of software versions across the vehicle fleet
- Documentation of all software configurations
SUMS requires knowing exactly what software is in every vehicle. Without SBOMs, this is guesswork.
ISO/SAE 21434: The Technical Standard
ISO/SAE 21434 provides the technical framework for automotive cybersecurity engineering. It covers the full lifecycle and includes specific supply chain requirements:
- Clause 7: Cybersecurity management at the organizational level, including supplier management
- Clause 15: Distributed cybersecurity activities, defining how OEMs and suppliers share cybersecurity responsibilities
The standard requires threat analysis and risk assessment (TARA) that includes supply chain threats. This means evaluating the risk that a compromised software component could affect vehicle cybersecurity.
Practical Challenges for Automotive
Tier Structure Complexity
The automotive supply chain is multi-tiered. An OEM receives ECUs from Tier 1 suppliers, who source components from Tier 2 suppliers, who use software from Tier 3 and beyond. Software supply chain visibility degrades at each tier.
An OEM might receive an ECU from a Tier 1 supplier and have no visibility into the operating system, middleware, and open-source libraries inside it. Yet under R155, the OEM is responsible for the cybersecurity of the complete vehicle.
Getting SBOMs from Tier 1 suppliers is challenging enough. Getting them from Tier 2 and Tier 3 suppliers is a major industry coordination effort that is still in early stages.
Long Vehicle Lifecycles
Vehicles are designed for 10-15 years of service. Software components that are current at the time of development may have dozens of known vulnerabilities by the time the last vehicle rolls off the production line. Monitoring and managing vulnerabilities across a fleet with different software configurations, over a decade or more, requires systematic component tracking that most OEMs don't have.
Legacy ECU Constraints
Many ECUs have limited memory, processing power, and connectivity. They may not be updatable over-the-air. They may run proprietary real-time operating systems where traditional SBOM tools don't work. Yet they still contain software components that can be vulnerable.
Mixed Criticality
A vehicle runs safety-critical software (braking, steering) alongside non-safety-critical software (infotainment). The supply chain requirements for ASIL-D safety-critical software are different from those for QM-rated entertainment systems. Your supply chain security program needs to account for these differences.
Building an Automotive Software Supply Chain Program
Map Your Software Architecture
Start with a complete mapping of your vehicle software architecture:
- What ECUs are in each vehicle platform?
- What software runs on each ECU?
- Which software comes from Tier 1 suppliers?
- Which components are open source?
This mapping is the foundation for everything else. Without it, you can't assess risks, manage vulnerabilities, or meet R155 requirements.
Implement SBOM Requirements Across the Supply Chain
- For internally developed software: Integrate SBOM generation into your build pipeline. Generate SBOMs in CycloneDX or SPDX format with every build.
- For Tier 1 supplier software: Add SBOM delivery requirements to contracts. Specify format, completeness expectations, and update frequency.
- For open-source components: Maintain an internal registry of approved open-source components with associated SBOMs and vulnerability tracking.
Establish Continuous Vulnerability Monitoring
Vehicle software doesn't stop needing security attention after production. You need:
- Continuous matching of vehicle software components against vulnerability databases
- Impact assessment processes that consider vehicle safety implications
- Coordinated disclosure and response processes with suppliers
- Fleet-wide vulnerability tracking across vehicle platforms and configurations
Integrate With TARA
Your Threat Analysis and Risk Assessment process should incorporate supply chain threats:
- Component-level threat scenarios (what if this library is compromised?)
- Supply chain attack paths (how could an attacker target a supplier to reach your vehicle?)
- Risk mitigation through component selection, isolation, and monitoring
How Safeguard.sh Helps
Safeguard.sh helps automotive manufacturers and suppliers build the software supply chain visibility that UNECE WP.29 and ISO 21434 require. The platform automates SBOM generation for build pipelines, ingests supplier-provided SBOMs, and provides continuous vulnerability monitoring across vehicle software platforms.
For OEMs managing complex multi-tier supply chains, Safeguard.sh provides a centralized platform to collect, store, and monitor SBOMs from Tier 1 and Tier 2 suppliers. When a vulnerability is disclosed, the platform identifies affected vehicle platforms and software versions, enabling rapid assessment of fleet impact.
Safeguard.sh supports the lifecycle monitoring that automotive cybersecurity demands -- tracking software components not just at production, but throughout the vehicle's service life, enabling the continuous risk management that R155 requires.