Modern vehicles are essentially computers on wheels, with interconnected software-enabled systems such as advanced driver assistance systems (ADAS), keyless entry, onboard diagnostics, infotainment, and battery management functions. Many of these components support internet connectivity for over-the-air (OTA) software updates, remote access, and real-time monitoring.

The U.S. government’s efforts — including a recently proposed rule — to prohibit Chinese and Russian software and hardware components in vehicle connectivity systems highlights the threat while focusing attention on the broader issue of software supply chain security (SSCS) in the automobile industry.

Here’s what you need to know about the state of connected car security — and key insights more broadly about lessons from SSCS.

[ See our Essential Guide: Software Supply Chain Security for Dummies ]

Potholes prevail: A history of troubling hacks

In recent years, there have been multiple instances of researchers demonstrating ways to break into internet-connected components and execute various arbitrary commands. Examples include remotely unlocking a vehicle, turning the ignition on, flashing the headlights, activating the horn, and accessing a vehicle’s camera.

In September, white-hat hacker Sam Curry showed how an attacker could do all this and more, including precisely geolocating a vehicle using just license plate information. One of the most troubling demonstrations happened back in 2015 when researchers Charlie Miller and Chris Valasek exploited a vulnerable software component in a 2014 Jeep Cherokee and seized control of the vehicle’s steering, braking, transmission, and engine systems—while the vehicle was in motion.

“There is a very real risk of loss of life if we continue to add internet-to-physical controls [insecurely]. Right now, it’s funny to make horns honk and track people, but in the future the famous Jeep hack may replay itself if automakers aren’t careful about adding proper safeguards around internet-to-physical deployments.”
—Sam Curry

Software supply chain complexity: Cars, like enterprises, are at risk

What makes that a challenge is the complexity of the connected vehicle software supply chain. Like the vehicles themselves, the software supply chain is a complex web of interdependencies that involves numerous stakeholders and software components. Automakers source software from third-party vendors, open-source communities, in-house development teams, and other suppliers.

The sheer diversity of sources and the fact that a security weakness in a single component could have a cascading and potentially catastrophic outcome has raised the stakes around connected vehicle software security. A sampling of concerns includes insecure or malicious OTA updates, vulnerabilities in code, outdated libraries, and delayed patches.

The crucial difference between the connected car ecosystem and others is that there is an internet-to-physical element that places trust in third parties that have access to manage vehicles, Curry said. “If there were a SolarWinds-type attack on the connected car ecosystem, it could affect any component of this ecosystem and lead to huge data loss or potentially something more damaging like an OTA update compromise.”

Same old code story: Why holistic software assessment is key

David Brumley, founder and CEO of application security firm Mayhem, said there’s a need to look at connected vehicle software security from both a national security and a software vulnerability perspective. Efforts such as the U.S. government’s proposed ban on Chinese and Russian information and communications technologies are focused on preventing foreign adversaries from planting potentially malicious software and hardware within the connected vehicle ecosystem.

Risks tied to software vulnerabilities are another issue. Cybellum’s State of Automotive Security in 2023 report showed that a total of 5,921 new CVEs were detected in automative software last year, or more than 10% of the total 50,545 total declared CVEs. The vendor assessed some 30% of the new vulnerabilities last year as being relevant or potentially exploitable in the specific content of the product in which they were present; 87% of the vulnerabilities involved information exposure.

Troublingly, Cybellum’s research showed a high prevalence of old software packages — 10 years or older—and critical open-source software vulnerabilities in automative software. Many of these were OSS flaws disclosed years ago, such as Heartbleed (CVE-2014-0160), from 10 years ago; Spectre (CVE-2017-5753), from 2017; and Dirty COW in the Linux kernel (CVE-2016-5195), from 2016. “Much of the vulnerabilities we are seeing throughout connected automotive components continue to remain those whose true risk posture was exposed years ago,” Cybellum said. “By not identifying all embedded software components, teams are unable to identify if any are outdated, have reached end of service or end of life.”

Brumley said a lot of the software supply chain risk in the automotive industry has to do with vendors not keeping their OSS software properly updated.

“Automotive vendors do not update their dependencies at the pace needed today. Simply said, the time from when a new zero-day in OSS is found to when it’s actively exploited can be hours or days, while some automotive vendors could take months to update their software.”
—David Brumley 

