Why software supply chain transparency now matters
Transparency across the software stack can raise concerns about intellectual property, while continuous documentation demands tighter collaboration between product development and software engineering.
Bildagentur PantherMedia / videoflow
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.