Few people realise how much software runs today’s cars, observes Les Hatton, emeritus professor of forensic software engineering at Kingston University, UK. “We sit at home and can’t work out why the printer isn’t working, and then we’ll get in a car where there’s probably more software underneath,” he says. “People should think twice about this.”
As vehicles become smarter and more connected, embedded software is likely to draw the eye of ‘digital vandals’ and extortionists. Alongside the prospect of hacking, automotive software brings the risk of serious digital error and subsequent safety recalls. Thus, in the automotive sector, the risk lies in on-board software as well as business software.
Experience suggests that modern cars contain a great many software flaws. Though most bugs cause only glitches, a few defects can create more serious outcomes and yet still lurk undiscovered. “Some errors require a relatively unusual set of circumstances before they’re triggered,” Hatton notes. “This is actually one of the longest-known empirical properties of software, discovered by engineer Ed Adams in 1984.”
Adams studied IBM mainframes and found that about a third of software faults took at least 5,000 years of continuous operation to emerge, though nobody had to wait quite so long because there were about 500 IBM mainframes around the world at the time. “A third of all defects would appear once, in one of those machines, unpredictably, about every ten years,” Hatton explains.
Today, bugs crop up in the same scattered fashion, but in shorter order. “If you send a million copies of a braking system out into the world, you’ll see defects much more quickly,” says Hatton. “So, one of the advantages of worldwide spreading of software is [that] you shrink the time required for unusual defects to appear. And they will appear. Nobody can test for all defects – it’s not feasible.”
Estimates from suppliers like Bosch and Continental suggest that today’s premium cars depend on as many as 100m lines of code. “Staying below one defect per 1,000 executable lines of code for the entire lifetime of the software is extremely difficult,” Hatton observes. “Less than 5% of all software genuinely falls into that category. The most reliable large application the human race has ever created is the Linux kernel, which is believed to have about one defect per 10,000 lines of code, in the entire lifecycle of the software.” Put simply, 100m lines of code implies tens or even hundreds of thousands of hidden defects.
Focusing on binaries
At the Detroit Motor Show in January, Canadian company BlackBerry launched a new tool to help battle these inevitable bugs, reducing the potential for both cyber-attacks and functional failures. Called BlackBerry Jarvis, it scans software for many different types of vulnerability and error.
While BlackBerry is known for smartphones, the company has become a force in trusted software. It owns the QNX operating system, which has underpinned critical applications from high-speed trains to internet routers for decades and is now employed by about 40 carmakers.
“The auto industry is starting to realise that if they want people to trust their cars, and if they want autonomous cars to become a mainstream reality, they are going to have to be very secure,” says Alex Manea, chief security officer at BlackBerry (see box, below).
Adam Boulton, the company’s business systems CTO and architect of BlackBerry Jarvis, concedes that no tool can spot every software error. “Jarvis doesn’t mean you can eradicate source code reviews,” he warns. “I never want to give people that hope – that’s not realistic.”
Source reviews look for mistakes or bad practice in code written by humans, whereas Jarvis analyses the binary executable generated from that code, looking for inconsistencies and errors. “There is an overlap of issues you would find doing a source code assessment and a static binary analysis,” Boulton explains. “Both techniques have advantages.”
Jarvis handles binaries for very practical reasons. “You don’t always have access to the source,” Boulton observes. “There is a benefit from having the source code, but that pretty much never happens. It’s particularly uncommon in automotive.”
As with hardware, there can be a complex supply chain in software and each link will aim to protect its intellectual property. Shipping binaries rather than source code protects investment. “It’s often very difficult to get hold of source code,” Boulton says. “And even if you do, testing it doesn’t scale particularly well.”
Testing the tech with JLR
Boulton cites a pilot programme which BlackBerry carried out for Jaguar Land Rover, where Jarvis was pitted against a manual code review. “We actually fared extremely well, to the point where we found every issue like for like,” Boulton says. “JLR put their own comparison together; it was entirely independent. They were thrilled, because the source code assessment took about 30 days, whereas Jarvis took seven minutes.”
Jarvis works by decomposing binary files into a form where structural problems and vulnerabilities like buffer overflows can be spotted. Scans are initiated from a developer’s build environment and errors flagged up on a dashboard. Jarvis yields quick results partly because it runs in the cloud, with Amazon Web Services providing resources on demand.
Since it deals with binaries, errors spotted by Jarvis will often need to be reported back to the software’s supplier for a fix. “Jarvis doesn’t just tell you the issue, it tells you how to remediate it, where it is and gets everything ready for the supplier,” Boulton adds.
As a side benefit, Jarvis can also flag up sloppy coding. “You can check if software adheres to your own standards or coding standards like MISRA C or CERT C,” Boulton notes. “We do see some violations coming up because typically, you’re relying on trust in a software supply chain. You ask if people are following standards, they say yes. Now you can actually check. If they’ve been riding on the system thinking it’s going to remain a trust exercise forever, that has now changed.”