In fact, some major automakers ship updates on an average of just once every 4.75 months, which is an infinite amount of time for attackers, Brumley noted. He stresses the need for automakers to build development pipelines that can test and field new software updates in less than a day if needed to address new threats.

“If you ask automotive vendors, ‘How much of your software do you have in a Docker container that can be tested in CI/CD?’ the answer would be, ‘Very small.’ That needs to change.”
—David Brumley

A mixed bag of standards: Watch this space

A handful of frameworks and standards has emerged in recent years that give automakers some guidelines on how to bake cybersecurity into their internet-connected components. The UN’s WP.29 document provides guidelines around risk identification and management in vehicle designs, risk assessments and verification incident response and analysis, and security lifecycle management across the vehicle production and post-production phase.

The standard also offers help around deploying OTA updates in a secure manner. Another example is ISO/SAE 21434 which focuses on cyber-risk management through all phases of a vehicle’s lifecycle. In addition, entities such as the Automotive-ISAC are working in collaborative cross-industry fashion to develop and share best practices for mitigating emerging automotive cybersecurity risks.

For the moment, though, specific guidance and standards around automotive software supply chain security still appears to be emerging.

One option would be to consider the equivalent of something such as the Protecting and Transforming Cyber Healthcare Act (PATCH) for medical device vendors, Curry said. At its core, this act would require medical device manufacturers to adhere to basic cybersecurity standards for their devices and would give the U.S. Food and Drug Administration the authority to hold companies accountable for compliance failures. “Governments should be more particular about the privacy and security elements of the connected car ecosystem,” Curry said.

Joe Saunders, co-founder and CTO of RunSafe Security, said code scans and software composition analysis (SCA) are good places for carmakers and others in the automotive supply chain to address the problem. A more long-term approach is to implement capabilities for analyzing source and build time components at every step so as to enable a complete picture of risk within the software.

“These risks are most noticeable when components originate directly from a banned origin country, but the underlying software supply chain can be compromised without country-of-origin issues. As such, generating an SBOM at build time with 100% ground truth data at build time [is key].”
—Joe Saunders

So too is ensuring you have a trusted binary, file protection, software integrity checks, and runtime memory protections.

Key lessons from the supply chain security front lines

Traditional approaches to application security (AppSec) are always going to be needed, much like the testing of individual components on a car, Saša Zdjelar, chief trust officer at ReversingLabs, wrote recently.

“Shifting left, for example, is great. You should be doing software testing as early as it makes sense in the SDLC. It gives you a valuable component view of your software, even if you lose some context in the process.”
—Saša Zdjelar

But approaches such as static application security testing (SAST) are useful only when it’s your application, when you have access to source code, and when the only types of vulnerabilities you’re worried about are cross-site scripting and SQL injection, Zdjelar said. If the source code is not yours, if you don’t have access to it, and if you’re also worried about things such as malware, tampering, malformed signatures, etc., traditional AppSec tools won’t help you.

And while dynamic application security testing (DAST) tools are a great complement to SAST tools for confirming vulnerabilities, they won’t tell you if you have malware, tampering, or malformed signatures. And they won’t say anything about any third-party components, whether commercial or open source — or about any software components that contain high CVE vulnerabilities. DAST is also limited to web applications and cannot test thick-client applications, binaries, etc. By the time you run DAST tools, your environment may already be compromised, because DAST tools require you to have already installed the application and to observe it at runtime, Zdjelar said.

What’s needed in the age of sophisticated and persistent software supply chain attacks is a modern approach to AppSec. Going beyond those traditional approaches is now a requirement to create truly trustworthy software. By implementing a holistic approach to AppSec, you can analyze a final product — your final, complete package. To do that, you need to be able to analyze thousands of file types and be able to identify potential malicious code, typically from repositories of millions of malware samples.

Whether it’s the software running in your organization or your car, with a holistic approach you’ll be able crash-test your application environment — and trust your software.

*** This is a Security Bloggers Network syndicated blog from ReversingLabs Blog authored by Jai Vijayan. Read the original post at: https://www.reversinglabs.com/blog/connected-car-cybersecurity-software-complexity-takes-to-the-road