OEM Cybersecurity: How to Verify What Your Suppliers Actually Shipped

A modern connected car runs software from dozens of suppliers spread across more than 100 electronic control units (ECUs). The infotainment head unit, the telematics module, the battery management system, and the gateway that links them each arrive from a different Tier-1, built on operating systems, libraries, and firmware sourced from tiers further down. Most of the code in a finished vehicle is written by someone other than the brand on the hood.

What Is OEM Cybersecurity Under UN R155?

Under UN Regulation No. 155, the manufacturer answers for all of it. R155 makes cybersecurity a condition of vehicle type approval and requires the original equipment manufacturer (OEM) to run a Cybersecurity Management System across the full vehicle lifecycle, including the security of software it did not write. R155 stays neutral on how, and ISO/SAE 21434 supplies the engineering method most OEMs use to produce the evidence. In the EU, the rule has applied to every new vehicle produced since July 2024. The supply-chain clause is the demanding part: you are responsible for the security of components authored several contracts away, and those components reach you as compiled binaries with no source attached, so there is nothing to read at the moment you accept them.

What Role Does a Supplier SBOM Play in OEM Supply Chain Security?

Most programs try to meet that obligation with paperwork. You ask a Tier-1 for a software bill of materials, or SBOM, and a CycloneDX file comes back, formatted and complete on its face. It gets signed, logged against the Cybersecurity Interface Agreement, and filed as evidence. What the file describes is the catch. Most supplier SBOMs are generated from a build manifest, so they record the components the build system was configured to pull in, rather than the ones that ended up in the firmware that shipped.

Why Manifest-Derived SBOMs Miss Components in Embedded Firmware

For software with a clean, package-managed dependency tree, the manifest and the shipped binary usually match, and a manifest-derived SBOM is fast, accurate, and worth relying on. Finite State runs that same source-based analysis on that kind of code for exactly that reason. Embedded automotive firmware works differently. Real-time operating systems like VxWorks, QNX, and FreeRTOS are compiled from source trees merged at build time, with no package manager for a scanner to read. Statically linked libraries are absorbed into the executable. Build and packaging steps add components after the manifest was written. The SBOM that comes back can look authoritative while omitting real components, and because a component absent from the list produces no findings, an incomplete SBOM is indistinguishable from a complete one that happens to be clean.

This is a structural problem rather than a lapse by any one supplier. When researchers ran six SBOM-generation tools across 26 open-source Java projects in a 2023 IEEE Security & Privacy study, the tools produced different component lists for identical code. The 2026 Minimum Elements for a Software Bill of Materials, published by CISA and its international partners, widened the recommended data fields and asked for full transitive coverage, yet it placed accuracy, coverage, and completeness outside the minimum elements and pointed to binary analysis as a way to detect components an SBOM leaves out.

Why Are OEMs a Primary Target for Supply Chain Attacks?

An OEM is where the supply chain concentrates. A single library reused across three Tier-1s reaches every vehicle line those suppliers touch, so one undeclared component is a fleet-wide exposure rather than a product-level one. The consequences show up the day a vulnerability is disclosed, when the questions that matter are whether the affected component is in your fleet and whether anything can reach it. Consider CVE-2025-6019, a Linux privilege-escalation flaw in the libblockdev component. It reads like a server problem, yet the same Linux services ship inside Automotive Grade Linux, which increasingly runs cockpit and central-compute domains, so the flaw travels into the vehicle. When libblockdev never appears on the supplier's manifest, it never enters your triage queue, and you learn it is present the day a researcher outside your program reports it. Fixing it in the field then depends on an over-the-air update that is slow to qualify and costly to push across a service life measured in decades, which is why catching an undeclared component before the image ships is far cheaper than catching it afterward.

How Do OEMs Verify Security in Third-Party Components?

You verify a supplier's software the way you verify any claim you are about to sign for, by checking it against the artifact itself. Generate a second SBOM directly from the delivered firmware image using binary analysis, and reconcile it against the one the supplier provided. That comparison shows what the supplier declared, what the binary actually contains, and where the two disagree. The components that appear in the binary but never in the declaration are the exposure that was going untracked, and finding them is the whole reason to verify.

The Limits of Binary Analysis, and Why Reconciliation Beats Either Source

Binary analysis has limits of its own. Static linking blurs the boundaries between libraries, and version detection sometimes relies on heuristics, so reading the binary alone can miss details the supplier's build records hold. Reconciling the two sources gives a more complete inventory than either produces separately: the supplier's records name components that static linking hides, and the binary reveals components the manifest never recorded. The result is a system of record you can put in front of an assessor. When you can document a specific discrepancy, such as a component in the binary that the SBOM omitted, you can require the supplier to correct it under the interface agreement and show the evidence behind the request.

Where Finite State Fits in OEM Cybersecurity

This is the work the Finite State Platform is built to do for an OEM carrying code it cannot see. It reads shipped firmware, binaries, and source to build a ground-truth inventory of what is actually in the image, consolidates supplier SBOMs against that inventory, and surfaces where the two disagree. From there, it ranks what remains by exploitability, so the components an attacker can reach rise above the ones that are present but inert. Because the platform reads the compiled artifact the way an attacker does, it identifies the components manifest-based tools miss: statically linked libraries, RTOS components with no package metadata, and anything introduced at build time.

See it on your own firmware. Book a demo to watch the Finite State Platform unpack a supplier's firmware image, reconcile it against the SBOM they handed you, and rank what remains by what an attacker can actually reach.