One of the things that makes connected vehicle cybersecurity particularly challenging is scale. If a researcher or attacker discovers a remotely exploitable vulnerability in software running on a particular vehicle model, that flaw potentially exists in thousands of other vehicles running the same software.

Now imagine that vulnerability is discovered five or ten years after the vehicles were manufactured. There is a good chance the original development team has moved on, some software dependencies are no longer maintained, and the manufacturer has to determine whether the vulnerability is exploitable before it can begin thinking about a fix.

While automotive manufacturers spend years engineering, testing, and validating a vehicle before it enters production, once it leaves the factory, they no longer control when the next cybersecurity problem will arrive.

Manuel Rebelo and José Rui Simões, both Principal Engineers at Critical Software, made this point during a discussion on managing cybersecurity across the connected vehicle lifecycle. During development, teams largely determine when to evaluate risk. Once a vehicle is in the field, a supplier advisory or newly disclosed vulnerability can force an assessment at any moment.

“You don’t get to choose when your risk assessment gets tested,” Manuel said. 

So, what are the biggest challenges of automotive cybersecurity, and what are best practices to support cybersecurity throught a vehicle’s lifecycle? Manuel and José shared more.

1. Build an Accurate Automotive SBOM

During the discussion, we asked attendees where their organizations faced the greatest difficulty managing cybersecurity after production. Coordinating vulnerability information across suppliers came out on top, followed by identifying which deployed vehicles were affected by a vulnerability.

The two answers are closely linked. “If you can tell which vehicles in the field are affected, you can brief your suppliers, and you can also reassess the risk,” Manuel said. “Sometimes what seems like a supplier coordination problem is often a traceability problem underneath.”

Traceability depends on accurate tracking of your software components. At RunSafe, we work with plenty of organizations that have sound tracking processes built on an incomplete inventory. Components get modified, statically linked into other software, or pulled in without a package manifest, and those are exactly the cases a manifest-based Software Bill of Materials (SBOM) tends to miss. That’s a large part of why RunSafe generates SBOMs at build time, from what the compiler actually produces.

Inventories can also hold things that were never meant to ship. “It’s easy once you’re building a Linux distribution to have one or two packages that are not really needed,” José said. “Sometimes they were needed as a dependency for a version that got dropped or got updated, and it was no longer a dependency.” 

Finding the component is where the analysis begins. Before any talk of patching, manufacturers need to know which vehicle types and software versions carry it and whether the vulnerable function is reachable at all. 

“The bill of materials is important, but should not be the only source of information,” Manuel said. A defensible “not affected” call needs evidence from source code and configuration, including whether an attacker can reach the function, whether input validation blocks the attack, or whether a downstream component truncates an unbounded write to 32 bytes. 

The urgency also depends on how a fix would reach the car. “If you don’t have a way to remote software updates,” José said, “you have to do an actual recall, call vehicles to a shop.”

2. Maintain Build Environments

If you ask a team to rebuild firmware that shipped ten years ago, you will quickly discover whether its build environment survived. 

“You could produce a fix, but you will not be able to build it and ship it,” Manuel said of teams that let their tooling lapse. 

Keeping the source code is the manageable part. “Ensuring that all the operating systems, libraries, open source packages, and whatnot still exist in 15 years may be impossible,” José said. CERN recently faced exactly this when kernel support for an older processor architecture was dropped, threatening the upgrade path for hundreds of machines still in service.

Much of automotive runs on QNX and VxWorks, and you won’t always be able to get a license for a very old version. “Time is still needed,” José said, “because they’re no longer able to provide you with that version.”

That’s why teams should plan to move off end-of-life platforms. If you’re running Ubuntu 16.04 or Yocto 2.0, plan the move to a current long-term support (LTS) release. Updating a package version is quick. Backporting a fix into an unmaintained release and proving it didn’t break anything is slow.

3. Think of Security Beyond Patches

The PerfektBlue vulnerabilities offer a good example of the reality of patching delays. Researchers uncovered four flaws in OpenSynergy’s widely used BlueSDK Bluetooth stack that could be chained together to remotely execute code in affected vehicle infotainment systems. 

