As vehicles absorb software from dozens of suppliers, the security question is moving beyond supplier assurance. Before software becomes part of a vehicle, can the OEM establish what is actually inside the artifact it received?
A modern vehicle no longer comes from a single production line, at least not where software is concerned. Infotainment, ADAS, telematics, battery management, vehicle-control systems and OTA infrastructure are assembled from software originating across multiple supplier tiers.
A Tier 1 may depend on Tier 2 components, open-source packages, commercial libraries and increasingly AI-assisted development. By the time software reaches an OEM, the original development chain can be several layers removed from the artifact being delivered.
This is the convergence problem: independent software supply chains, development environments and security practices ultimately converge inside one vehicle that is expected to operate safely for years.
A trusted supplier is not necessarily a verified software supply chain
Supplier assurance is essential. OEMs need to know who they are buying from, how software is developed, how vulnerabilities are managed and whether the supplier meets the required security and regulatory expectations. Standards such as ISO/SAE 21434, UNECE R155/R156, TARA processes and secure development practices are all part of that picture.
But the security process of a supplier and the security properties of an individual software delivery are not the same thing.
A mature supplier can still deliver a build containing an outdated dependency, an unexpected third-party component or software that differs materially from what was previously assessed. Dependencies change. Builds change. Configuration changes. Development teams change. The artifact that arrives at the OEM is the point at which all those changes become real.
Artifact assurance asks: “Can we trust what this organization actually delivered?”
Where SBOMs help — and where they stop
The growing use of software bills of materials is an important step forward. An SBOM can improve visibility into the components and dependencies that make up a software product, helping OEMs understand exposure to known vulnerabilities and manage third-party risk.
But an SBOM is fundamentally a declaration of software composition. It does not, by itself, prove that the artifact delivered to the OEM contains exactly what was declared, that nothing unexpected was introduced during the build, or that the artifact has not changed since it was assessed.
That creates an important distinction between declared composition and observed composition. The first tells us what we expect to find. The second asks what is actually there.
The vehicle is an aggregation of artifacts
It helps to think about the vehicle software stack as an aggregation rather than a single system. An ECU update is an artifact. That artifact contains code, configuration and dependencies. Those dependencies may themselves originate from other organizations and open-source ecosystems.
Multiply this across dozens of ECUs and functional domains and the question changes from “Do we trust this supplier?” to “Do we understand what is actually in this build?”
AI changes the assurance equation
AI-assisted development adds another dimension. It is not necessary to assume that AI-generated code is inherently insecure to see the challenge. The more important issue is velocity.
Software can be generated, modified, reused and incorporated into builds at a pace that makes traditional point-in-time assurance increasingly difficult to maintain. A security review performed when a supplier was onboarded may say little about the exact artifact delivered months later.
The faster software changes, the more valuable it becomes to verify the artifact at the point where a trust decision is actually being made.
From supplier assurance to artifact assurance
This does not replace supplier audits, TARA, SBOMs, static analysis, secure development practices or the regulatory frameworks the automotive industry has spent years building. It adds another layer: continuous verification of what actually arrives.
That layer can sit at different points in the software supply chain — during supplier intake, within a CI/CD pipeline, before deployment, or around an OTA distribution process. The principle is the same: make the software artifact itself part of the trust decision.
This is the layer we built GateScanner Deep Detector for an independent assessment of the actual software artifact at the point where it is about to be trusted.
The next question is not who built it. It is what is actually in it.
The automotive industry has become much better at asking suppliers to demonstrate that they have a secure development process. That remains essential.
But as vehicles become software-defined, supply chains become more complex, software changes faster and AI accelerates development, assurance cannot stop at the organization that produced the software.
The next question is more direct:
That is increasingly becoming an artifact verification problem — and a new layer in the automotive software supply chain.
As vehicles absorb software from dozens of suppliers, the security question is moving beyond supplier assurance. Before software becomes part of a vehicle, can the OEM establish what is actually inside the artifact it received?
A modern vehicle no longer comes from a single production line, at least not where software is concerned. Infotainment, ADAS, telematics, battery management, OTA infrastructure and vehicle-control systems are assembled from software originating across multiple supplier tiers.
A Tier 1 may depend on Tier 2 components, open-source packages, commercial libraries and increasingly AI-assisted development. By the time software reaches an OEM, the original development chain can be several layers removed from the artifact being delivered.
This is the convergence problem: independent software supply chains, development environments and security practices ultimately converge inside one vehicle that is expected to operate safely for years.
A trusted supplier is not a trusted software supply chain
Supplier assurance is essential. But a supplier's security process and the security properties of an individual software delivery are not the same thing.
A mature supplier can still deliver a build containing an outdated dependency, an unexpected third-party component or software that differs materially from what was previously assessed. SBOMs can improve visibility into components, but visibility alone does not establish that the artifact conforms to what was expected.
The vehicle is an aggregation
It helps to think about the vehicle software stack as an aggregation rather than a single system. An ECU update is an artifact. That artifact contains code, configuration and dependencies. Those dependencies may themselves originate from other organizations and open-source ecosystems.
Multiply this across dozens of ECUs and functional domains and the question changes from “Do we trust this supplier?” to “Do we understand what is actually in this build?”
This is the layer we built GateScanner Deep Detector for an independent assessment of the actual software artifact at the point where it is about to be trusted — whether that is supplier intake, the CI/CD pipeline or an OTA channel.
From supplier assurance to artifact assurance
This does not replace supplier audits, TARA, SBOMs, static analysis or the compliance frameworks the industry has spent years building. It adds another layer: continuous verification of what actually arrives.
Software supply chain risk is not static. Components change, dependencies change, development practices change and the attack surface changes. AI-assisted development is likely to accelerate that pace further, making it increasingly difficult to rely on point-in-time assurance alone.
That is the convergence problem — and increasingly, it is an artifact verification problem.
Share on:
