Software Defined Vehicles

Cybersecurity

Why software supply chain transparency now matters

2 min
Night-time aerial view of a busy road junction with bright vehicle light trails.
Transparency across the software stack can raise concerns about intellectual property, while continuous documentation demands tighter collaboration between product development and software engineering.

As vehicles become software-defined, cybersecurity risks are shifting deeper into the software supply chain. This is where SBOMs, regulation and process discipline start to matter.

For years, automotive cybersecurity was often framed around the vehicle itself: ECUs, interfaces and external attack surfaces. That is no longer enough. As software becomes the operating core of the vehicle, risk moves upstream into the software supply chain.

This is where the topic becomes strategically important. Modern vehicles combine proprietary code, supplier software, open-source components, cloud interfaces and increasingly also artificial intelligence functions. In that environment, cybersecurity is no longer just about protecting the end product. It is about understanding what is inside the software stack in the first place.

Systematic cyber risk management

In this context, the Software Bill of Materials, or SBOM, is gaining strategic relevance. It functions like a software blueprint and ingredient list. That makes it a critical tool for cybersecurity, compliance and faster incident response.

According to Mirko Ross, CEO of Stuttgart-based risk analysis specialist asvin, manufacturers are now facing converging regulatory obligations. For vehicles, UN ECE WP.29 requires structured cybersecurity management. For production and digital infrastructure, the European NIS2 Directive and the Cyber Resilience Act add further pressure. Together, these frameworks make systematic cyber risk management unavoidable.

Why the supply chain is the real challenge

The automotive industry operates one of the most complex supply chains in manufacturing. Vehicles combine thousands of components and software modules from multiple suppliers. OEMs develop only part of the software themselves, while major shares come from Tier 1 and Tier 2 suppliers or from open-source libraries. This creates limited transparency across dependencies, versions and risks.

The challenge becomes even greater because software is no longer static. Over-the-air updates continuously change vehicle software in the field, meaning documentation and risk visibility must also be continuously updated. Ross points out that software products are highly complex structures with supplier components, cloud interfaces and increasingly also AI-based functions. Maintaining a current and reliable picture of that environment is difficult.

To address this, OEMs are pushing cybersecurity obligations into procurement and supply agreements. Suppliers are increasingly required to provide SBOMs and demonstrate how they monitor and remediate vulnerabilities. Technically, however, this only works if standards, interfaces and toolchains are aligned. Formats such as SPDX and CycloneDX are widely used, but data must be converted between systems without loss. Otherwise, vulnerability scanning across the chain becomes unreliable.

Why SBOMs require organisational change

At the same time, SBOM management is not just a technical issue. It requires organisational change. Transparency across the software stack can raise concerns about intellectual property, while continuous documentation demands tighter collaboration between product development and software engineering. In practice, this means integrating SBOM generation and vulnerability analysis into DevSecOps and CI/CD pipelines. Used well, SBOMs support both automated checks before deployment and continuous monitoring of the software versions actually delivered to vehicles.

In automotive cybersecurity, that shift is decisive. Software supply chain visibility is becoming a prerequisite not only for regulatory compliance, but for secure and scalable vehicle development.