A modern vehicle is a distributed computing platform on wheels. A premium car contains upward of 100 electronic control units (ECUs), runs 100-150 million lines of code, and communicates with cloud services, mobile apps, and other vehicles. The software supply chain that feeds these systems is vast, fragmented, and until recently, almost entirely opaque.
The automotive industry is now being forced to reckon with this reality. Regulatory pressure from UNECE WP.29, industry standards like ISO/SAE 21434, and the sheer volume of vulnerabilities affecting connected vehicles are driving OEMs and their suppliers to adopt Software Bills of Materials as a foundational practice.
The Regulatory Landscape
UNECE WP.29 R155 and R156
The United Nations Economic Commission for Europe published two regulations that have reshaped automotive cybersecurity:
R155 (Cybersecurity Management System) requires vehicle manufacturers to implement a Cybersecurity Management System (CSMS) that covers the entire vehicle lifecycle, from design through decommissioning. It mandates risk assessment, vulnerability monitoring, and incident response for all connected vehicles.
R156 (Software Update Management System) requires manufacturers to have a Software Update Management System (SUMS) that can safely deliver over-the-air (OTA) updates and maintain integrity of the vehicle software throughout its lifecycle.
Both regulations took effect for new vehicle types in July 2022 and apply to all new vehicles produced from July 2024. They apply to all vehicles sold in countries that recognize UNECE regulations, which includes the EU, UK, Japan, South Korea, and others. While the US does not directly adopt UNECE regulations, US manufacturers selling into these markets must comply.
Neither regulation explicitly mandates SBOMs. But the requirements for vulnerability monitoring, supply chain risk management, and software update tracking are effectively impossible to meet without a software inventory. You cannot monitor for vulnerabilities in components you have not inventoried.
ISO/SAE 21434
This standard provides the detailed engineering framework for implementing automotive cybersecurity. It covers threat analysis and risk assessment (TARA), cybersecurity requirements, and verification throughout the development lifecycle.
Section 7 on distributed cybersecurity activities is particularly relevant. It defines cybersecurity interface agreements between OEMs and their suppliers, including expectations for vulnerability disclosure and component documentation. Again, SBOMs are the practical mechanism for meeting these requirements.
The Automotive Supply Chain Challenge
Automotive software supply chains are uniquely complex for several reasons.
Tiered supplier structure. OEMs do not write most of their vehicle software. They procure it from Tier 1 suppliers (Bosch, Continental, Denso), who in turn source from Tier 2 and Tier 3 suppliers. Each tier may use open-source components, third-party libraries, and proprietary firmware. An OEM may be four or five layers removed from the actual code running in their vehicle.
Long vehicle lifecycles. A vehicle platform may be in production for 7-10 years and on the road for 15-20 years. The software supply chain must be managed for the entire support period, which means tracking vulnerabilities in components that may have been selected a decade ago.
Mixed criticality. A single vehicle contains safety-critical systems (braking, steering, airbags), security-critical systems (keyless entry, immobilizer), and comfort systems (infotainment, climate control). Each has different assurance requirements, but they increasingly share software platforms and communication buses.
Real-time and embedded constraints. Many ECUs run real-time operating systems (RTOS) with custom firmware. Traditional SBOM tooling designed for Linux containers or npm packages does not work well in this environment. Binary analysis, firmware extraction, and custom parsers are often required.
Building an Automotive SBOM Program
Component Identification
The first challenge is identifying what software is actually running in the vehicle. This requires:
- Manifest analysis for ECUs with standard package managers (Android Automotive, Linux-based systems)
- Binary analysis for proprietary firmware where source code is not available
- Supplier-provided BOMs for Tier 1 components
- Hardware-specific analysis for microcontrollers with embedded software
The output should use standard SBOM formats (CycloneDX or SPDX) with automotive-specific metadata. Package URLs (purls) provide consistent identification for open-source components, while CPEs can be used for proprietary software that has NVD entries.
Vulnerability Monitoring
Automotive vulnerability monitoring differs from enterprise IT in several ways. Patches cannot be deployed instantly -- OTA updates require extensive testing and may need regulatory approval. Meanwhile, the vehicle is on the road and potentially exposed.
A practical automotive vulnerability monitoring process includes:
- Continuous correlation of vehicle SBOMs against NVD, OSV, and vendor-specific advisory feeds
- Risk assessment that considers the vehicle's architecture -- is the vulnerable component reachable from an external attack surface?
- Severity adjustment based on automotive context -- a vulnerability in an infotainment system is different from one in a brake controller
- VEX statements documenting exploitability decisions for each vulnerability in each vehicle platform
Supplier Integration
Getting SBOMs from suppliers is the hardest part of the program. Start by:
- Adding SBOM requirements to cybersecurity interface agreements (as defined in ISO 21434)
- Specifying minimum BOM quality: format, required fields, update frequency
- Providing tooling guidance to smaller suppliers who may not have SBOM generation capabilities
- Validating received BOMs for completeness and accuracy
Many Tier 1 suppliers are building their own SBOM programs in response to OEM demands. The challenge is at Tier 2 and below, where companies may have limited security maturity. OEMs that invest in supplier enablement will see faster adoption.
Lifecycle Management
Because vehicles have such long lifecycles, SBOM management must extend well beyond initial production. Key practices include:
- Maintaining a current SBOM for each vehicle platform and ECU software version
- Tracking which vehicles in the field are running which software versions
- Correlating new vulnerability disclosures against the fleet in real time
- Planning and executing software updates with full understanding of what changed
This is where the difference between a one-time SBOM and a managed SBOM program becomes starkly apparent. A static BOM from 2022 is useless for responding to a vulnerability disclosed in 2025.
The Road Ahead
The automotive industry is still in the early stages of SBOM adoption. Most OEMs have internal programs in various stages of maturity, but supply chain integration is patchy and tooling for embedded/RTOS environments is immature.
Several trends will accelerate adoption:
- Software-defined vehicle architectures that consolidate ECUs and move to standard operating systems (Android Automotive, Linux) make SBOM generation easier
- AUTOSAR Adaptive Platform includes provisions for software component inventory that align with SBOM practices
- Type approval requirements in the EU will increasingly require demonstrable software transparency
- Vehicle Security Operations Centers (VSOCs) need accurate software inventories to perform effective threat monitoring
How Safeguard.sh Helps
Safeguard.sh provides the centralized SBOM management platform that automotive OEMs and suppliers need to meet R155, R156, and ISO 21434 requirements. It ingests BOMs from multiple sources and formats, correlates them against vulnerability databases with automotive-relevant context, and maintains version history across the entire vehicle lifecycle.
For supplier management, Safeguard.sh offers a portal where Tier 1 and Tier 2 suppliers can submit SBOMs, receive automated quality validation, and get notified when new vulnerabilities affect their components. This reduces the manual coordination overhead that currently makes automotive SBOM programs so resource-intensive.