The Software-Defined Vehicle Is Not a Technology Problem.
Every OEM is running towards SDV. Most will discover — too late — that the blocker is not their stack. It is their operating model, their supply chain assumptions, and their relationship with trust.
There is a question the automotive industry has been avoiding. Not about electrification, not about autonomy, not about which compute architecture will win the next decade — but a more fundamental one: can an organisation built to ship physical products, on five-year cycles, governed by supply chains that predate the internet, actually become a software company?
I do not ask this rhetorically. I ask it because I live inside the answer every day, leading the Connected Cars Platform at Tata Motors — one of the world’s largest and most complex automotive programmes. And my honest view, after years of building this infrastructure, is that the industry has a clarity problem. We are solving for the wrong constraint.
"The race to the Software Defined Vehicle is not a race to adopt new tools. It is a race to rebuild the trust infrastructure that makes those tools mean something."
What follows is not a product review or a conference recap. It is a set of theses — things I believe the industry needs to confront honestly — drawn from the real experience of building a DevSecOps backbone for one of India's most ambitious SDV programmes, using JFrog as its foundation.
THESIS ONE
The SDV’s hardest problem is not software. It is provenance.
When people talk about the Software Defined Vehicle, the conversation usually gravitates towards the glamorous end: AI-assisted driving, personalised in-cabin experiences, remote diagnostics. These are real and important. But they are downstream of a problem the industry is less eager to discuss.
A modern vehicle programme at scale involves somewhere between 50 and 150 electronic control units, each running firmware from a different source. Some is written in-house. Most arrives from a Tier-1 supplier as a compiled binary — a black box the OEM did not write, cannot read, but is legally and morally responsible for.
This is not an edge case. This is the automotive software supply chain. And it has an uncomfortable implication: you cannot have a Software Defined Vehicle strategy without a software supply chain strategy. The two are the same problem.
THE TATA MOTORS REALITY
At Tata Motors, our Connected Cars Platform integrates software artifacts from over 15 partner organisations alongside our own internally developed code. Every piece — whether written by our engineers in Pune or delivered as a binary from a Tier-1 partner — must be provable, traceable, and compliant before it reaches a vehicle.
JFrog Artifactory became the single source of truth for this entire ecosystem. Not because it was the most convenient tool, but because the alternative — fragmented repositories, manual handoffs, tribal knowledge about what version of what binary went into which build — was a liability we could not afford.
The insight here is not about tooling. It is about the organisational admission that the supply chain is the product. The vehicle that a customer drives is, in software terms, the aggregate output of dozens of development organisations who will never meet each other. The OEM's job is to make that aggregate trustworthy. Centrally. At every release.
THESIS TWO
Speed and safety are not a tradeoff. Refusing to resolve the tension is the failure mode.
The received wisdom in automotive engineering is that safety and speed exist in opposition. Move fast, and you cut corners. Move carefully; you fall behind. This framing is seductive because it feels honest. In practice, it is the rationalisation of organisations that have not yet invested in resolving the tension.
Here is what I have learned building continuous delivery infrastructure for software that goes into moving vehicles: the organisations that treat speed and trust as opposing forces are the ones that have not automated trust.
When every artefact in your pipeline is automatically scanned for vulnerabilities the moment it lands in your repository, when SBOM generation is a pipeline output rather than a programme-end deliverable, when partner binaries are governed by the same policy engine as your own code — you have not slowed down. You have made speed safe.
At Tata Motors, our CI/CD infrastructure runs across more than 200pipelines. Engineers across multiple sites commit code continuously. The release cadence we are working towards would have been considered reckless by automotive standards a decade ago. It is only viable because the trust layer is automated, not manual.
"The slowest thing in automotive software delivery is not the build. It is the meeting where someone asks whether a binary is safe to deploy. Automate the answer, and the meeting disappears."
What follows is not a product review or a conference recap. It is a set of theses — things I believe the industry needs to confront honestly — drawn from the real experience of building a DevSecOps backbone for one of India's most ambitious SDV programmes, using JFrog as its foundation.
THESIS THREE
Regulation is not arriving. It has arrived. And it is a gift, if you read it correctly.
UNECE R155 and R156 — and their Indian equivalents AIS 189 and 190 — have fundamentally changed the compliance conversation in automotive. These regulations mandate cybersecurity management systems and software update management systems as conditions of vehicle homologation. They are not advisory. They are not aspirational. They are prerequisites for putting a car on the road.
I want to make an argument that runs against the grain of how most OEMs are approaching this: these regulations are not a burden. They are a blueprint.
Read UNECE R155 carefully and you will find a detailed specification for exactly the kind of traceability, vulnerability management, and incident response capability that a mature DevSecOps organisation needs to build anyway. The regulation did not invent a new requirement. It codified a best practice that software-forward organisations were already pursuing.
THE ARCHITECTURAL IMPLICATION
CSMS compliance under R155 requires end-to-end cyber posture from component sourcing through in-life updates. SUMS compliance under R156 requires governed, auditable update processes with traceable delivery chains.
Both of these are properties of a well-designed DevSecOps pipeline — not additional governance layers bolted on top. JFrog’s traceability, attestation, and policy controls made our regulatory readiness a consequence of good engineering, not a separate compliance programme.’
The OEMs that will struggle with R155/R156 are the ones that treat it as a legal question rather than an engineering question. The ones that build the right infrastructure — a single source of truth for artefacts, automated security scanning, governed OTA delivery pipelines — will find that compliance is a byproduct, not a project.
THESIS FOUR
The OTA update is the product. Which means the pipeline is the factory.
There is a mental model shift that every automotive organisation needs to make, and many have not made it yet. In the traditional world, the product is the vehicle. Once it leaves the factory, it is complete. The software-defined vehicle breaks this model permanently.
The vehicle that a customer drives today is not the vehicle they will drive in six months. It will have new features, patched vulnerabilities, updated maps, refined ADAS behaviour — all delivered over the air, long after the hardware left the assembly line. The product is not the car. The product is the car-plus-its-update-history. And that update history is generated by a software delivery pipeline.
This is a profound shift in what it means to manufacture a vehicle. It means that the factory does not stop when the car ships. The pipeline is a continuous factory, running twenty-four hours a day, producing software updates that are, in a meaningful sense, new versions of the product.
"An OTA update is not a patch. It is a product release. Which means it needs a release process — one governed, traceable, and auditable from commit to car."
At Tata Motors, the architecture reflects this. Approved and scanned builds flow from JFrog Artifactory into our OTA update infrastructure, and from there to the vehicle — integrated with our automotive PLM systems so that engineering changes are traceable all the way through. The pipeline is the factory. And like any factory, it must be reliable, auditable, and safe.
THESIS FIVE
The engineering culture gap is wider than the technology gap.
I want to end with the thesis that is hardest to quantify and most consequential to get right. The SDV transition is, at its heart, a culture transition. And most of the technology vendors selling into this space have an incentive not to tell you that.
The technology for building software-defined vehicles exists today. The CI/CD tooling, the artefact management systems, the security scanning platforms, the OTA infrastructure — it is all available, mature, and proven at scale. What is not available off the shelf is an organisation that knows how to use it.
Automotive engineering cultures were built around hardware-first thinking: long design cycles, waterfall programme management, quality gates that assume the product is immutable once it ships. Importing software delivery practices into this culture is not a tooling challenge. It is a change management challenge of the first order.
The single source of truth is a cultural commitment before it is a technical one. You can deploy Artifactory in an afternoon. Getting 15 partner organisations and multiple internal teams to actually use it — and only it — takes months of alignment work.
Security scanning at the pipeline level requires a shift in who owns security. In most automotive programmes, cybersecurity is a function at the end of the programme. In an SDV programme, it must be a property of every build — which means it must be owned by the engineers doing the building.
OTA as a product capability requires a different relationship with the customer. Customers who experience a vehicle as a static, physical product will react differently to software updates than customers who understand their car as a platform. Managing this expectation is as important as managing the software.
The partner ecosystem is both the biggest risk and the biggest opportunity. The OEMs that learn to govern their Tier-1 software supply chains — to scan, attest, and govern partner binaries at scale — will have a structural advantage that is very hard for competitors to replicate quickly.
The Race Worth Running
The SDV era does not reward the organisations that move first. It rewards the ones who move with the deepest foundations.
Speed without provenance is a liability. Features without governance are debt. And a pipeline without trust is just complexity with better branding.
Build the invisible layer right — the single source of truth, the automated security posture, the governed delivery chain — and everything above it accelerates. Get it wrong, and every layer you add makes the problem harder to fix, not easier.
The technology exists. The regulations are written. The supply chain is ready to be governed.
The only question left is whether your organisation is.
This piece is drawn from my presentation at EveryOpsDay '26, Mumbai — a conference for the people who build and operate the systems the world runs on. If you'd prefer to watch rather than read, the full talk is linked above.