OpenSynergy provided patches in September 2024, but by June 2025, at least one automaker still hadn’t received the vulnerability notification or fix through its supply chain. Even after a patch reaches the manufacturer, integrating and validating changes across interconnected vehicle systems can take considerable time.

Even so, the industry has come a long way. In 2015, the fix for Charlie Miller and Chris Valasek’s remote attack on a Jeep Cherokee was sent to owners via USB drives in the mail. A thumb drive in the mail sets off alarm bells, but with no remote update path, it was the fastest option available.

Today, good in-vehicle observability shortens the cycle by letting manufacturers roll an over-the-air (OTA) update to part of the fleet, watch it, and expand.

One of the other challenges of patching is that it introduces code changes that need to confirmed to not disrupt safety.

“This is a bit of a meme,” José said, “but in security, you want to move as fast as possible and fix the thing as fast as possible. In safety, you want to change the thing as little as possible because re-verification and validation campaigns are quite expensive.” 

“A change is never isolated,” José said. “If you change something, there are still a lot of things that could go wrong that are worse than what you’re trying to fix.”

For example, a modern vehicle carries hundreds of electronic control units (ECUs), down to the small controllers that animate dashboard lighting. A minor fix to one of them can corrupt a message on a shared bus and affect something unrelated, so even a one-line change triggers a regression campaign. 

So what protects the fleet during the months between disclosure and a deployed fix? Architecture does a lot of the work. For example, an infotainment unit has no reason to talk to a brake controller, and as vehicle functions consolidate onto central computers, that boundary has to be drawn on purpose. 

“In the old times, everything was a wire or a cable,” José said. “With the move to software, everything becomes a data stream.”

Beyond architecture, protections within automotive software can further narrow the window. Embedded runtime security, such as randomizing where code sits in memory each time it loads, makes memory corruption bugs much harder to turn into working exploits while those bugs are still present. The vulnerable code still has to be fixed, but an attacker gets far less out of it while the patch is being validated.

4. Run a Cybersecurity Management System After Launch

What separates a team that treats every disclosure as a fire drill from one that handles it as routine work? Mostly a cybersecurity management system (CSMS) that keeps running after launch. 

“A cybersecurity management system often is seen as a set of documents, and it shouldn’t,” Manuel said. In his view, it should run three continuous loops for monitoring, deciding, and collecting evidence, so that the annual report to the approval authority “should really just be a summary of the work that has been happening all year.”

People change over a 15-year service life, so ownership has to outlast them. “The responsibility has to be assigned to roles and not people,” Manuel said. 

Temporary measures, such as disabling a feature while a patch is validated, need the same discipline. Organizations get into trouble, he said, when they treat these measures as “an engineering workaround instead of a decision with an owner and a date.” Each one should be approved by someone with authority to accept residual risk, given a review date, and paired with a signal for when it needs updating.

For teams wondering where to start, Manuel suggested running a drill. Pick a vulnerability from the last few months in a component you actually ship, work out whether your vehicles are affected, write down the evidence, and time it. Every blocker you hit tells you something about your process. 

Within the first 24 hours of a critical disclosure, an OEM should know whether the component is in its software, which vehicles and versions have it, and who owns the decision. “Firefighting mode is never the cheaper option,” Manuel said.

Connected Vehicle Security for the Second Decade

Connected vehicles will continue to receive vulnerability disclosures for as long as they’re on the road. The preparation that makes those disclosures manageable starts during development:

• Build an accurate inventory. Generate SBOMs from the software as it’s actually built, and tie them to the vehicle types and versions they ship in.
• Keep the ability to rebuild. Archive complete build environments and plan around end-of-support dates for every platform.
• Move onto current platforms. Updating a supported package is far faster than backporting a fix into an end-of-life release.
• Limit what attackers can reach. Use architectural boundaries and runtime protections to cover the months a safety-validated patch requires.
• Assign owners, then rehearse. Give risk decisions named roles, and run a drill on a real vulnerability to find the gaps before a critical disclosure does.

With these in place, a critical disclosure becomes part of normal engineering work.

To hear the full conversation with Manuel and José, watch the on-demand webinar. For more on automotive software security, download our white paper, Driving Security: Safeguarding the Future of Automotive Software, and RunSafe’s 2025 Connected Cars Cyber Safety and Security Index.