Software is now central to vehicle performance, safety, cybersecurity and user experience. But as the amount of software in vehicles grows, so does the challenge of knowing exactly what is inside each system. An automotive Software Bill of Materials (SBOM) gives OEMs and suppliers a structured way to track software components, manage vulnerabilities, support compliance and respond faster when software supply chain risks emerge.
This article explains what automotive SBOMs are, why they matter for connected vehicles, how they link to HBOMs, UNECE R155, ISO/SAE 21434, the Cyber Resilience Act and the U.S. connected vehicle supply chain rule, and what OEMs and suppliers should do now to prepare.
What is an automotive SBOM?
An automotive SBOM, or Software Bill of Materials, is essentially an ingredients list for vehicle software. It shows what software components, open-source packages, third-party libraries, versions and dependencies are inside a connected vehicle system. For OEMs and suppliers, an SBOM helps answer a critical question: if a vulnerability is discovered, which vehicles, ECUs, software releases or supplier components are affected?
As vehicles become more connected, automated and software-defined, that question is becoming harder to answer without structured software supply chain visibility. Modern vehicles may depend on millions of lines of code, multiple Tier 1 and Tier 2 suppliers, open-source libraries, firmware, cloud APIs, infotainment systems, telematics platforms, mobile apps and over-the-air update pipelines.
That is why SBOMs are moving from a cybersecurity best practice to a core requirement for connected vehicle risk management.
Why automotive SBOMs are becoming a priority
Connected vehicles are no longer isolated mechanical products. They are digital platforms that communicate with cloud services, mobile applications, roadside infrastructure, charging networks, dealer systems, diagnostics tools and software update servers.
That connectivity creates value, but it also increases the attack surface.
A vulnerability in a third-party library, a compromised supplier component, an outdated firmware module or a poorly tracked open-source dependency can create risk across thousands or even millions of vehicles. Without a reliable SBOM, automotive cybersecurity teams may struggle to determine where a vulnerability exists, whether it is exploitable, which vehicles are affected and how quickly a fix can be deployed.
This is why SBOMs are becoming important in three overlapping areas:
Cybersecurity operations: Identifying vulnerable components and prioritizing remediation.
Regulatory compliance: Supporting lifecycle cybersecurity, vulnerability management and supply chain transparency.
Supplier governance: Giving OEMs better visibility into software dependencies across a complex multi-tier ecosystem.
In Automotive IQ's recent interview with Pawel Brzezinski, Senior Manager and Head of AES Cybersecurity Practice & Cybersecurity Domain Lead at HARMAN, he explains that SBOMs and HBOMs have "shifted from being seen purely as cybersecurity tools to also being compliance instruments."
That shift is crucial. SBOMs are no longer just something security teams might request after a vulnerability is found. They are increasingly becoming part of how OEMs prove that software supply chain risk is being managed continuously.
SBOM vs HBOM: what is the difference?
An SBOM focuses on software. It lists the software components, libraries, versions and dependencies used in a product or system.
An HBOM, or Hardware Bill of Materials, focuses on hardware. In automotive cybersecurity, HBOMs can help identify chips, modules, ECUs, connectivity components, processors, memory, wireless modules and other hardware elements that may introduce risk.
For connected vehicles, both matter.
A vulnerability may sit in software, but the risk may depend on the hardware environment where that software runs. Equally, a regulatory issue may relate to the origin of a connectivity module, telematics unit or automated driving component, not just the software code itself.
The U.S. Department of Commerce's final connected vehicle supply chain rule shows why this matters. The rule prohibits certain transactions involving Vehicle Connectivity System hardware and software, and Automated Driving System software, with sufficient links to China or Russia. It also sets software-related prohibitions for Model Year 2027 and hardware-related prohibitions for Model Year 2030.
For OEMs and suppliers, this kind of rule makes component visibility more than a technical issue. It becomes a market access, national security and compliance issue.
The key compliance drivers behind automotive SBOM adoption
SBOM adoption is being accelerated by several regulatory and policy trends. Some explicitly reference software supply chain transparency, while others create obligations that are difficult to meet without SBOM-style visibility.
1. U.S. Executive Order 14028
U.S. Executive Order 14028, issued in May 2021, helped push SBOMs into mainstream cybersecurity practice by requiring stronger software supply chain security for federal procurement. It helped establish SBOMs as a practical mechanism for understanding the components inside software products.
momentum around SBOMs grew strongly in 2023, but "the first formal mandate actually came earlier, with Executive Order 14028 in May 2021."
2. UNECE R155 and ISO/SAE 21434
As Brzezinski notes in Automotive IQ's interview, "ISO/SAE 21434 and UNECE R155 do not explicitly mandate SBOMs by name, but they clearly require continuous vulnerability management, risk identification, and lifecycle transparency."
That is why SBOMs are becoming a natural fit for automotive cybersecurity management systems. They provide a scalable way to support vulnerability monitoring, impact analysis, TARA updates and lifecycle risk management.
3. Cyber Resilience Act
The EU's Cyber Resilience Act, or CRA, introduces mandatory cybersecurity requirements for products with digital elements. The European Commission says the CRA requires manufacturers to address cybersecurity across planning, design, development and maintenance, and to handle vulnerabilities during the lifecycle of products. The CRA entered into force on 10 December 2024, with main obligations applying from 11 December 2027 and reporting obligations applying from 11 September 2026. See the European Commission overview here: Cyber Resilience Act.
For automotive suppliers that produce connected components, aftermarket devices, software, firmware, cloud-linked systems or digital products not fully covered by sector-specific vehicle regulation, SBOMs may become essential evidence for CRA readiness.
4. U.S. connected vehicle technology restrictions
The U.S. connected vehicle rule shows how cybersecurity, supply chain integrity and geopolitics are converging. The Department of Commerce states that certain Vehicle Connectivity System and Automated Driving System technologies from China or Russia present an undue and unacceptable national security risk.
For OEMs, this creates a need to understand not only whether a vehicle contains vulnerable software, but also where software and hardware originate, who supplied them and which systems they connect to.
This is where SBOM and HBOM practices become increasingly valuable together.
Why SBOMs matter for connected vehicle cybersecurity
The strongest argument for automotive SBOMs is operational: they help cybersecurity teams respond faster and more accurately.
Without an SBOM, a new vulnerability can trigger a manual scramble. Teams may need to contact suppliers, review spreadsheets, check software releases, inspect code repositories and ask whether a vulnerable package exists anywhere in the product line.
With a mature SBOM process, teams can ask more precise questions:
- Which components contain the affected library?
- Which software versions are impacted?
- Which ECUs or vehicle systems are affected?
- Which suppliers provided the software?
- Is the vulnerable component reachable or exploitable?
- Can it be patched through OTA updates?
- Does the issue affect safety-critical functionality?
- Does it require regulatory reporting or customer notification?
Brzezinski argues that BOM data should anchor cybersecurity decision-making in the actual system composition. As he puts it: "Instead of asking what could theoretically go wrong, teams can ask what the system really contains and where the real exposures are."
That is particularly important for safety-critical components. A vulnerability in an infotainment app may not carry the same risk as a vulnerability in a telematics control unit, gateway, ADAS component or software update mechanism. SBOM data helps teams prioritize based on the combination of vulnerability, exposure, system function and safety relevance.
Case study: Log4Shell and the need for software visibility
The Log4Shell vulnerability in Apache Log4j is one of the clearest examples of why SBOMs matter. When CVE-2021-44228 was disclosed in 2021, organizations around the world had to determine whether they used the vulnerable Log4j library and where it existed across their software estate.
For companies without component visibility, this became a time-consuming manual exercise. In connected vehicles, the same problem can become even more difficult because software may be distributed across embedded systems, supplier code, diagnostic tools, cloud platforms and mobile applications.
An automotive SBOM does not eliminate vulnerability risk. But it gives teams a better starting point for answering the most important question: are we affected?
Why static SBOMs are not enough
One of the biggest mistakes OEMs and suppliers can make is treating an SBOM as a one-time document created near release.
Connected vehicle software changes continuously. Suppliers release updates. Open-source packages are patched. New vulnerabilities are disclosed. OTA updates change deployed software. Vehicle variants may use different software builds. Cloud services evolve after the vehicle leaves the factory.
That means the SBOM must be treated as a living asset.
Brzezinski is clear on this point: "SBOMs and HBOMs are still often misunderstood as static documentation." He argues that they should feed directly into "TARA updates, vulnerability monitoring, and change management throughout the vehicle lifecycle."
This is where many organizations still struggle. A static SBOM may help with a compliance request, but it will not support real-time vulnerability management unless it is:
- Machine-readable.
- Automatically generated.
- Linked to build and release pipelines.
- Updated when software changes.
- Connected to vulnerability intelligence.
- Mapped to vehicle systems, variants and suppliers.
- Usable across OEM and supplier boundaries.
Key numbers and facts shaping SBOM adoption
2021 — U.S. Executive Order 14028 helped make SBOMs part of federal software supply chain security expectations.
2024 — The EU Cyber Resilience Act entered into force, creating mandatory cybersecurity requirements for products with digital elements.
11 September 2026 — CRA reporting obligations for actively exploited vulnerabilities and severe incidents begin applying.
Model Year 2027 — U.S. connected vehicle software prohibitions linked to China and Russia begin applying under the Commerce Department rule.
11 December 2027 — The main CRA obligations apply, increasing pressure on manufacturers to manage cybersecurity across product lifecycles.
Model Year 2030 — U.S. connected vehicle hardware prohibitions begin applying.
2,414 repositories — A 2025 empirical study of SBOM-based vulnerability management examined 2,414 open-source repositories and found that downstream vulnerability scanners produced a 97.5 percent false positive rate in the studied context, while function call analysis helped prune 63.3 percent of false alarms.
That final point matters because it shows a key limitation: SBOMs are necessary, but not sufficient. Automotive teams need SBOMs that are accurate, enriched and connected to exploitability and reachability analysis. Otherwise, teams may drown in vulnerability alerts without knowing which risks actually matter.
What should an automotive SBOM include?
A practical automotive SBOM should include enough information to support vulnerability management, supplier governance, compliance and lifecycle support.
Key elements may include:
- Component name.
- Component version.
- Supplier or origin.
- Open-source or proprietary status.
- Licenses.
- Dependency relationships.
- Package identifiers.
- Known vulnerabilities.
- Hashes or integrity metadata.
- Build and release context.
- Associated ECU, software package or vehicle function.
- Update history.
- End-of-support information.
- Links to VEX or exploitability information where available.
For automotive, the most valuable SBOMs are not just lists of components. They connect components to vehicle context. A vulnerability becomes far more actionable when a team knows which vehicle platform, ECU, software release, supplier and safety function it relates to.
How SBOMs support TARA and safety-critical risk assessment
Threat Analysis and Risk Assessment, or TARA, is central to automotive cybersecurity under ISO/SAE 21434. SBOMs can make TARA more accurate by grounding analysis in real system composition.
For example, instead of assessing generic risk to a telematics system, teams can use SBOM data to identify the actual libraries, versions, dependencies and supplier components inside that system. When a new vulnerability is disclosed, the TARA can be updated based on real exposure rather than assumptions.
For safety-critical components, this is especially important. Brzezinski notes that SBOM and HBOM data help identify components that are both "security-exposed and safety-relevant," allowing teams to prioritize risks based on potential impact rather than vulnerability scores alone.
This is a key point for connected vehicle cybersecurity. A vulnerability score may be high, but the actual risk depends on where the component is used, whether it is reachable, whether it affects a safety function and whether mitigation is available.
What OEMs and suppliers should do now
Automotive companies should treat SBOM maturity as part of their cybersecurity management system, not as a standalone compliance project.
A practical preparation plan should include:
First, define where SBOMs and HBOMs are required across vehicle systems, connected products and supplier deliverables.
Second, standardize formats. OEMs and suppliers should align around machine-readable, future-proof formats that can be consumed by tooling across the supply chain.
Third, integrate SBOM generation into CI/CD pipelines so that BOMs are updated as software changes.
Fourth, connect SBOM data to vulnerability intelligence and TARA workflows.
Fifth, require supplier SBOMs through procurement and contractual processes.
Sixth, map SBOM data to vehicle platforms, ECUs, software versions and OTA update packages.
Seventh, develop processes for VEX, exploitability analysis and false-positive reduction.
Eighth, ensure SBOM and HBOM data can support regulatory audits, incident response and post-market monitoring.
The future of automotive SBOMs
The next stage of automotive SBOM maturity will be defined by automation, tooling convergence and operational use.
This is important because many vehicles include third-party or supplier components where source code access may be limited. Binary-level analysis can help close visibility gaps, while source-code analysis supports deeper development-stage control. Mature SBOM programmes will need both.
Over time, SBOMs, HBOMs and related concepts such as CBOMs may become part of a broader "bill of materials" ecosystem for software-defined vehicles. The goal is not documentation for its own sake. The goal is trusted, operational data that supports real-time cybersecurity decisions.
Key takeaways: why automotive SBOMs matter
Automotive SBOMs are becoming critical because connected vehicles depend on complex software supply chains that are difficult to secure without component-level visibility.
SBOMs help OEMs and suppliers identify vulnerabilities, manage supplier risk, support TARA, prepare for regulations and respond faster to emerging cybersecurity issues.
The most effective SBOMs are not static spreadsheets. They are machine-readable, automated, continuously updated and integrated into engineering, security and compliance workflows.
For connected vehicles, SBOM maturity will increasingly separate companies that can manage software risk continuously from those that only discover risk when a vulnerability, audit or regulation forces the issue.
In short, the automotive SBOM is becoming a foundational tool for connected vehicle cybersecurity, software supply chain resilience and long-term compliance.
FAQs
What is an automotive SBOM?
An automotive SBOM is a software bill of materials for vehicle software. It lists software components, versions, dependencies and supplier information to help OEMs and suppliers manage vulnerabilities and software supply chain risk.
Why do connected vehicles need SBOMs?
Connected vehicles rely on software from multiple suppliers, open-source packages, cloud services and embedded systems. SBOMs help identify which components are affected when a vulnerability is discovered.
Are SBOMs required by UNECE R155?
UNECE R155 does not explicitly mandate SBOMs by name, but it requires lifecycle cybersecurity and vulnerability management. SBOMs provide a practical way to support those requirements.
What is the difference between SBOM and HBOM?
An SBOM tracks software components. An HBOM tracks hardware components. In connected vehicles, both can support cybersecurity, compliance and supply chain risk management.
How do SBOMs support ISO/SAE 21434?
SBOMs support ISO/SAE 21434 by improving visibility into software components, enabling vulnerability monitoring, supporting TARA updates and helping teams reassess risk as threats evolve.
What should OEMs do now to prepare for SBOM requirements?
OEMs should integrate SBOM generation into development workflows, require supplier SBOMs, standardize formats, connect SBOMs to vulnerability intelligence and map software components to vehicle systems and OTA update processes.