There’s a chart making rounds in the past few years, comparing the software complexity of connected cars to that of an F-35 jet fighter. Apparently, an F-35 includes around 8 million lines, whereas a modern car has around 100,000,000. So are cars more complex than a fighter jet?
Before we delve into this, let’s take a look at the chart:
It’s about efficiency, not complexity
The answer is, obviously, no. The autonomous car isn’t inherently more complex than a fighter jet. Those are nice numbers to throw around, but the story they tell is not one about complexity – it’s all about efficiency. Any kind of development for military equipment is usually very thought-through, meticulously planned. Fighter jets are highly integrated machines, and every line of code serves a purpose.
The modern car, on the other hand, is a mix of various components, riddled with legacy code and software that’s made for “cars”, not for the specific model. The various 3rd party components integrated into each car weren’t purpose-built to work just with that model, and so they include code that’s never used, never touched.
So What Can We Learn?
The one lesson that can be learned, is that the software attack surface for the connected car is a vast one. It’s difficult to estimate how many vulnerabilities on average appear with addition of a thousand new lines of code, as this number depends on the language and the type of software developed, but educated estimates range from 2 to 8 vulnerabilities per 100k lines. With 100 million lines, that number is 2,000 to 8,000, which, obviously, is a huge problem. Even if we discard most vulnerabilities as unexploitable, the potential effect of even one vulnerability that enables an attacker to take over the car, is devastating for both passenger safety, and the reputation of a car maker. Yet while the problem is huge, the challenge of tackling it seems almost insurmountable without effective vulnerability management and automation for vulnerability detection. And not just detection, but one that has to be done in a closed binary, as the component manufacturers aren’t very keen on disclosing their source code to the car makers.
Without this kind of technology, risk assessment for any new component is not only based on extremely partial data, but also creates an environment in which car makers are automatically drawn to components that have already proved themselves by not failing, despite the fact that they might not be the most secure ones available.
The issue can, and will be exacerbated by the advancement in autonomous car technology, which will add even more mission-critical systems into this jungle of code. It will also create more liability issues, as the driver ceases to be in control of the car, and the responsibility burden for anything that happens shifts to car makers and components manufacturers.
